Ever notice how some people and some teams seem to thrive in adversity. They seem to be at their best - it's like they're waiting for the chance to show everyone just how strong, how capable they are when the going gets rough. Last year this hit home for me during the NFL season. The New England Patriots, in particular Tom Brady their quarterback, have an extraordinary winning percentage in extreme cold weather conditions.
I'm not a Patriots fan, but I admire their ability to win when it's cold. From NECN.com, "Brady's personal mark is now 19-2 in games played in the snow, ice or below freezing temperatures. He's the best cold weather quarterback in NFL history since 1960," While other teams dread playing in difficult weather Brady and his teammates embrace it and believe they are the best in freezing weather. Their belief is proven over and over as they continue to win.
How does this relate to agile and agile adoption? In my experience, most organizations have circumstances that present challenges to the adoption of agile principles and practices. This isn't new. Your attitude and approach to dealing with the challenging circumstances, may make all the difference in the world. Instead of giving up, embrace the environment as it is knowing that even small incremental improvements will make a difference.
While working with one client, they had two prominent challenges. First, teams were made up of non-dedicated team members and second, they conducted integration and testing at the end of the project. There were other issues to deal with, but those two were the biggest issues we faced.
We started the move to agile by choosing to leave the two biggest problems alone, focusing instead on starting a couple of teams using Scrum. The first two pilots quickly showed how the two big issues were preventing the teams from being more productive. Every iteration we would show managers how the teams did and why the teams were unable to complete all the work selected. Management decided they couldn't change the development team members' allocation, but they would allocate one tester to one project for 50% of her time. With a tester focused on the project earlier, the team could now do better job of testing during each iteration. Positive feedback about the change began to trickle through the organization. For the first pilot projects that's all we got, one tester on one of the teams.
Before we started the next projects we asked for a dedicated team that included a tester. We did this by making the argument that let's just try it for one release, about 6 months, to see how it works. We got mostly dedicated teams and we did get testers from the start of the project. These teams performed better than the previous two and we continued to make incremental progress. It took a couple of years, but the organization began to establish cross-functional product-based teams with dedicated team members and the organization began to see shorter release cycles, from cycles that were at a minimum 9 months down to 2-4 month cycles.
So, don't throw your hands up and say "I give up." Instead embrace your circumstances to see where you make incremental improvements, even it you if can't start out adhering to all the principles and practices. Start somewhere and continue to improve. Don't let people tell you: "You're not doing agile if you aren't ..."
It takes time, effort and most of all patience but it can be successful.
No comments:
Post a Comment