This is the final post in a series about how to get control of distressed projects.
As previously discussed, this project suffered from the fact that tasking and work assignment was done in an interrupt-driven manner. The primary way that we solved the problem of development team members being tasked before they had a chance to complete their previously assigned task was to move to a Kanban pull system. Now the problem became how to get work into the backlog and estimated so that the team could just pull the next work item with minimal interruptions.
Previously, the development team was simply told what work items to work on and when they were to be completed. In addition to the problems associated with the aforementioned interrupt-driven tasking model, developers never took the deadlines seriously because they had no ownership of the work item estimates. The managers making the commitments to the client had no real understanding of how long it would really take to complete the work items so they just told the client what they wanted to hear. This resulted in deadlines that were rarely met. Plus the managers had no credibility with either the developers or the client. By declaring everything an emergency, the managers ended up creating an environment where nothing really ended up getting treated with any urgency.
In Agile approaches, it is essential that the team doing the work performs the task of estimating the work it is being asked to do. Therefore, we had to also ensure that the estimation task itself caused minimal interruption of the development tasks.
If everything is important, nothing is. One of the keys to making a continuous flow, pull system like Kanban work is for everyone on the team to have a consistent understanding of what the next most important work item is. If everyone knows what work item to pull onto the board next, the team does not need to continuously absorb the coordination cost of figuring out what to do next.
The central mechanism for managing the full list of candidate work items is the backlog. The backlog is a prioritized list of all the potential work items that have been identified by the product owner. User stories and defects are kinds of work items. Users and other stakeholders can request any new work item at any point in time. When they do so, those requests go into the backlog. Addition of work items to the backlog will have no impact on the work that is currently being completed on the Kanban board. Rather, the backlog is a holding place for requested work items. New work item requests simply represent a commitment on the part of the development team to have a conversation about the requested change with the requester.
All work items in the backlog are prioritized relative to one another. So the work item at the top of the backlog is the one that has been deemed the next most important thing for the team to work on. What this means is that if the product owner cares about the order in which work items are completed, they are responsible for ensuring that the backlog is properly prioritized. By the way, the relative priority of work items is constantly changing in response to changing business needs.
In the previous post, I mentioned that we revoked the manager’s ability to task developers. The next thing we did was re-purpose the manager role to one of working closely with the client to force them to prioritize the work in the backlog. And yes, they had to be forced to do this since up until that point, they were accustomed to controlling what the team worked on by throwing a tantrum, which in turn exacerbated the interrupts on the development side. This ended up being a full-time job for the manager based on the large number of backlog items and the rate at which the client kept changing their mind about what they wanted next.
One of the rules we put in place was that a work item could not make its way onto the Kanban board until it had been estimated. The reason for this was so we would not compromise our ability to report on the velocity of the team, which fed into our ability to make future commitments based on the prior performance of the team.
Every Monday morning, we held an hour long (time-boxed) estimation session for the team to collectively estimate the highest priority backlog items that had not yet been estimated. The team estimated as many items as they could in that time period. The estimation units were ideal days. The estimates accounted for all the activities on the Kanban board. Previously, what few estimates were done only took the actual coding into account.
By having the entire team do the estimates, they all felt more vested in delivery of the items within the estimated time periods. Since all the development activities were included in estimate it also forced them to understand more about what was involved in their teammates’ roles. It increased their cohesion as a team.
By doing the estimation session at the beginning of the work week, we could get it over with and out of the way so the team could focus on delivery for the rest of the week and not be interrupted to do estimating when they needed to be doing development.
We observed that there is a dynamical relationship between prioritization and estimation because the product owner may choose to increase or decrease the prioritization of work items based on how quickly or not they can be completed. For example, a user story that the client thought was a high priority may end up not being as important once the client learns that they can get four of five smaller stories done in the same time-frame.
Projects get off track, and they get off track for a variety of reasons. Projects that start off using traditional, predictive planning approaches are more susceptible to derailment. This series of posts has presented a high-level approach for containing projects that have become distressed. Some of the methods may seem counter-intuitive such as embracing change instead of trying to control it. Also, the idea of letting the development team pull the next batch of work instead of pushing it to them may seem strange to some.
Using the approaches outlined we were able to turn this project around from one that was on the brink of failure to one where the client was very happy with the quality software of they were receiving and the predictability with which it was delivered. In this example, we started seeing positive results in the first 2-3 weeks. After 8 weeks, the root causes of all the dysfunction on the team had been completely addressed and the team became largely self-sufficient and self-managing.
Equally important, the morale of the development team improved significantly. After years of being beaten down by a barrage of unmanaged interrupts and complaints about the quality of their work they were finally given the chance to prove to the client and themselves that they, in fact, did know what they were doing and could produce a worthy product.
By the way, the best way to keep a project from needing to be bailed out is to employ these methods from the beginning. Kanban is not merely a project recovery tool.
I highly recommend David Anderson’s book on Kanban for those seeking a more in-depth understanding of how to make it work. If you need a partner to help you introduce these methods and make them stick, contact Fountainhead Solutions.