I've wandered off to the Agile track at London's QCon today, and listened to "230 Iterations later" talk by Suki Bains and Kris Lander. Here are my notes from the track:
The main idea was to use example of the team both speakers worked with in past 4 years to show how being agile, focused on good process and delivery can lead to "delivery zombies" - teams that only focus on delivering stories without asking how? and why?
1. They did the right thing at the beginning and it worked well. The team was piloting agile approach in the company, it took on new project, started off with brave decision of building up a new platform as a backend for the new site. Managed to successfully deliver but also to build a "perfect" agile environment, strong foundation for future projects, and a team that felt they work towards common goal.
2. Reflecting now on this time speakers wondered what they mean "good" when they say the team was in a good place back than. Does "good team" mean a team that produces code that provides required features? Is it a feeling that team members have?
3. Thanks to the success the team build up reputation, good relationship with business owners, delivery of features became easy. Shipping became a mesure of success. Some early signs of future problems started showing up: the goals the team had in front of it felt small, the technical debt started building up, the "how?" question being answered the process felt too easy/boring, and the team started making mistakes - slipping. Task weren't always picked up in priority order ("This is first in the queue but it's a lot of front end, I can't work on it"). Sounds scary when I think about my team... :S
4. After 160 iterations the team became a "delivery zombie". Focused only on shipment of the features, not interested in innovation. The office became quiet. Mind that the code was still well maintained, there was high level of automation in the platform. The external test were covering most of functionality (even though they were a "nightmare to manage"), the cost of adding new features were kept down. The code is still considered to be an asset.
5. 176 iterations is a new project is introduced. It's in line with what the team was doing before and they feel confident they can deliver again. The situation changes when the business owners change. The team looses 1-to-1 relationship with product owners, new structure brings on new complexity, and the team can't adapt quickly enough. The feedback loop between development and business is broken and the team loses it's identity.
6. 190 iterations in there are conflicts in the team, there is no common purpose, and people are not working together anymore. The team realises that delivery of the features can't be it's measure of success anymore - they are still delivering, but they can see that's not enough. They struggle to define new goals and values.
7. At the end the projects is still shopped on time, and there is a positive feedback both from business and users. But the team during retrospective doesn't feel successful. The takeaway: vision is important, needs to be reinforced often and on different levels. The team needs to share common values and goals, and needs to understand (and ask) why? as well as how? Keep on asking what it means for your team to be "good", "successful" and "right".
The main idea was to use example of the team both speakers worked with in past 4 years to show how being agile, focused on good process and delivery can lead to "delivery zombies" - teams that only focus on delivering stories without asking how? and why?
1. They did the right thing at the beginning and it worked well. The team was piloting agile approach in the company, it took on new project, started off with brave decision of building up a new platform as a backend for the new site. Managed to successfully deliver but also to build a "perfect" agile environment, strong foundation for future projects, and a team that felt they work towards common goal.
2. Reflecting now on this time speakers wondered what they mean "good" when they say the team was in a good place back than. Does "good team" mean a team that produces code that provides required features? Is it a feeling that team members have?
3. Thanks to the success the team build up reputation, good relationship with business owners, delivery of features became easy. Shipping became a mesure of success. Some early signs of future problems started showing up: the goals the team had in front of it felt small, the technical debt started building up, the "how?" question being answered the process felt too easy/boring, and the team started making mistakes - slipping. Task weren't always picked up in priority order ("This is first in the queue but it's a lot of front end, I can't work on it"). Sounds scary when I think about my team... :S
4. After 160 iterations the team became a "delivery zombie". Focused only on shipment of the features, not interested in innovation. The office became quiet. Mind that the code was still well maintained, there was high level of automation in the platform. The external test were covering most of functionality (even though they were a "nightmare to manage"), the cost of adding new features were kept down. The code is still considered to be an asset.
5. 176 iterations is a new project is introduced. It's in line with what the team was doing before and they feel confident they can deliver again. The situation changes when the business owners change. The team looses 1-to-1 relationship with product owners, new structure brings on new complexity, and the team can't adapt quickly enough. The feedback loop between development and business is broken and the team loses it's identity.
6. 190 iterations in there are conflicts in the team, there is no common purpose, and people are not working together anymore. The team realises that delivery of the features can't be it's measure of success anymore - they are still delivering, but they can see that's not enough. They struggle to define new goals and values.
7. At the end the projects is still shopped on time, and there is a positive feedback both from business and users. But the team during retrospective doesn't feel successful. The takeaway: vision is important, needs to be reinforced often and on different levels. The team needs to share common values and goals, and needs to understand (and ask) why? as well as how? Keep on asking what it means for your team to be "good", "successful" and "right".
No comments:
Post a Comment