Martinig & Associates Methods & Tools group recently updated their agile adoption survey and compared their results to their initial inquiry back in 2005. They asked a single question: “At what stage is the agile approach (XP, Scrum, FDD, …) adoption at your location?”

The results indicate a two-fold increase in awareness of agile methods (26% in 2005 to 13% in 2008 not aware if agile methods) and a two-fold increase in all projects deployment using agile methods (8% in 2005 to 17% in 2008). The complete results are shown in the table below and can be found on their website.  I have summarized the data in the chart below…

Is this good news?

While their findings show that agile awareness and adoption are on the rise, their findings also come with a warning…

“The recent improvement in agile software development process visibility and acceptance should however make us cautious with the current results on agile adoption surveys. When software development practices are more widely accepted, the number of adopting organizations increases, but the substance of valid usage of this practices decreases. The answers to surveys tend then to be biased towards what should be the correct answer instead of reflecting the reality of the software development context. The tendency of upper management to “push” new approaches to people who are more reluctant to change their old habits does usually not produce good results. This is even truer when projects will not be given additional resources to support the transition.”

So what does this mean?

This means that the rise in agile awareness and adoption will coincide with a rise in a veil of “agility” covering almost anything - including traditional software development methods. I agree with their observations and see this in practice quite often with companies that I meet. With the increase agile awareness has come an increase of agile perception. Many companies claim to be agile, or to be using agile methods, but often fail even the most basic tests of agility like the Nokia Test developed by Jeff Sutherland.

Why does this happen?

There are a number of reasons companies fail to walk the talk of agile. For one, it’s hard. It requires discipline and forces roles who typically don’t work closely together to collaborate frequently. It compresses an entire software life-cycle process into a very short and sometimes intense time period. Secondly, it’s adaptable. Teams often struggle with basic concepts and then using the inspect and adapt framework will throw away the core practices veering away from agile principles. Third, aligning organizational structures is difficult across many inter-dependent teams, locations, and disciplines.

In some upcoming blog posts, we will dive further into the assessment framework of agile to help teams understand how to properly assess their agility and adapt without straying away from the agile principles.

Dean Leffingwell, the author of the recent book, Scaling Software Agility: Best Practices for Large Enterprises (http://scalingsoftwareagility.wordpress.com) and I have been discussing strategies for enterprise-wide agile transitions in preparation for helping a significant software business contemplating just such a move. Dean and I have multiple experiences with enterprise-scale transitions. Dean provided leadership guidance to BMC Software as documented in the Agile Journal case study – How BMC is Scaling Agile Development. I guided an enterprise-scale transition with Salesforce.com as documented in their experience report Large Scale Agile Transformation in an On-Demand World presented at Agile 2007. Salesforce.com is the first recorded “all-at-once” transition of its size and was recently highlighted in an article by Mike Cohn on various approaches toward agile transition in the Agile Journal article Patterns of Agile Adoption.

We are now collaborating to identify the training and consulting patterns that can be applied for a, rapid enterprise-scale adoption (enterprise-scale: an agile transformation that will impact many hundreds, and potentially thousands of practioners in a time frame of less than one year.) Since there are a number of new team-based and organizational practices  that must be mastered for a successful enterprise transformation (refer to Dean’s book) we’ve identified  three key transition mechanisms required to facilitate practice adoption and fan out a consistent, effective and disciplined process across the organization. These are 1) the establishment of an internal agile enterprise transition team, 2) an agile training program reaching most practitioners and 3) and effective coaching and mentoring program.

First, and foremost, the creation of an internal agile enterprise transition team drives the enterprise vision for the agile transition and also facilitates its implementation. Implemented properly, it re-orients the transition from a top-down mandate to a middle-out and bottom-up buy-in of the impending change. Transition teams are not a new concept and have been well documented by William Bridges in his book Managing Transitions: Making the Most of Change. More recently, Ken Schwaber has written about the importance of a transition team for large-scale Scrum adoption in his book The Enterprise and Scrum. We will write more on our experiences incorporating transition teams in upcoming posts.

Secondly, shared-learning achieved through outside training is a critical success factor in an enterprise-scale transition. This addresses the basic need for understanding, mastery, consistency, and coordination of the many new techniques across the multiple interdependent teams that are necessary to deliver large-scale business solutions in a substantially agile manner. Due to the self-organizing principles of agility, teams can (and will) eventually adapt the initial practices to better suit the needs of the organization.  Building a common vocabulary and understanding of the principles behind the practices first will help align the whole organization and drive a consistent, yet truly agile approach. Dean and I provided a team and role-based framework for this training in Dean’s recent blog posting – Ideal Training for Enterprise-Scale Agility?

