When you’re getting started with Agile development you need to pick some methodology to get started. Just getting that far is a huge step forward to being able to continually adapt to changing customer needs. Just like a system under development, be prepared to continuously evolve and adapt the way that the team works and consider the process itself as a work in progress.
I say this because I’ve seen enough projects that try too hard for too long to force a process to work even when the evidence tells them that it may not be a best fit for the team. This ends up causing the development team and the customer to get frustrated and miss out on the benefits they adopted Agile for in the first place.
High performing teams and their managers are honest with themselves about when something is working well and when it is not, and they adjust course accordingly. This requires both a high degree of collaboration and trust among team members as well as the discipline to make decisions based on project metrics.
One project I worked with decided to adopt the Scrum methodology. The team was geographically distributed across two time zones three hours apart, so team members’ real-time communication was limited to phone calls. Most communication was via email. So there was a high degree of coordination cost on the project. A traditional project manager was sent to scrum master training. The team used all the buzzwords and went through all the prescribed motions of daily stand-ups (albeit sitting down), backlog grooming, and tracking task burndown. They chose a 2 week sprint duration.
However, something was very wrong. The team never delivered the stories they committed to at sprint starts. The software quality was terrible and getting worse. The developers blamed the testers for the quality. The testers blamed the developers. The scrum master blamed the product owner, the developers, and the testers.
When I showed up, the state of this project was that the team was now spending the vast majority of time fixing bugs and not developing new features. They were way behind schedule and over budget. Product management had no confidence in the team’s ability to deliver the product.
Yet they were all still clinging to the same way of working!
A series of project retrospectives revealed, among other things, the following:
- Inconsistent understandings of acceptance criteria between developers, testers, and product owner;
- Insufficient testers staffed to keep up with pace of new code production;
- Initial and work-remaining estimates for tasks were completely unreliable leading to task burndown that was not meaningfully correlated to story burndown;
- Team members were pushed tasks by managers way ahead of those team members’ capacity to take on new tasks, which led to team members doing a lot of multitasking.
Given these observations in context of the team working environment, it started to become clear that Scrum might not be a good fit for this team. So we asked the team to try some experiments.
First, we took on the misaligned expectations item by getting developers, testers, and product owner working together on specifying the acceptance tests before starting development. This, in itself, had a profound transformative impact on the team dynamics. Obviously it helped clear up what was required for a story to be done, which gave the developers a better defined target to work toward. More importantly, it got team members collaborating that previously did not. Each of these team members brought their unique perspective to bear on how to implement the story. At times, this ended up resulting in stories being changed, where before they were taken as gospel without many questions being asked and a lot of assumptions being made. Where testers were previously on the receiving end of untested code, they were now participating in the creative process early on. This ended up boosting morale of the team.
After we experimented with putting tests first on a set of stories, we observed that the testers were still struggling to keep pace verifying stories after development. We also observed that developers would “work ahead” on story development if a tester and product owner was not available to participate in up-front test development. Test activities were still a bottleneck on the project.
To address this, we decided to try Kanban to limit the amount of development work that could be in process. At first this was very frustrating to the developers. The feeling was that they were being held back from producing lines of code at maximum velocity. Here’s what they were missing: quality is the entire team’s responsibility – not just the testers. Within 2-3 weeks the team started to self-organize to even out of flow of work across the Kanban board. Developers started chipping in to define tests and verify other developers’ stories.
The team was able to dig out from under most of its technical debt, and they are now delivering features on a more predictable cadence. It is a much healthier project. The Kanban approach eliminated the need for team members to be tasked with work. Team members pull stories based on their capacity to do so. This has eliminated a lot of wasteful management overhead.
What about the unreliable task estimates and burndown? Turns out breaking work items into tasks and providing fine-grained estimates was complete waste. So the team doesn’t do it anymore. The tasks to be performed are codified into the columns on the Kanban board, and everyone can see at a glance whether items are moving across the board or not. When work items hit up against WIP limits, the team members swarm to unblock them and keep things moving.
The team has continued to make improvements. For example, they added pending states to the Kanban board such as “Ready to Code” and “Ready to Verify” to decrease the coordination costs associated with their distributed nature.
The above case study demonstrates a team’s ability to adapt the way they work to address challenges they are facing. This example was somewhat extreme in that the team changed their entire methodology from Scrum to Kanban. In most cases the adjustments will be less dramatic. The point is that the team’s ability and empowerment to make those adjustments is one of the most critical factors in their success.