-
RespectJurgenAppelo
-
The only thing your postpbielicki
-
Epics are just big fat storiesArtem
-
Releasesmattgrommes
-
I thought, Small Releases, was also missing, was it?Vikas Agarwal (not verified)
This survey was conducted and sponsored by VersionOne in June and July 2008. It received answers from 3061 participants in 80 countries; most of them (70%) were participating to the survey for the first time. The majority of the respondents were agile team leaders, coach or consultants. This could lead to a bias towards a perhaps slightly more optimistic vision of the reality of agile projects. Whether they are agile or not, managers stay managers ;o)
I recently had someone pose a question to me that got me thinking about the scalability of agile success. Here was the question: "I'm part of large organization of over 1,000 people. Our small team of 40 has been using agile with a great deal of success. Now our company wants to me to extrapolate the successes we've enjoyed from agile (efficiency, value, profitability) to the rest of the company. Do you think the agile success of 40 people can be extrapolated to over 1,000 people?”
It's a great question and I don't think there is an easy answer to it. Speaking from my own personal experience, it's been difficult extrapolating the success our small team of five developers had in the past to our larger organization of about 35 people. There are many challenges as you scale agile up. Agile practices depend heavily on collocated teams that are cross-functional in nature. When you start scaling agile up, you need to consider geographic dispersion of much larger project teams that may not be as cross-functional as you'd like them to be. This is just the nature of large organizations.
Lately I've been hearing feedback from lots of different people that they've "adopted" agile and it's just not working for them. This always causes me to pause, step back and ask a few questions. Here's the list that usually runs through my head: How did your company adopt agile: top down mandate or grown organically? Was your adoption done in stealth mode or full fledged "Hello world, we're going agile"? Do you have real executive support for your agile adoption? What kind of projects have you implemented agile on: fixed price, fixed scope, fixed schedule? Has your staff received any kind of agile training? How many projects have you run in an agile manner? How long ago did you start doing agile?
I run through these questions because I think each one represents a potential failure point for agile adoptions. Let's take a look at each one.
Working really hard on low priority items can be useless to the point of killing the company
Efficient Resource Utilization
Many teams start using agile methods while being highly specialized, that is team members are typically responsible for a particular component or area, that other people don't really understand. Developers often "own" their components and all the fixes go through them.
Agile processes often enter the organization from the grass roots - from the developers appreciating useful practices and insightful low level managers seeking for ways to help their subordinates. However, if things progress well, at some point the top management might buy the idea of delivering incremental software faster, than the competition, and declare "we are going Agile" or even "we are going AGILE". While the top management support is something to appreciate, there is still a number of issues to be aware of, when restructuring mid to large size organizations. One of the most important changes is the potential career ladder restructuring.