This is the final post covering how one of our software teams made some modest changes and went from struggling to high-performing, all within a short period of time.
Understanding the requirements was the first important improvement. The next two improvements related to estimating and collaboration – beyond the improvement already achieved between the product owner and the team.
One clear reason that this team struggled with meeting its dates was because they were underestimating. A good understanding of the features (backlog) and streamlining some of the tasks helped, but they needed to make a couple of other adjustments.
The first was that there was no team estimation process. For example, individual developers would go off and determine estimates for the items that they planned on – or thought that they would be – developing. They also were estimating work in fairly significant (for Scrum) chunks of time. I asked that the team use tasks that were no greater than 2 days in size, and that they collaborate and discuss their estimates.
I’m a big fan of team estimation, and the experience with this team supports this concept. Once the developers began discussing their tasks collectively and exploring how they were going to approach each user story, they gained a much greater understanding of what was truly required. The combination of smaller task sizes and greater collaboration increased their confidence that they could meet their objectives.
As the team saw the benefits in collaboration as part of their planning and estimation process, they were receptive to moving towards greater team collaboration across the board. While the team was using Scrum development, it really looked like a mini-waterfall project where Quality Assurance would develop test plans and would wait for Development to be complete before any testing would begin.
Over a period of a few weeks or so, the team moved towards collaborating across the board. For example, each time a developer finished even the smallest piece of functionality, he reviewed it immediately with QA. And if the team encountered one of those inevitable “we didn’t consider this” scenarios, the team huddled together to discuss what that meant to the user story, to their acceptance criteria, and their commitments.
Did you catch the subtle change? The team took ownership. It wasn’t QA’s acceptance criteria, it was the team’s acceptance criteria. The team also started collaborating this way on their own; they had seen the benefits of collaboration and embraced it.
This team moved from merely performing individual tasks to being an engaged, motivated, collaborative team. They started to own all aspects of their work – as a team. As they moved from being a collection of individuals to a true team, you could almost feel the spirit and the flow. The output of the team visibly increased, overtime ceased, and everyone looked much happier about their work. Being successful will do that.
Looking back, I got a little lucky. One of the factors in this team’s rapid success was the willingness of the team to try new things. They were competent professionals, but they were unable to implement the key concepts of Scrum development – despite the fact that they intellectually grasped what “it” was.
Sometimes people get set in their ways or lack the ability to see how to apply concepts in their day-to-day work. Changing methodologies can necessitate changes in expectations, and these new expectations must be clearly communicated. Other times, people are simply skeptical.
In our case, it was a combination of factors that included some skeptics, but they put aside their skepticism and tried something new. And they ended up loving it. It was a pleasure to be a small part of this, and definitely one of those "Yes!" moments to see them succeed.
Thunderbolting Your Video Card
20 hours ago