Last, but not least, is the need for experienced agile mentoring and guidance. While training is necessary for an enterprise consistency and understanding of agility, it is not sufficient.  Training is often separated from the reality of the environment and project issues teams face. Moreover, fully leveraging an ideal training scenario is not always practical and gaps in understanding as well as practice will certainly remain. This is the main driver for the third mechanism, facilitating an engagement with experienced, outside agile mentors.

Experienced agile mentors help teams solidify their understanding of agility and its principles through repeated practice. Agile mentoring facilitates process adoption by leveraging experience from other organizations that have already walked that path. Mentoring guides process, product, project and functional leaders through their changing roles and responsibilities. Mentoring also assists with the organizational alignment in creating dedicated, focused and high-performing teams.

A single-tiered mentoring model, used in most small and mid-sized agile transitions, leverages one or more outside agile mentors to guide individual teams. This provides a direct and proven knowledge transfer mechanism that are effective for small and midsize organizations. This approach eventually supplies the organization with a number of internal agile team leaders, and has been effective at smaller scales. At enterprise scale, however, it may be prohibitively expensive (requiring a substantial number of outside consultants) and too slow for large-scale enterprises that want the benefits of agility (higher quality, better responsiveness, improved morale) sooner, rather than later.

To date, larger enterprise-scale agile transition models have primarily been phased in over many years, essentially building on top of many smaller-scale pilot projects and transition efforts. British Telecom is one such example as recorded in their 2007 Scrum Gathering presentation – Scrum@BT. Geoff Watts and Paul Goddard write that their organization has been transitioning to Scrum since 2003, when they certified their first ScrumMaster.

Having guided both incremental and all-at-once transitions, there is a compelling corporate synergy, alignment and focus that occurs when an organization attacks a problem all-at-once. The shared focus and experiences more quickly surface organizational issues and impediments and leadership is more acutely aware and prepared to respond. The organization moves much more quickly through the discovery phase and into a delivery and adaptation phase of the transition. The leveraged mentoring model that we propose as presented in Figure 1 below provides a less costly and more rapid transition while equipping the organization with agile leaders who are capable of supporting and guiding its ongoing evolution and adaptation. 
 
 

Figure 1: An Agile Coaching Model for an Enterprise-Scale Transition

Unlike single-tier coaching models and longer-term phased transition models, this model introduces internal agile coaches at the outset of the transition. By developing internal agile coaches early in the transition process and actively engaging them throughout the training and early mentoring activities, they have an opportunity to develop the skills necessary to introduce and transition other teams within the organization, and over time displacing the external agile mentors used to seed the transition. The experienced outside mentors act as the initial catalysts for change, whereas the agile coaches provide the ongoing support, consistency and growth for the agile adoption to embed into the culture of the organization. Moreover, it’s likely that these internal coaches will have an understanding of the issues and challenges the teams face internally, and in the marketplace.

In other words, another benefit of this, model is that it provides a proving ground for the future leaders of a truly agile enterprise.

Dean Leffingwell and I were formulating a training strategy for a significant enterprise that is contemplating an “all in” (immediate and across the entire company) enterprise scale transformation approach. Based on my experiences at Salesforce.com and his experiences at BMC Software, as well as some of our larger, ongoing clients, we had a chance to reflect on what we would recommend as the “right” amount of training to ensure success. We concluded that for the enterprise, a combination of team-based and role-based training that would touch every practitioner is ideal.

Read more on Dean’s posting Ideal Training for Enterprise-Scale Agility?

I have also written a follow-on looking more deeply into the coaching strategies for such clients in my subsequent post - An Ideal Coaching Strategy for Rapid Enterprise-Scale Agility?

Welcome to the latest edition of the Carnival of Agilists - the rotating agile blogroll guiding you to the active voices in the agile community. In this edition we take a look at self-organizing teams, lean methods and a variety of other topics. Enjoy!

Agile Leadership?

We start this carnival with that famous agile leader - Dilbert’s boss! It is hard to determine what is more detrimental to an organization trying to be effective with agile methods - the belief that agile is about no planning and documentation, the belief that it is easy and requires so little education and experience to be effective, or that leadership is clueless about either.

