Agile Zone is brought to you in partnership with:

Martin has worked with many customers in government, finance, manufacturing, health and technology to help them improve their processes and deliver more. He provides management and technical consulting that intends to expose processes and practices to gain transparency, uncover impediments to value delivery and reduce cycle-time as part of an organisations path to agility. Martin is a Professional Scrum Trainer as well as a Visual Studio ALM MVP and Visual Studio ALM Ranger. He writes regularly on, and speaks often on Scrum, good practices and Visual Studio ALM. You can get in touch with Martin through naked ALM. Martin is a DZone MVB and is not an employee of DZone and has posted 64 posts at DZone. You can read more from them at their website. View Full User Profile

There is No "Do Agile," There is Only "Be Agile"

  • submit to reddit

I commented on Scrum is Hard to Adopt and Disruptive to Your Organization before and I think that, for most companies, this is just beyond their comprehension. They are fundamentally misunderstanding agile and trying to do agile rather than be agile.

There are is no training or certification or even process that can provide you with that understanding. There is nothing but deep organizational change and hard work that can create that lean-agile way of doing things that provides many companies with so much value.

If you want to be agile you will need to embrace:

  • giving up management command-and-control
  • going and seeing what the problems are rather than looking at endless reports
  • encouraging and supporting people to serve as hands-on-master programmers for 15+ years
  • close engagement between the hands-on developers and customers, without intermediates
  • managers and architect who are pair-programming coaches
  • real transparency – of delays, what’s wrong each day, …
  • The candour to say “we don’t know”
  • stopping sequential lifecycle practices and mind-set
  • empirical process control
  • replacing cube farms with team rooms and visual management

-from Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum

I do not believe that it is possible to sell Agile to a company, they must come to the realization of what it entails themselves. Oh, you can introduce them to many of the practices and encourage them to experiment. You can teach individuals TDD and other test-first methods, but all you are doing is priming the pan and creating an environment where that spark of agility can smoulder. Then they will come to you.

I was recently contacted by a customer that I have worked with before to help them become more … well ... agile. They feel that they have a good understanding of the mechanics of Scrum and that they are gaining value at the team level, but they want more. They want to realize the greater organizational reality of agility and not just follow the rules.

In short they want to build people, then products.

There are a great many thing that we can look at but until I can "go see" how folks are working there is no way I can have any idea of a plan. I can, however, imply that there are some things that, while not constants, are good bets to look at and for:

  • Discourage "fake agile" – The first thing to look at is if they really do have just the mechanics down or if they are starting to be agile
  • Encourage "Communities of Practice (CoP)" – Sometimes referred to as guilds, these CoP allow and encourage folks interested in a practice to collaborate, regardless of the affinity they have to a particular discipline.
  • Encourage "go see" – Encouraging managers to go to where the work is boing done will be immensely more valuable than looking at reports

If we can get some amount of time on-site to investigate and work on some of these things, then that would make me happy. I am really looking forward to seeing how they have been getting on and how many of the issues we identified in the last engagement have changed.

Here is looking forward to future collaboration and experimentation.

Published at DZone with permission of Martin Hinshelwood, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)