Agile and Scrum has many upsides over waterfall. Focus on the backlog, customer involvement, ability to change, and team synergy are among the list of improvements that Agile brings to the table. Unfortunately, Agile does have a few dark sides. I mentioned the potential testing issues in a previous article, but there is another.
The Dark Side of the Backlog
Most good scrum teams have a maniacal focus on processing their backlog, showing a positive burn up (or burn down), and maintaining a strong story point velocity. Maniacal focus is a positive spin on this behavior. However, the danger is that it can be a short trip from maniacal focus to myopic tunnel-vision.
How do you track process improvement work?
Many organizations are reluctant to allocate resources that do not have a direct relationship to customer deliverables. As a result of this reluctance, they often assume that process improvements happen magically through the hard work and diligence of the team members. The unfortunate reality is that these improvements do not often happen under Scrum, and the reason is not due to lazy team members. It is due to the high-level of focus on completing backlog items within a sprint.
Think about it, you spend all of this energy defining and tracking a functional backlog so that the team can focus on it, then expect the other stuff to happen “magically” outside of the Scrum framework. Is there any wonder why they don’t get done?
The Scrum teams are equally frustrated by going through numerous retrospectives to identify improvements, only to see time go by without any change. Depending in the background of your product owner, they may not value this work as highly as customer deliverables. Teams also develop elaborate rules for what type of story is allowed on the backlog. These rules often don’t embrace process improvement work that is not a customer deliverable.
Is it a team or program improvement?
In large programs it is often difficult for a single team to make program level improvements. This is another reason why this work does not get done.
A tool that allows an application team to streamline the process ofgenerating internal regulatory codes is a great example of a team-level process improvement.
Development Operations (DevOps) is a great example of program-level investment that can have a big impact on improving team velocity. You would not expect an application team to take on the heavy lifting of building an integrated build and deploy system for an entire program. Hopefully your program has a team dedicated to this work and you are not competing with customer deliverables for DevOps. Their customer is the development teams and they should act accordingly.
But there are other types of program improvements that may not be getting a voice. Your program reviews and scrum of scrums must provide a means for teams to identify and prioritize program improvements.
Staffing the work
The bottom line is that you need to allocate resources to this work, one way or another. There are several approaches to this. I don’t think it is a stretch to say that in most Scrum teams, if it is not on the sprint backlog it doesn’t get done. With this in mind, the simplest solution is to put these process improvement items on the backlog. Some of the purists that I’ve work may be angry right now, citing the flagrant violation that non-customer work represents. But it is the only way to ensure that it gets done.
Another approach is to allocate a percentage of the team to process improvement work that is not represented in the capacity model. This can work, provided you can track the activity of these resources with clear goals and deliverables. I prefer to use the main team backlog to make this work visible and allow all team members to participate in the process improvement work.
Finally, program improvements must have a “voice” and a way to get implemented. To start, this should be a backlog for the management team and project office. It is there responsibility to prioritize, staff, and implement. This team should manage this backlog as it would external customer commitments.
If you are frustrated by the lack of process improvement in your organization, look at how you are allocating resources to this work and you may find the solution. Program-wide improvements and retrospectives require the same focus as at the team level.