Speaking of leadership, Jennifer Fawcett has started a new blog - The Agile Product Owner. Check out her recent post: Applying Agile Product Ownership within TeamsEnterprise Product Manager=Agile Product Owner…I don’t think so… OK, so the title is a bit long. I thought agile was about less documentation, at least that what Dilbert taught me

David Alfaro has a new blog - Scrum Costa Rica. Through the help of Luke Hohmann and Stacia Broderick, he has blended the art of product roadmapping with the adaptive approach of Scrum in learning that Agile is about Reality not Fairy Tales.

Lisa Haneberg reminds us that leadership is sometimes (mostly) about deflating that ego and actually meeting people where they are at rather than just plowing ahead in your own way. It is amazing what you can accomplish when you can Partner Better with Peers - Here are Eight Ways.

Can Agile Fail? You bet!
Sometimes our agile community has its rose-colored glasses on too much. We can learn alot more from failure - That’s why reading Dilbert is so helpful. Here are a couple of top-notch coaches providing us some real-world failure views…

Sanjiv Augustine counts 11 Ways Agile Adoptions Fail that all leaders should be aware of in guiding their agile transitions.

Joe Little knows something about failure too. In fact, he knows so much he had to split it into two blog postings in his Top Enterprise Impediments Part I and Part II. It’s better to know where the landmines are rather than stepping on them.

Michael James: Simple = Scrum. Not Simple = Analysis Paralysis = Failure. He’s right. Keep it simple.

Speaking of failure, contracts are a great way to fail - if you don’t know what you are doing. Didn’t the Agile Manifesto say something about Customer collaboration over contract negotiation? Someone better tell Chris Spagnuolo - he has gone to the dark side in creating a place to discuss Agile Contracting at Agile Commons and the Agile Development Practices Conference.

Agile Practices

• Dave Nicolette provides a number of helpful keys and links on TDD at XP Days Germany.
• Johanna Rothmann guides us in Using Multiple Life Cycles in Combination on a Project Part I, Part II, Part III
• Mike Griffiths provides a very detailed analysis of Agile Estimating Approaches

Previous Editions
All previous editions of the Carnival are referenced at the Agile Alliance website.

Join in the Fun!
Have something that you think is worth sharing? Don’t be shy! We love new ideas and insights. Send us a link to your post at agilists.carnival@gmail.com. Future editions will be on the first and third Thursday of each month. If you would like to participate, please send us a link to your post at mailto:agilists.carnival@gmail.com Or, if you prefer, use this handy dandy carnival submission form.

It is hard to determine what is more detrimental to an organization trying to be effective with agile methods - the belief that agile is about no planning and documentation, the belief that it is easy and requires so little education and experience to be effective, or that leadership is clueless about either.

David F. Rico has released the results of a 3-year study evaluating the Effects of Agile Method on  Website Quality for Electronic Commerce (ppt or pdf). You can find a reference to this work and others on our Surveys and Studies page.

This new study breaks ground in a number of areas including its indepth research and presentation of related literature and the creation of a new conceptual model to measure agility across multiple agile methods. In summary, he found that 80% demonstrated a correlation between agile methods and website quality. However, you should dive into the report yourself as there is a tremendous amount of valuable information presented.

To contribute to his ongoing research, you can fill out his online survey.

I recently completed Patrick Lencioni’s Literary Fable entitled Death by Meeting. If you haven’t read it, it is worth an afternoon. It is written as a literary fable so it is a quick read. In it, Lencioni highlights the ineffectiveness of meetings and how it drives an ineffective corporate culture. He highlights two primary issues with meetings in most organizations - the lack of conflict and context.

While the conflict side is interesting, I want to highlight meeting context and its relationship to Scrum. Lencioni states that most leaders have one kind of meeting - the staff meeting. I can attest to this in my previous role as a leader. The problem is that everyone in the room has a different agenda with respect to what they want from the meeting. Some are looking for coordination details, others tactical information about current projects, and yet others looking at strategic decisions. Attempting to address each of these in the same meeting leads to incompleteness in all of them.

Surprisingly, his proposal is to actually increase the number of meetings - not decrease them as you might expect. However, each meeting requires a distinct and appropriate context. Hold a short 15 minute meeting daily to coordinate activities. Hold a 1 hour weekly meeting to address tactical issues. Hold a 2-4 hour meeting each month and a 1-2 day offsite meeting each quarter to address strategic issues.

