top of page

Speed to Deliver

Time is money, speed saves time.


Deliver with Speed and Quality

Can you complete an impossible project with ¼ of the time originally allocated to it, then you are a real Engineer.

The engineers around the world are so much pressured to deliver everything at a fast pace. If a team or an individual could deliver the job before the actual planned date, they are really smart.


Let me introduce one person who was an Engineer in Indian Railway, Mr. E. Sreedharan and he showed us his ability to deliver something that is impossible in a short time and now he is India's highly valued engineer who was the backbone of lots of engineering projects of modern India. This started with a bridge, In December 1963, a cyclone washed away parts of Pamban Bridge that connected Rameswaram to mainland India. The Railways set a target of six months for the bridge to be repaired while Sreedharan's boss, under whose jurisdiction the bridge came, reduced it to three months. Sreedharan was put in-charge of the execution and he restored the bridge in just 46 days.

Any business or industry, speed to market and the quality is very important, a win win situation..

In today’s connected world, improved speed to market is crucial for achieving better revenue margins, more efficient managerial practices, and increased market competitiveness. This has led to a strong appetite for a new generation of practices and technologies that enable speed and responsiveness.


As an engineer we have to always explore innovative ways to help our team to deliver with speed and quality. Our extensive experience, our experience to quickly respond to a customers' requirement or a technical problem that we have internally, finding new ways of working on existing or new technologies, everything matters.



A Software Engineer’s Perspective


Today in my company’s all-hands meeting, there was talk on velocity of development, a nice vision. This triggered me to bring-in my thoughts here and want to reiterate that it was not a very modern thought, but was there earlier, shown to us by previous engineers.


We can say the software delivery is fast when:

  • Goals are clear. It’s clear what we are trying to accomplish and our team is aligned around on how to accomplish it.

  • Any information we need is readily available. For example, if we need to talk to a subject matter expert, they’re nearby and readily available.

  • Systems and tools we depend on make sense and are easy to use. For example, programming languages, development environments, APIs, libraries, components, services, communication tools, how you track work, etc.

  • Minimize Designing, documenting Phase. Sometimes we do not require even a design phase, unless otherwise you are creating a real complex system. The time to document the design can be utilized for real development, then once delivered create the design document.

  • Any administrative, non-value adding activity is minimized. For example, time tracking, performance appraisals, estimation, etc.

How to make software product delivery fast:

  • The entire organization should focus on a limited number of important initiatives and not trying to do everything at once.

  • Initiatives are broken down to smaller pieces. People don’t try to deliver everything at once.

  • Coordination is effective. That is, people synchronize expectations before starting any kind of effort that has large interdependencies rather than just assume alignment and then continue to synchronize regularly.



Developer feeling pressure


Pressure to "speed it up" tends to hit developers the hardest. But top developers are difficult to recruit, costly to retain and easy to lose. The constant pressure to magically do more, faster — especially if the rest of the team is not equally fast and productive — can eventually frustrate developers, placing your most valuable asset at risk.


We need to look at some few proven strategies for accelerating application delivery without increasing the burden on developers. I have read a couple of them, but never practiced, even though I think it's worth sharing with you all.


Low-Code/No-Code

Low-code/no-code development is one way in which organizations are meeting the relentless demand to deliver more software faster. Low-code/no-code essentially "democratizes" the development of common applications by enabling non-programmers to build and customize standard business workflows via user-friendly interfaces. It also helps developers quickly knock off many routine tasks without worrying about low-level implementation details so they can focus their time and energy on the more strategic and challenging tasks that set your business apart. Nowadays there are Low-code/no-code development frameworks available to classic languages like Java and Javascript. React native has lots of open source plugin libraries available, which makes mobile app development very easy and fast.


Realize what is slowing

The applications being released in today's DevOps processes are the product of many different components, being developed by different teams on different schedules using different tools. If you lack real-time insight into the overarching application's release readiness, you are slowing down the delivery.

  • Releasing issues into production: This means that developers will later have to stop what they're doing, take time to reacquaint themselves with that functionality (sometime it takes too much time), figure out how to fix the problem and work with QA to ensure it's really fixed and didn't inadvertently break something else in the process.

  • Unnecessarily delaying releases: It's not uncommon for organizations to defer delivery as inefficient-dependencies are not satisfied, may be a depending API not yet ready, or the dependent service may not ready to consume.


For each team and each component, there are likely volumes of data points buried within different instances of planning, dev, build, test, release and ops tools. If you can unlock that data and automatically convert it into a clear, accurate release assessment, you can release the moment you're ready without worrying about production issues derailing your subsequent releases. The more you can automate the collection of those critical data points, the more efficiently you'll be able to fix critical issues — so you can reach the finish line faster.


Reference:


コメント


bottom of page