This is a link to an article by Martin Fowler and Jim Highsmith following their signing of the Agile Manifesto: http://www.drdobbs.com/184414755
As I have moved between jobs and also been in consulting at client sites, I have noticed the increased awareness of the Agile buzzword. As much awareness I see, I see the same amount of misinformation.
I have seen two categories:
- The old crusty PMI/mainframe guys who show intense mistrust of Agile. They view our enthusiastic support with the same amused attitude that we show to teenagers who love boy bands - "these kids and their stupid toys" they seem to be saying.
- The new generation developers/project managers/business analysts who are supportive but confused. To them, Agile is periodic delivery of software and a daily status meeting. Managers especially like this. They think - "Boy! I am going to get software delivered every 2 weeks and I can demand what's going on everyday! How cool!". Clearly, they fail to see their responsibility in ensuring that this happens.
I love this quote from a colleague regarding a client - "You can't convince them they are not Agile!".
So, in this blog, I will attempt to articulate the different stages of Agile adoption and the roles/attitudes of personnel I have encountered in my experience. I will use the following roles in my diagrams and explanations.
Agile Champion: The true Agile expert and champion who is attempting to bring about true change.
Analyst/Project Manager: The PMI school adherents who think they know Agile.
Developer: Junior to Mid-level developers who are amenable to adopt Agile but don't know how.
Senior/Experienced Developer: The crusty veteran/mainframe guys.
Senior Management: VP, Director, C-suite officers
Stage I: Pre-Agile
In this stage, the organization is cruising (or not!) along with waterfall and delivering projects with > 6 month timelines for even relatively small efforts. Analyst/Project Manager is aware of Agile having heard it in some training or the other. Developer is also familiar with Agile. Senior Management just wants things done now and without delays.
The diagram shows relative levels of support for Agile in this stage. The Agile Champion is the one with the most enthusiasm and the rest of the company is sort of indifferent to Agile.
Moving to the next stage, the Agile champion is faced with some tough questions. The choices are coerce, enforce, collaborate and to co-opt.
Does he/she approach management to enforce or Project Manager to coerce or Developer to collaborate and to co-opt?
The first instinct is to go to management and in a grand presentation, show-off Agile, bring in an external/recognized export and get them to OK the adoption of Agile. In my experience, this is not only useless but also a sure way to fail. The moment, Senior Management thinks something is going to on to improve delivery, they want it now and are not willing to play their part because they are too busy.
Coercion will not help either because this will quite often incubate a mild to major rebellion among Developers and Senior Developers just because they are coerced and there will also be perceived performance pressures.
So, the best choice is to collaborate and co-opt.
Stage II: Early Adoption
So the Agile champion approaches the Developers first and begins to show them the benefits of Agile thinking. This involves in my opinion Test Driven Development, just enough design and continuous integration. Trying to proselytize without concrete deliverables will only confuse the concept further. So, the collaborate and co-opt phase involves a lot of doing and showing while encouraging learning and practice. Developer ( and usually not the Senior Developer) is willing to try and learn. In most cases, the tools and software are on the Agile champion's personal computer.
As the Agile champion demonstrates TDD and benefits of user scenarios, the Developer slowly begins to voluntarily perform some of the tasks and experience the excitement and joy of having tests to cover their regression testing. Refactoring exercises naturally enhance their just enough design skills and they get more comfortable with talking to the customer or product owner (Analyst).
As you can see, the diagram shows the Early Adoption stage.
What next?
Stage III: Growing Influence
In many cases, if the previous stage was reasonably successful, the Agile adoption has typically gathered mass and moving downhill. This is also the most critical stage in this model. Having established the tools and techniques, it is time to begin driving home some of the concepts behind the actions so far. In most cases, the tools and software are on the team's development server and resources are being shared.
If the Developer is doing his/her job, then he/she is speaking up in requirements meetings asking about developing user scenarios and quick milestones. The Analyst/Project Manager sees that the developers are more into asking the right questions and are forced to find answers and they begin to experience the joy of always talking to the customer and getting feedback and reducing surprises when software is delivered.
So, you can see the growing influence of Agile thinking among Developer and Analyst/Project Manager roles. The customer loves being involved with the developer in refining and validating requirements often. This is the stage when the Agile champion has to formalize some sort of education/training and encourage discussion and self-learning among these personnel. It is important to answer: Why TDD?, Why just enough design? Why refactoring? What is Technical Debt and when to repay it?
This is reflected in the Growing Influence stage diagram. The Agile champion duties are now spread among Developer, Agile Champion and Analyst/Project Manager. It is critical to show positive results in this phase.
More often than not, by the end of this phase the Senior Developer is participating in the Agile adoption out of little choice in the matter. This role has to be managed carefully as they often have the ear of Senior Management and can cause adverse impact to Agile adoption.
One note of caution: At this stage, since Agile is not your official model and many companies are bound by scheduled releases, this may not be true Agile continuous delivery. But, if you have managed to deliver the final product on the scheduled release date but with high quality and high customer confidence of the final product, you have achieved Agile in my opinion. We all cannot be nor indeed need to be Facebook or Twitter or Google and deliver features to production every two weeks. THe goal of Agile is not to achieve this model. Rather, it is to achieve high software quality while delivering as close to customer expectations.
Stage IV: Active Practice
In this stage, Senior Management has become aware of the growing influence of Agile and have seen results. This is the the time to break out the power points and bring in the external expert if necessary to present to Senior Management that Agile is indeed viable and demonstrate your successes so far. If Senior Management sees most of the team willing and active participants, they rarely have incentive to shut it down.
As I said earlier, they usually care about delivering value to the organization's customers as expected.
The Agile Champion's role is reduced to be more of an evangelist in the company and interfacing with Senior Management to promote official adoption.
Stage V: Evangelical
This stage is achieved when the company officially recognizes Agile processes to software development and delivery.Tools and Technologies revolve around augmenting Agile and there is support to buy requisite tools. Potential new hires are evaluated during interviews according to their experience with Agile or willingness to be in that environment. All stakeholders speak and think in terms of Agile processes and are willing to put this at the top of the priority while thinking about delivering value to their customers.
The Agile Champion's role is greatly reduced to be more of an evangelist in the company and externally as the case may be. This role merges into Senior Technical Leadership role either as Senior Developer or Architect depending upon the company's policies.