Does this sound familiar? Sounds like Scrum to me. Hold a daily 15 minute Scrum of keep everyone on the team in sync. Every couple weeks hold sprint planning and review meetings to address the tactical focus for the product. Every few months hold a release planning meeting to focus on the strategic product direction.

Some would say that Scrum is common sense - it is doing the simplest thing to get results. I agree and I think Patrick Lencioni would agree as well. So if you have some business or executive stakeholders who may not quite understand Scrum, introduce them to this book first, then begin to compare approaches. Sometimes coming at the problem from a non-agile perspective is the best way to influence those with agile filters on.

If you have read the book and agree or disagree, I want to hear about it.

Welcome to the latest edition of the Carnival of Agilists - the rotating agile blogroll guiding you to the active voices in the agile community. In this edition we take a look at self-organizing teams, lean methods and a variety of other topics. Enjoy!

Self-organizing Teams 

Jim Highsmith recently sent out an Cutter Email Advisory entitled “No more self-organizing teams“. Jim feels the term “self-organizing” has outlived its usefulness within the agile community. He believes it gives agile a bad perception as it is too often equated to “anarchy”. He points to Sanjiv Augustine’s term “Light Touch” Management in his new book and blog post on “The Role of the Project Manager“. Many others, including Tobias Mayer, disagree with Jim and Sanjiv representing the necessary language change required to get companies to make the 180-degree change required for agile to be successful - otherwise you just have a “watered-down” agile (pun intended). You can read Tobias’ view here in “No more self-organizing teams. Not.” Hard as it is to believe, I find myself on Tobias’ side of this argument - a change in language is required. Read and decide for yourself the many posted comments to Jim’s original posting.

Lean

Aaron Sanders wonders whether estimation should be considered a waste in an agile process in his post entitled Naked Planning Explained - Kanban in the Small. Interesting thought. I have been working recently with more flow-based teams who think similarly. They believe that late commitment is more efficient and effective than early commitment in a sprint. They claim higher performance with better quality because they don’t have the false commitment over their heads which gives them more time to focus on doing things right. However, there has been one consistent attribute of teams executing this type of approach - they are more mature in breaking down work more granularly and have more built-in discipline than other teams.

David Anderson looks at lean in a slightly different angle in his post Lean Scales Differently than Agile. In this case he is focused on the scalability of the team with respect to the daily standup meeting. He indicates effective daily synchronizations of upwards of 20 people focused on Kanban work. My experience tells me that team collaboration breaks down after about 10 people, but I am always open to learning new things. Read his post and see for yourself.

Other Topics

Michael Vizdos portrays an excellent three-part series of posts on retrospectives in his unique style. Check them out - Part I: The Scary Team Retrospective, Part II: Beyond the Book Retrospectives, and Part III: Walk into the Light.

Dave Nicolet evaluates the Cutter Report on Enterprise Architecture and agile methods and thinks the authors should have taken one more step in the organizational alignment - I agree. Was Dave listening in my NFJS course on Agile Enterprise Architecture (sorry, shameless plug) or is he just a smart guy? You’ll have to ask him, but first read his analysis of the report.

Mike Griffiths has an excellent post on Developing Authentic Leadership. Some of my favorite quotes include “Leadership can not be taught, but it can be learned” and “Managers use people to accomplish work, leaders use work to grow people”.  Thanks Mike.

Sanjiv Augustine has a great agile business perspective in his post 5Qs on Agile. Next time your in an elevator with your CEO, you can use some of this wisdom to stand above the rest.

Chris Spagnuolo has some great ideas to clean up that leftover debt in The Bug Bash Sprint. Debt is still a killer issue for most teams.

Previous Editions
All previous editions of the Carnival are referenced at the Agile Alliance website.

Join in the Fun!
Have something that you think is worth sharing? Don’t be shy! We love new ideas and insights. Send us a link to your post at agilists.carnival@gmail.com. Future editions will be on the first and third Thursday of each month. If you would like to participate, please send us a link to your post at mailto:agilists.carnival@gmail.com Or, if you prefer, use this handy dandy carnival submission form.

Clarity, Movement, Alignment, Focus

This is the premise of a book called Simple Church. While Simple Church has nothing to do with agile methods, it has everything to do with agility. Its research indicates that most churches are weighed down by all of their various programs and fail to reach their goal - to grow disciples. The multitude of programs they are creating to increase participation and growth are the very thing that are preventing their growth due to fractioning and defocusing people on too many varying objectives. Each program fighting over the same limited resources. Each program success being measured by its own attendance. The programs become the focus. The overall goal is lost in the mix.

