As individuals begin down their own personal journey of discovery and practice using Agile techniques, most frequently find themselves in a situation where their organization has not yet embraced the values and principles of the Agile Manifesto. As such, they find themselves as agents for change or creating an "Island of Agility" in which they and a close knit team operate in a self-contained domain, but the larger organization remains the same. Is this type of a situation maintainable? How does one manage the interfaces between these groups that are now operating in a very different way?

Managing the Interfaces

Michele Sliger wrote on this topic several years ago, arguing that maintaining the precarious balance of Agile teams within a larger non-Agile organization is indeed maintainable, but it requires great care. Her essay, "Bridging the Gap" is available on Sticky minds here:  http://sligerconsulting.com/Bridging the Gap.pdf.

Unfortunately, after a couple more years, she revised her position with, illustrating her experience that teams reach a high center point, where they either move forward, fully embracing Agile in the organization, or they teeter and eventually fall back into old practices. (http://tinyurl.com/czlsue)

Culture Eats Strategy for Breakfast

While this may sound like a depressing message, it brings forward a bigger point about organizational culture and managing change. As Jesse Fewell offered the saying, "Culture Eats Strategy for Breakfast", we would like to think that each microcosm within an organization will look dispassionately at the results and performance of different behaviors and come to realize the value of Agile. Unfortunately, organizations are frequently not so rational. Indeed, the most effective frame of reference that people identified for managing Agile projects was as that of a change agent who was managing organizational change.

The use of Agile holds a mirror up to an organization and begins to surface issues. Depending on the nature of that organization, this can be a threatening experience. Ken Schwaber, the co-founder of Scrum an Agile framework, will frequently compare Scrum to an annoying mother-in-law; she points out things you probably don't want to see, but are true nonetheless. As humorous as this analogy may be, the implications can be profound. If you don't manage the inevitable organizational change that accompanies the use of Agile, you will most likely fail in the longer term.

Managing Organizational Change

"Cucumbers get more pickled than brine gets cucumbered"

     -Gerald Weinberg's Rule about Change (http://www.geraldmweinberg.com/Site/Consulting_Secrets.html)

Using Agile practices in a non-Agile organization is an inherently destabilizing activity, and as such, the most responsible thing to do is to acknowledge and understand the nature of this change. More importantly, its also important to understand what pressures exist that have moved an organization to where they are today, if a change agent does not mitigate those pressures they will likely find themselves becoming the ones changing as their island of Agile practices slowly re-adopts the practices and behaviors they were looking to abandon.

So how does one go about changing an organization? Michael Spayd and Joseph Little discussed this particular challenge at length in this web interview in 2007: http://www.infoq.com/interviews/agile-organizational-change-little-spayd. A summary of tips blog post by Tom Perry: http://agiletools.wordpress.com/2008/01/14/some-ideas-for-managing-an-effective-agile-transition/ 

Top 10 Organizational Impediments

The book "Scaling Lean and Agile Development", by Craig Larman and Bas Vodde, lists the top 10 organizational impediments, according to 10 agile development experts working in and with large companies:

• 10. [...] failure to remove organizational impediments
• 9. [...] centralized departments looking for cost 'savings' and 'synergy' that leads to a local optimization
• 8. [...] consider learning a waste of time and money
• 7. [...] functional organizations
• 6. [...] systems that foster local optimization over global optimization
• 5. [...] failure to learn from outside expertise
• 4. [...] individual performance evaluation and rewarding
• 3. [...] 'commitment games' and unrealistic promises
• 2. [...] assuming it's all about developers
• 1. Almost everybody cited "silver bullet thinking and superficial adoption" as a major impediment.

Also read The Cargo Cult Agile Approach, a blog post by Bill Gaiennie  http://theagileadvisors.com/?p=39  "The term cargo cult comes from the author Richard Feyman and was described in detail in his book Surely You’re Joking, Mr. Feyman!  The terms roots were even earlier than its use in his book, originally being used in his 1974 commencement address where he warned of learning to not fall into the trap of fooling one’s self.  And unfortunately, this is just what I am seeing more and more lately, agile teams fooling themselves into believing that they are truly utilizing agile"

Finally, read James Shore's (author of one of the best books on Agile) "The Decline and Fall of Agile"

What do you think?

This section is based on the experience of the members of the PMI-Agile community, a group of professionals seeking to bring more engagement and discussion between the practitioners of Agile and members of the Project Management Institute. As this is a community website, we welcome your thoughts, questions, and elaborations on this topic.

Please refer to the Content Guidelines if you are unsure how to contribute to this page.