Broken Agile by Tim Brizard

Author:Tim Brizard
Language: eng
Format: epub
ISBN: 9781484217443
Publisher: Apress

Story 6: All Teams Are Not the Same

While not specific to Agile software development, I think having team members who “gel” is more important for Agile teams than for teams using other types of software development methodologies. One of the best Agile teams I’ve ever worked on was cross-functional. The team members really respected each other, worked really well together, and complemented each other’s skill sets. We each knew the others’ capabilities, we swarmed on issues, and we were as close to self-organizing as I’ve seen. This team was very productive, and not surprisingly, the team manager loved to tout our success. As a new project spun up, I was asked to teach other teams “the way we did it.” I worked with some other teams to show them how our team worked with the business, how we ran our meetings, and how we were able to have a good, sustainable cadence.

Management thought that they could clone the success of this team simply by forming new teams with the same number of web developers, engineers, and so on, and have the new teams follow the same processes. But it was not too long after this project started that it was clear that it was not that easy. These new teams struggled to work together in this new way. What made it worse was the fact that when these teams did not become as productive as the team I was on, management was not happy. Not surprisingly, these teams felt the pressure and quickly became frustrated because they felt they were unfairly being compared to the other team—and they were right.

Thoughts

At the beginning of the project discussed in Story 6, I must admit even I felt that we could mimic the success of the team I was on. I had read about the “hidden hand of management” on Agile teams and knew that you can’t just put any group of people together on an Agile team and expect it to work. It takes time and adjustments (sometimes even of team members) to make a team really good. But after the experience in Story 6, what became clear is that there is a huge difference between learning lessons from other teams vs. reproducing the exact chemistry of a team.

So, the bottom line is to learn lessons from other teams. What have they seen go well? What have been their pain points? But teams don’t need to adopt the same culture. As I’ve discussed in Chapters 7, 8, and 18, comparing team velocities is not a good idea. So don’t set up teams for failure by saying “do things like that other team” and just expect to get the same results.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.