This is true for corporate organizations as well. Most organizational processes are not simple, clear and aligned directly to their primary goal, and often they are struggling to achieve it. And as organizations fail to achieve their goals, they often add additional processes and structures to fix it. Layer after layer, new processes and structures created for the purpose of reaching their goal are in fact serving to do just the opposite - they defocus an already overloaded organization with more work on processes and communication taking away from their true goal - in this case, to deliver value through software. This negative reinforcing cycle creates increased busywork and waste. In the end, the process itself becomes the goal.

Simple Churches are successful and growing. A Simple Church has a clear process that is easily understood which moves people toward discipleship. It aligns all of its ministries around this process and abandons everything else that falls outside to focus on the goal. Simple Churches have clarity, movement, alignment and focus.

Organizations who implement Scrum are growing and successful too. Primarily because Scrum provides clarity, movement, alignment, and focus. Scrum is a simple process framework that is clear to understand by everyone in the organization. It uses simple language, simple artifacts, simple meetings, and simple roles. Scrum creates movement of the most-valued product solutions delivered for the business. Scrum helps teams deliver early and often for rapid feedback and alignment. Scrum creates cross-discipline teams from multiple functions throughout the organizations aligned on this shared goal. Scrum focuses its teams on meeting their shared goals through regular time-boxed sprints. And Scrum provides a framework to identify and remove any distractions from that goal.

Whether you are in religious ministry or developing technical solutions to drive business, simplifying your approach is a critical success factor for your organization. Evaluate your organization. Do you have a simple and clearly defined process? Does your process create and measure movement toward your goal? Does everyone in the organization embody the process and can clearly articulate it? Is everyone in the organization aligned to the process and focused on its goal and allowed to say "no" to everything that falls outside of that goal?

NOTE: Don’t confuse simple with easy. Simple is clear and understandable. Easy requires little effort. Scrum is simple, but it is not easy.

There is a major difference between a travel agent and a tour guide. This difference can be seen in white-water rafting. There are plenty of rafting outfitters from which to choose along a white-water river trail. A travel agent will mail you brochures. They will suggest a few rafting outfitters and a river to enjoy. But a travel agent’s role ends there. They tell you to enjoy the journey. “Nice to meet you. Enjoy your trip.”

A tour guide is different. A tour guide will say “Nice to meet you. Get in. Let’s go.” A tour guide has been there before. They have traveled this journey many times. A tour guide shares the stories from past trips along the way. They provide you perspective of the journey, what to expect and what to look out for. You get inspired by their passion. They are with you, sharing in the journey. They are on the bus and in the boat. And if things don’t go well, the tour guide is in the river with you too.

Organizations going on an agile trip need agile tour guides, not agile travel agents. There are plenty of agile travel agents. An agile travel agent will mail you pretty brochures of agile. They will offer training courses to prepare you for your journey and for what it will be like when you “get there”. If indeed there is a “there” to get to (agility is a journey, not a destination).

Organizations need agile tour guides. An agile tour guide is someone that is willing to take the journey with you. Someone that has traveled that journey before. Someone to share the stories of trips past - the adventure, the mistakes, the storms, the celebrations. Someone to guide and inspire you. An agile tour guide will not be perfect. Their boat may tip over with you in it. But they are credible. They know the shortcuts to take and the ones fraught with danger. They can make your journey more enjoyable and the results much more valuable.

While travel agents have their place, I prefer to hang out with the tour guides. They know what’s really going on inside organizations. They have the experience of many journeys and the scars to prove it. They also tend to have more fun and their stories are more intruiging!

That is why I am leading an effort in the Scrum Community to identify and designate agile tour guides. In the Scrum Alliance, we call this the Certified Scrum Coach (CSC) program and we are qualifying those individuals who have been down the agile journey many times before and are capable of guiding others through it. Feel free to contact me if you would like to know more about this program or keep an eye on the Scrum Alliance website for a soon to be released application process.

Note: This concept of agile travel agents and tour guides came from my reading of a book entitled Simple Church. Some of this text is paraphrased from the book. While Simple Church is not a book on agile methods for corporate organizations, is indeed a book on agility - creating a simple and clear purpose with a simple and aligned process to execute it. Regardless of whether you are in a religious or corporate institution, this book is a worthy read.