In my interview with David, we created a process map of software development at his AWS DevTools team. In this case study, I am going to propose and evaluate a specific improvement to that process.
The improvement area
During our interview, I told David that I thought the work stream unification process during the work definition phase could be improved. The following diagram displays the area I was referring to:
This component performs an important function in the software development process. There are three streams of work coming to DevTools: one for product features, one for company-wide initiatives, and one for cross-team projects. If these work streams are not unified, the engineers will be asking what they should work on next every time they finish a task. This would waste a lot of time. By unifying the work streams into a single prioritized backlog, engineers will always know what to work on next.
Why I chose this area for improvement
There are a few reasons I believe this component can and should be improved.
Firstly, the component seems overly simplistic. Prioritizing different kinds of work against each other is difficult and there are rarely clear answers. I find it unlikely that prioritizing work based on where the work originated will lead to effective results.
Secondly, I see a high value in the improvement of this process. In its existing state, there is no ability to focus the team for a sustained period of time. If the team is working on a project related to a cross-team objective and then a company-wide initiative arrives, the cross-team project will be dropped so higher priority work can be completed. If there is a way to maintain a consistent focus for the team while still unifying the three work streams, that would be a big improvement.
My suggested improvement
I used my software development process improvement worksheet to create a process improvement suggestion. The completed worksheet is available here.
The result of the worksheet is “I suggest that managers, senior engineers, and product managers meet quarterly to unify the work streams in the backlog.“
The expected outcomes of the improvement
The biggest benefit of my suggested improvement is that priorities change less frequently. When priorities change less frequently, developers are more effective, happier, and feel more invested. Slower changing priorities also enable product roadmaps that create an inspiring product vision.
The downside of my suggested improvement is that it increases manager and product manager effort. Setting priorities for a full quarter is high stakes. Although not easy, setting those priorities should lead to a more complete understanding of company objectives and values. I do not see this cost as wasted effort because it can improve manager and product manager communication and alignment with each other and the broader business.
This improvement is good but does not address the root of the problem. Lasting change will not come from individual improvements. The cultural problems that are the root cause will be the topic of my next blog post.