Anatomy Of Perfect Software Delivery

In the software industry, there is always the pressure of delivery. ‘Ship out faster than perfect’ they say.

Companies are often in the search for improving their workflow and task management to make the process and deliveries efficient. This is one of the reasons that we see evolution in project management tools and techniques all these years. While there is continuous improvement, the perennial question that often pops into any founder’s mind is

Is there something we can do to make delivery more predictable? And if yes, then how?

Although everyone would like you to deliver fast with high quality at low cost, the age-old truth is that from those three, you can only pick two.

Now, quality is something one cannot forget and speed cannot be forever increased. After all, you cannot just add people and get more work done. The answer to this paradigm eventually lies in the balancing of the three factors. Ideal software practice would keep the quality high with optimal speed and would save costs by removing waste and rework. This is what I consider the perfect software delivery.

The problem is that software is built under such an agile environment with continuous feedback and changes in priority that a 100% predictable process is next to impossible. The changes are inescapable too as companies move closer to user feedback as they build and users always surprise.

Thus, the same plan cannot work every time. There will always be sudden demands as the company gathers feedback. Hence, priorities would change, and architecture may change and even the tech stack could be required to change.

Bringing predictability to software delivery cannot be solved like one solution to complete software development but is more like fixing the smaller components to make the individual sprints be delivered on time and with expected quality. These smaller improvisations can then add up to form a process that makes software delivery predictable.

In fact, the predictability of software delivery isn’t limited to the delivery of software at all. It is based on a variety of factors such as

• The time it takes to change the status of an update i.e. from its starting to its completion
• The average time taken to fix a certain bug
• The failure rate of a certain process
• The frequency of deployment

All these factors contribute to the predictability of software. With all of the above in mind, let’s dive into further understanding of what derails project delivery and how to fix it.

What Derails Software Delivery?

Every software starts with a seemingly perfect plan. The problem in keeping it in line with the plan is that software complexities and time taken to solve then cannot be predicted by 100%. Sometimes seemingly large parts could just be fixed with an API call while small nuances may take days. Here are some other reasons that derail software delivery-

• A Gap Between The Definition Of Done Among Team Members

One of the major causes of delays is the difference between what the development team may consider as complete vs what really is a finished sprint. While the development team may claim their work is considered done in the prescribed timeline, the product owner’s delivery version could be expecting more aspects covered in terms of quality, testing, interoperability, etc.

• Inconsistent Process

There are just so many processes and tips out there on project management that it may completely boggle the mind. Inconsistency in the process or having no process at all results in chaotic development. This is often true when the whole project is dependent on a single developer who could be making decisions at their own whims and comfort.

• Lack Of Quality Control

While there is the talk of quality control, in the real world, speed supersedes quality and when quality processes are not defined, the scope and timelines fall through the gaps.

Especially startups assume to just focus on getting work done and think about quality later but such an attitude creates a technical debt that is hard to fill later. Moreover, it makes a culture in the team that is laidback to quality and is difficult to change later.

• Lack Of Responsibility Taken By Developers

One of the inherent reasons for failing output is the team culture and the attitude of the team for work and keeping the delivery on course. This is a human issue where if there is a lack of motivation or enough conviction within the team, the project could keep getting messier with no real effort to solve it.

So how to keep your project delivery in check? Perfect software delivery is all about managing the expectations and mitigating the risks. It is about proactively identifying the issues and fixing them before these issues impact the team’s plans. My solution to building perfect project delivery is based on 3 broader trends that need to be aligned to keep Software delivery perfect.

• The right planning
• The right execution
• The team orientation

A. The Right Planning

The right planning is pre exercises and aspects of software development before the start of development. This involves the planning of the sprint, setting up expectations, end goals, and so on. Here are the different aspects to consider during this stage

1. Having Clear Requirements

Clear requirements are those that make it easy to understand for the developer to follow. Mockups or wireframes are a hundred times better than a worded document. Clear expectations help in avoiding any miscommunication and misjudgment in development.

2. Planning The Sprint

A lot of times teams plan sprints in a hurry or just follow a plan without giving it a deep thought at the start of the sprint. This kind of practice is bound to fail.

At every sprint, the stakeholders should sit and plan the sprint before putting it to execution. Establish the clear outcome of the sprint right at the start. Take a look at the product backlog, convert it to tasks and make a plan that is achievable.
Sprint should not be too long or too short. 2-3 weeks is a good length.

Post the sprint, there must be the sprint retro to share feedback and learnings for the future sprint. Even there could be a time set up to clear backlogs before starting a new design sprint. Measure what matters so that the team can improve on key parameters. This way the complete team is focused on making each sprint more predictable.

3. Clearing The Definition Of Done

Very often, development teams misunderstand the meaning of done, and that skewed judgment may create a delay in your project delivery. A checklist confirming that the development is done can be a time and effort saver.

Here is a checklist that we use at Mindbowser

👉 Feature is implemented
👉 Unit tests are passed
👉 Documentation is up-to-date
👉 Feature is accepted by QA
👉 Code is in the master branch
👉 Code is deployed to production

Any sprint is considered done when it has met all the conditions and the acceptance criteria. This way the developer knows the end point rather than randomly saying done.

4. Managing Dependencies

Projects have a lot of moving parts and teams that could be dependent on each other’s delivery. Thus it is important to manage dependencies by proactively checking for any obstruction that might surface. Using project management tools like Jira can be pretty handy here where issues can be assigned to each other in the team easily.

The mission of the team should be to get to the most effective order of doing things and complete all the work in a structured manner. Hence, the team should plan and manage your task dependencies effectively.

