Delivering value through a technology-enabled service to the end user, fast, isn't just a competitive advantage—it is a necessity.
To deliver value fast, workflow needs to be hitch-free—work must move swiftly and efficiently through each stage of the development and post-development pipeline. Minimizing interruptions, reducing waste, and optimizing processes can lead to faster, more reliable software delivery.
In software development, bottlenecks and inefficiencies can hinder progress, leading to longer lead time and increased frustration for the stakeholders, teams, and users.
In this article, we will explore strategies for improving workflow and reducing lead time.
Minimize Work-in-Progress
“When you have competing sources of attention, your task performance is often going to be reduced” (Madore et al., 2020).
Work-in-Progress (WIP) refers to tasks that have been started but are not yet finished. In technology-focused workflows, managing WIP is important due to the cognitive demands of work. Switching between multiple tasks requires re-establishing context and goals, which can significantly reduce productivity. Reducing the number of concurrent tasks improves efficiency while allowing teams to lighten their workload, and have a clear focus on current tasks.
Teams can actively reduce WIP by making work visible and enforcing an upper limit on tasks. For example, a team struggling with context switching and feature bloat can utilize WIP limits, the team can set a WIP limit of 3 tasks in the "In Development" column of the Kanban board. This ensures only three features are actively being worked on at any given time.
The key lies in striking the right balance with WIP limits. Setting them too low can stall productivity, while excessively high limits can lead to scattered focus and hinder productivity. Teams should actively analyze their workflow and team capacity to determine the optimal WIP limits that unlock their peak performance.
Visualize the Workflow
(Source: Andrey P., 2023, Agile Business Team Using Kanban Task Board, Unsplash, https://www.istockphoto.com/photo/agile-business-team-gm1458140561-492776632)
In technology, work can often be invisible, so making tasks as visible as possible is necessary. This transparency helps teams pinpoint roadblocks and identify areas where work is accumulating.
Visibility's power lies in its immediate impact on team dynamics. When tasks are made visible on a shared board such as a Kanban, teams gain instant clarity: everyone readily sees what needs to be done and who's assigned to which task.
Naturally, our brain excels at processing visual information, Kanban capitalizes on this, by creating a visual representation of workflows. It maps different work stages to columns on a Kanban board (physical or electronic), and work items are tracked as they progress through them.
Work (represented by cards) progresses from the left of the kanban through the workstations (columns) to the last column on the right, usually marked as "done". Your definition of "done" should be when the service is safely running in production and delivering value to the customer, not just when development is complete.
Shrink Batch Sizes
In any process, a batch refers to a group of tasks or work items that move through different stages together. The size of a batch determines how many items are processed at once. Large batch sizes automatically mean more WIP.
Let's take a look at the negative effects of working with large batch sizes. For example, imagine a team that is developing enterprise software. They gather features and bug fixes throughout an entire sprint before releasing them all at once as a major update. This approach of handling a substantial batch size brings about several challenges:
Complexity and Risks: Integrating numerous changes simultaneously increases complexity and makes it harder to pinpoint problems when they occur.
Delayed Feedback: Feedback on individual features is delayed until the entire batch is released, postponing the identification of potential issues.
Increased WIP and Lead Time: Working with large batch sizes means more WIP and longer lead time.
Why work in small batches?
Faster Feedback: Smaller batches allow for quicker deployments, enabling earlier feedback on features and improvements.
Reduced Risk: With smaller batches, issues are easier to identify and isolate, reducing the overall risk of the project.
Fewer Conflicts: Smaller batches naturally lead to fewer conflicts between different parts of the work. If conflicts do arise, they are easier to pinpoint and resolve.
Other Benefits: Faster code reviews, reduced cycle time, quicker learning from failures, and more.
Continuous deployment is a strategy that perfectly complements small batch sizes. In this approach, each code commit is automatically tested, staged, and deployed to production. This allows for frequent deployments and near-instantaneous feedback.
Decrease the Number of Handoffs
A handoff refers to transferring ownership or responsibility for a task from one team to another.
Excessive handoffs can slow down the development process, as teams must wait for other teams to complete their tasks. When one team makes a request, the receiving team adds it to their backlog, until they are able to attend to it. This can delay progress.
To remedy this, create a cross-functional team of Developers, Designers, QA, InfoSec, Operations etc. This team shares responsibility for a feature from its design, development, and testing, all the way through to when it is safely running in production. This reduces the number of handoffs between different teams and fosters a sense of shared ownership.
Conclusion
By visualizing your workflow, limiting work-in-progress, reducing batch sizes, and minimizing handoffs, you can create a more efficient, productive, and harmonious development environment. These practices not only accelerate the speed of delivery but also improve the overall quality of your product and team performance.
References
Madore, K.P., Khazenzon, A.M., Backes, C.W. et al. Memory failure predicted by attention lapsing and media multitasking. Nature 587, 87–91 (2020). https://doi.org/10.1038/s41586-020-2870-z
Top comments (0)