Software development best practices that reduce cycle time and lead time

During my tenure as a Software Delivery Director at MHR is when I have realised that lean manufacturing cannot be applied literally to software development. This is when I have started focusing on lead and cycle time together with the software development team to drive change.

During this period we have started to notice what reduces lead time and what increases it. Maxims listed here are not new, they are covered in plenty of Agile and DevOps literature or are obvious if you think about it.

1. Work needs to be planned

Due to the volatile nature of knowledge work as normally there is no “single organisational queue” and very little standard work. It is important that sponsors know what is currently being done, what is going to be done next and what is the long-term vision. Without this top-level agreement, disruption can run havoc across an organisation as work gets prioritised and deprioritised (work swapping).

You know it is got bad when Scrum teams can’t even plan a two week Sprint, or if they plan it and by the end of what they have delivered is a different set of stories as they all got swapped.

Figure 1, optimised by work and not department

For this reason, project management and planning are necessary parts to get an agreement with customers, stakeholders and sponsors. Ideally you want to move your organisation towards figure 1 to remove project management and planning as much as possible (but not completely).

If you are working in a large organisation project management is inevitable even if your organisation is optimised for work. Someone needs to coordinate work that is being done by many teams. This is because work needs sequencing and dependency mapping. What does all of this mean in practice? To reduce disruption and wait time we need to:

• Have a high level broad strokes plan that everyone understands.
• Pull together just enough of a roadmap and backlog.
• Dependencies need to be removed as much as possible so that teams can work independently on their own backlogs and not be part of a project.
• If team dependencies are needed then project’s dependencies and everyone’s contribution must be known and frequently communicated.
• Work needs to be delivered just-in-time. If you are working on something that is not needed right now, this means other work’s lead time is growing.
• If specialist teams exist (component teams) they must prioritise global work over their local work.

To be clear, I am not saying that user stories need to be planned 3 months in advance, that they need to be broken down to a task level and allocated to a specific person with the exact number of hours they have estimated for it. This is extreme and very wasteful. However, another extreme would be if people did not know what is needed of them. There would be no stories and work is swapping every single moment of the day and wrong software is being delivered.

A lot of people don’t find the above exciting, however if you work for a large organisation this orchestration is an absolute must to reduce lead time for work inflight.

2. Commit to less

The simplest solution to reduce lead time is to commit to less work so that there are less things in the queue waiting, that is reduce your work in progress (WIP). This is the hardest thing to do in practice as this involves saying no and creating a slack in the overall organisation.

When I say no, it means no to new work or contracts. Letting go of customers that are no longer your speciality. Saying no to features that don’t seem like a right thing to do long term.

If it is common that your company expedites work to meet a customer demand, then maybe this should be embraced. Create space in teams schedules for urgent work of a certain size. If nothing urgent happens then the team can pick up the next thing off the backlog, otherwise there is space for the urgent work. Generally speaking, it is healthy to create a bit of slack in the overall system so that teams can help each other out day to day. If everyone is high-strung due to over utilisation teams can’t help each other, processes start to erode and lead time starts to grow.

By saying no, focusing and creating slack urgent work can travel through without interrupting existing commitments thus reducing or maintaining lead time.

3. Prioritise global work over local work

This section applies to specialist teams. Across the industry it is common to have Software Architects, Software Principals or a Data Scientist department. Sometimes delivery teams that have committed to deliver something rely on some expert department to help them. It is vital that these specialist teams prioritise globally committed work over their own local work. To achieve this specialist teams should not make concrete commitments or create plenty of slack to avoid local and global lead time increase.

Figure 2, Bruce Almighty, make way for global work over local work to reduce lead time

4. Quality throughout

Bugs can drastically increase lead time due to unplanned disruption. Too much unplanned disruption can erode trust and confidence in the process. It is important to minimise unplanned disruption as much as possible so that it is exceptional. This can be achieved by putting quality in your process and putting quality into your software. This can be achieved in a number of ways. For example, Definition of Done and Ready are checklists that are used to ensure that backlogs and sprints are in the expected state. Having a release pipeline, down which your work travels and gets automatically tested is another one.

Putting quality into your software is covered well in DevOps literature. Key thing is that your organisation iteratively invests into quality as this is one of the key ways to achieve long term predictable and sustainable lead time. If you would like to read more about this topic check out my “stabilise through embedded testing” article.

Conclusion

There are hundreds of ways that lead and cycle time can be reduced. This article does not provide a comprehensive list. However, I would be remiss if I did not provide few honourable mentions:

• “Shift-left testing” to reduce wait time.
• Empowering teams to make local decisions and create knowledge locally to reduce wait time (figure 1).
• Team leaders and managers that are there to resolve daily operational issues to reduce wait, disruption and task time.
• Converting Craft production to Standard work through automation, standards and component reuse to reduce task time.
• Talent retention to reduce task time.
• Microservices for work parallelisation, wait and disruption time reduction.

Has your organisation discovered lead time maxims? If so please leave a comment.