It is important to communicate dependencies, work out a schedule accordingly, and the project manager to bridge the schedule of the teams. If the dependencies are external, the team needs to take up the particular activity in the sprint only after the dependencies are resolved.

Related Read- 10 Things To Do Right Away Before Starting Your Product Journey

B. Setting Up The Execution

Once the plan is created, the next step is the execution. The day to day activities of the team need to be planned in a way that the feedback loops are smaller, the progress is clear and the final build goes through without a hitch on the release day.
Here is the list of different aspects to set up for your team to build a predictable software delivery.

1. Planning the test process

The testing process should be properly planned and communicated to the team. It should have a well-defined structure and documentation. The plan should be created by the project manager, customer, and the developers together so that everyone has the agreement to the plan.

The testing process should make the boundary cases and test cases clear for the team. This way the developers themselves can test before they publish. There should also be a proper test strategy that defines the approach to test the product and report bugs effectively.

2. Setting up the Release Management

Manual deployment of software carries a lot of risks. There should be a formal release management process that ensures the removal of the majority of manual interference results in the elimination of any blindspot risks associated with the manual controlling of the release process.

Setting up a DevOps cycle helps you set dynamic configuration, run predefined tests, and provides a near-instant feedback mechanism for the team. A typical release management process has 4 environments set up namely development, testing, production, and staging.

Each time code is checked in by a developer, a suite of unit tests automatically analyzes the code quality (as per standards defined by the team) and reports this back, almost immediately, to the developer that performed the code check-in.

Branching can help you accelerate your team’s velocity, make maintenance tasks and feature development easier to manage. It allows developers to work in isolation from the “main source code branch” and there are many branching strategies you can deploy.

3. Using source control

Source control is a good way to track and manage any changes in your code. Source control provides a history of code development and helps in solving issues when versions from different sources are merged. You can even track back to an older version if the newer changes do not work.

Additionally, source control systems like Github and Bitbucket allow easy integrations with other softwares like Jira as well as set a base to create your CI/CD pipeline. Keeping your code on a hard disk or a zip file is a complete no as it runs the risk of losing it. Source control backs up your code and makes it easy to share with different permission settings.

4. Automated Review and testing tools

Automation is the key to remove any delay caused by manual intervention in software development. By using automation tools with continuous integration and deployment tactics, you can do a small and frequent batch deployment. Continuous Integration (CI) and Continuous Delivery (CD) pipeline remove the instances in the software development process where there was any delay caused in the progress. This results in integrating the changes continuously into an application while deploying it as soon as possible. The main advantages include simpler code changes, fewer unintended results, quick fault isolation, lesser resolution time, etc.

Read more about how CI/CD can improve overall quality of software here

We recommend using different tools as per suitability to further make your process independent of human intervention and predictable. Here is a list of tools that we use as part of our sprint cycle.

C. The Team Orientation

While we have discussed the various tools and processes that you can make your software delivery perfect, there lies a big factor that makes or breaks the whole process- The people. Your team is the one eventually to run the process and make it successful. While the tools would help the team to learn and build the direction, it is eventually the team that can make the best out of the process.

1. Managing expectations within the team and customers

Throughout your development cycle, you need to keep the expectations communicated within the team. Right from the start of the sprint, in between, and towards the end.

If you have a sprint that is 2 or more weeks longer, it makes sense to keep sending an interim update to all stakeholders so that there are no surprises on the release date.

Here is a snapshot of the weekly report that we send to our customers at Mindbowser

The more proactive these communications are, the easier it for the team to absorb them and move to alternate plans. Such practices also build up credibility and reliability within the team and the whole project receives lesser shocks.

2. Have a person dedicated to run the process

There has to be a recognized delivery hero within the team whose role is to tie in all the loose ends. As we discuss the different layers of making software delivery perfect, it is useful to have a project manager/delivery lead or with whichever fancy title to take the lead and run the process.

While running the sprint the project manager needs to keep an eye on helping the team slice the backlog items efficiently. There should not be high variability.

The delivery management should be managed with a combination of tools and processes that make the progress transparent and feedback easy to understand.

Maintaining collaboration and sharing of information among the stakeholders is the key to the process. There would be some easy sprints and some very hard sprints along the way. The project manager needs to keep the team aligned and strong as the software grows.

There is a people element into the process as well where the project manager has to ensure that people are motivated enough to follow the process because the process would always fail if people do not follow it.

3. Setting Communication Cadence

Communication is the key eventually. Hence it has to be top-notch. Cadence is just the rhythm and frequency of communication among people. Set out the cadence that works for your team. It can be daily standups or weekly meetings or demo days, make sure that the team knows the cadence set in and the expectations of such meetings.

Apart from the conventional meetings, you can even experiment with a few out of the box meetings such as ‘What the fuck’ meet or the ‘townhall’ meet where you can encourage further communication and exchange. At Mindbowser, we created a monthly Beer talk where everyone would meet over beers and let the ideas flow.

The focus of setting the cadence should be to break silos and allow people to exchange ideas.

4. Create a positive environment

Eventually, work towards building a team that sticks so that processes and work are consistent. Create an environment where people love to contribute and be proud of their work. You can get the best out of people by giving them the opportunity to thrive and the freedom to express themselves.

The Anatomy Of Perfect Software Delivery

Just like a racecar, project teams need to maintain the balance between the speed of delivery and the safety nets like the quality of the project. In fact, quality by itself can make delivery faster by removing repeat work.

After understanding the different aspects of software delivery and the different pieces to make it possible, here is the anatomy of a perfect delivery