InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Organizations Going Agile: Tread with Caution

Posted by Vikas Hazrati on Apr 27, 2010

Sections
Process & Practices
Topics
Agile ,
Adopting Agile ,
Coaching
Tags
Organizational Patterns ,
Coaching and Mentoring

Most organizations hire Agile coaches to carry out an organization wide Agile transformation. The intention is to have a lean and fit organization by the time coaches walk out of the building. Often, the transformation begins with a pilot team. However, it is very difficult to achieve transformation that improves the end-to-end delivery process and is sustainable if the transformation just begins at the team level and the surrounding organization is not involved.

Agile coaches share their thoughts on what goes wrong with organizational transformation. Dave Nicolette categorizes the problem into two meta failure modes.

One is the “Agile community problem” which focuses too much on individual teams, software and testing disciplines and helping the teams improve. Most coaches are hired to help teams and not to focus on organizations. The other meta problem is the “Not our fault” problem.

I've observed a general tendency for management to dump all of their fire-suppressant directly on the point where they see smoke emerging from their process, without first discovering where the fire itself is located. Since traditional organizations are characterized by (among other things) blame-shifting and information-hiding, any problems in the delivery process are shunted downstream, and any metrics to be reported at a given point in the process are sanitized. The scorecard always looks beautiful until the work reaches the end of the delivery process.

Dave mentioned, that the teams might not be the best place to start the improvements. Coaches should by themselves and should be allowed to investigate the organization for finding out the potential weakest links in transformation and they should start addressing those.

Rob Myers suggested a list of pitfalls, which are identifiable pretty early in the transformation process. Rob suggested “Training the leadership team early” as one of the most critical precursors.

According to Rob, the management should be trained in Agile before the entire process begins so that they have an idea of how the teams should work and understand the true concept behind “servant leadership” and “self organizing teams”. Jean Tabaka also put this as a critical adoption failure. According to her,

An executive who announces "We are going agile," but does not provide rich resources, rich commitment, and readiness to change measures of success, simply demoralizes teams. Successful adoptions of agile can be associated consistently with a passionately engaged executive sponsor.

Rob, further made the following recommendations for the organizations going Agile,

  • Let Coaches Deliver Their Training – Instead of asking for commoditization right away, let the coach take his tried and tested approach.
  • Let Coaches Interact with Teams – Teams would always be against the wall with some deadlines. This should not be a deterrent for the coaches.
  • Don’t Micromanage the Efforts - Time does not equal productivity, especially when creativity and thinking are involved. (Software development, like agile coaching, requires both.)
  • Don’t Define Process without Experienced Feedback- Many organizations would define a process because they heard about it or read a book. It does not mean that it is best suited for their conditions.

Thus, the organization has a lot to keep in mind. However, sometimes it is also the Agile coach who is at fault. Lyssa Adkins suggested an interesting list of seven coach personalities which are sure to create problems in the transformation process. Her list has the following persona's for Agile coaches who lead to failed transformations.

  • Spy – spends just enough time observing the team, just for the retrospective.
  • Seagull - swoops in for some meetings and flies away again.
  • Opinionator – has an opinion and gets attached to the opinion thus leading the team to lose interest in the discussions.
  • Admin - becomes an unnecessary middle-man for meeting logistics and other admin jobs.
  • Hub - acts as the center for communication between team members.
  • Butterfly - flits around from team to team and is not focused enough.
  • Expert – very detail oriented but loses the big picture.

Thus, it is imperative both for the organization and the coach to tread with caution. The key lies in rising above the pilot team and look at the organization as a whole. As Dave summarized,

What we should stop doing is dropping onto "uh team" in the middle of an ocean of dysfunction, as if from a rescue chopper, and expecting meaningful and sustainable organizational change to occur just because we stick a few story cards on a wall in some conference room cum team room. It ain't gonna happen, my droogies.
  • This article is part of a featured topic series on Agile
Additional Consideration for Going Agile by alireza haghighatkhah Posted
support for tread with caution by Debbie Brey Posted
Re: support for tread with caution by Agile Academy Posted
Don't stop at training the leadership team early... by Dave Sharrock Posted
  1. Back to top

    Additional Consideration for Going Agile

    by alireza haghighatkhah

    Hi,

    As you mentioned I think Challenges of Scaling Agile in Enterprises can be divide to two parts:

    The first the challenges inherent in agile itself and second those imposed by the enterprise. Actually adopting agile practices and techniques is not sufficient, because agile is mindset and we should change organization culture, management model, organization hierarchies and many other factors should be consider. Perhaps this transmission is very hard for large scale organization, so it’s very important to select right pilot project and follow to mentioned recommendation as you said in above.

    Additionally another critical decision is Coach from Internal or Coach from external, this mean that there are very important that organization try to train agile from internal manager, (perhaps existing leaders) or someone from another company. I think training from internal is very efficient, because he/she know organization culture and psychology.

  2. Back to top

    support for tread with caution

    by Debbie Brey

    I agree with your article wholeheartedly. I started Agile on a single team in my organization without the rest of the org adopting or being trained. We were successful, but not without a lot of effort on my part to continue to push back on traditional practices.

    After 3 years, and a very successful product launch, we are now taking Agile up to the full organization. Here again we are struggling with changing the organizational infrastructure. There still has not been an effort to train the organization, and that is making the transition more difficult. People are reading a phrase or two out of an Agile book and thinking that makes them an expert.

    If you are considering adopting Agile at the organizational level, heed the cautions offered in the article.

  3. Back to top

    Don't stop at training the leadership team early...

    by Dave Sharrock

    In many cases, after training the leadership team and (if you're lucky) changing some practices in the leadership team, attention seems to turn almost entirely to the team transitions. Unfortunately, this can be even less effective than just starting with bottom-up transitions.

    The leadership team still needs attention through coaching and support. Yes, the leadership team is talented, influential and sees the whole picture. That is why they are there. But the sheer number of decisions and distractions means often change is harder to establish, even with well-intentioned teams. Often, the fact that coaches are establishing self-organized teams translates into a view that leadership can ignore the transition when this is often not the case.

    The leadership team has two clear responsibilities: To set an example by following through on any changes they may decide on to better understand agility (typically, transparency at the very least); To be vigilant in identifying and removing organizational impediments that threaten acceptance of the change.

    Therefore, the focus on the leadership team doesn't stop until the transition is complete.

  4. Back to top

    Re: support for tread with caution

    by Agile Academy

    Vikas, thanks for the orginal article and Debbie for your reply. At Suncorp (a financial institution in Australia) we started the Agile transformation of our 17000 people across numerous subsidiary companies and locations in late 2007/early 2008. We were lucky though as we did have support, energy and a true believer in our Group Executive, Jeff Smith, who drove the change from a few successful and motivated teams to the whole organisation.

    When we couldn't find quality Agile training in Australia to support our experiences, Suncorp created their own training organisation, the Agile Academy (www.agileacademy.com.au) in conjunction with trained internal coaches as well as eliciting assistance from our partners with external coaches to support the transition. This has seen 3000 internal staff trained and hundreds of external people undertaking our external Agile courses through the Academy over the past 2 years.

    Without a doubt though, training was one thing, but as you said Vikas, management have to be on board and understand what's happening in the first place to support their teams. For us too, coaches were and are essential to our continuing success. Sorry for the plug for the company but as you can tell, even though our journey has not always been smooth, success has been high and we are seen as one of the leading Agile organisations in Australia. What this has come to mean is that many if not all of us at Suncorp have joined the ranks of the true Agile believers too.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.