In software development we want to create the most value as fast as possible. Most bang for the buck. Little's Law states:
Lead time = Work in progress / Throughput
Lead time is the time spent from "ordering a new feature" until it is shipped.
So to ship a feature quickly we need to reduce the work in progress or increase our throughput. Let's focus on reducing the work in progress for now.
I attended a workshop for tech leads a couple of weeks back. There were around 90 senior software engineers in that workshop. A couple of hundred years of experience in one virtual room. Really nice!
One small exercise of the workshop was to list all causes of work in progress to increase. In other words, all causes that slow down software delivery. For me this is a gold mine of information. I took all the sticky notes in that Miro board and grouped similar causes together.
The biggest cluster by far was Management related causes with Changing Requirements being the number one cause with 24 mentions, followed by Changing Priorities with 17 mentions. The third group in the Management cluster was unplanned work that was added to the developers' plate by management with 13 mentions.
The second biggest cluster was the Setup of the Organization"with the groups External Dependencies (16 mentions) and Code Review / QA process (14 mentions).
Bugs in the production system (mentioned 12 times) was also a bigger group.
The smaller groups were Communication (7 mentions), Sickness or PTO (7 mentions), and missing Skills (7 mentions).
One interesting group was the group developers starting new task before finishing current task (8 mentions). This was also mentioned as the outcome of other causes. (For example: If people have to wait for QA, code review or external teams/stakeholders, they start new tasks)
For me the two big insights on how to speed up delivery are:
Reduce waiting times as much as possible, because it leads to people starting more tasks than finishing. (Which is kind of a no-brainer...)
Every software engineer in the organization should hold management accountable (and help them) to decompose work items into manageable well understood chunks that stay relevant for at least as long as it takes to implement them.
It was really fun to have all this data about what slows down delivery from a big group of industry veterans.
Wanna dig into the data yourself? Have a look at clustered sticky notes from the workshop that I used as foundation for this short blog post:
