No Glory in “The Middle Way“
March 21, 2008
(The “Balanced Blend” Manifesto takes Shape)
Don’t really buy into all the hype of agile? Think it works up to a point, but real-life is actually more complicated and demands more of a hybrid approach? – Don’t worry, you are not alone.
Since helping define DSDM in 1994, I have spent the last 14 years helping organizations adopt agile methods like DSDM, Scrum, XP, FDD, etc and have come to realize, like many others, that these methods are not the solution. Instead they are the over-simplified starting points that you need to blend into what already works within the organization. Then overlay and support with additional approaches to create successful project ecosystems.
We need simplified schematics of systems to assist comprehension and discussion. However, all too often these simplified models are put into production as the entire solution and then problems occur. Like a simplified model of a car braking system, it is useful in helping us understand how the system works in theory, yet is full of design flaws for practical implementation.
In real life, servo’s and pumps are needed to amplify the braking force from the pedal. There is not a single shared-fluid system, but instead two diagonally opposed systems (so a leak does not result in total brake failure or pulling to one side in a left and right split system). In addition to the basic system shown here, cars also employ an array of supporting systems for fluid level monitoring, ABS, wear detection, etc.
Luckily people do not read about the basics of car braking systems and then decide to replace the one on their car with their own design. However plenty of people read about agile methods and decide to implement that as their new software production system.
The good news is that the state of existing software production systems is often very poor and so implementing any kind of better conceived system is an improvement. (A basic sub-optimal braking system is probably better than relying on throwing an anchor out the window and hoping it snags on something to stop you!) The problems occur when the current system is not optimal, but understood and working; and it is then replaced by an oversimplified alternative.
The Real Solution is More Complex
These simple models are great starting points, but poor destinations for enterprise organizations. Agile practices need plumbing-in with established project initiation, reporting and 3rd party collaboration processes. Also, just as real-life braking systems need supporting sub-systems to deal with the realities of their operating environments, so too do agile methods to handle things like regulatory controls, dispersed teams, silo’d roles, etc.
To be consistently successful in implementing agile (or any other process) outside of simple applications, a balanced view and selective approach is required. We need to understand all the intricacies of traditional project management and agile methods to effectively create a better alternative. If nothing else, this deep understanding of traditional approaches helps communications with the skeptics. Talking their language is an important starting point for addressing their concerns.
Alistair Cockburn uses the stages “Shu”, “Ha”, “Rei” from Zen Buddhism, to describe agile adoption maturity. Progression moves from obeying the rules (Shu – to Obey), consciously moving away from the rules (Ha – to Break), and finally unconsciously finding an individual path (Rei – to Separate). Todd Little has a similar “Read, Write, Delete” metaphor. First we need to be able to Read, understand and apply agile practices. Then learn how to Write our own domain specific amendments and new practices. Finally, if we develop far enough, we can Delete the rules and practices as we don’t need them anymore and instead instinctively adopt the most appropriate tools.
However, this moderation, consideration and prudent selection sounds more like the doctrine of an oppressive religion rather than the rallying cry for action. How do we sell it, and will anyone listen?
Consideration, Caution, and Careful Balancing is a Tough Sell
This balanced “middle-way” message is not very sexy, and hard to promote. Agile zealots who evangelize the one-true-path to software success, have a simple message and appeal to our desire for “new” and “quick-fix” solutions. Yet they are a bit like eating cotton-candy (candyfloss) it looks and tastes good in the short tem, but soon disappears, does not really consist of much, and leaves you unsatisfied in the long run.
Following this food analogy; people want to be slim, full of energy and healthy and often pursue quick-fix diets like Atkins, South Beach, Detox, etc. They all have some truth in them, but alone are not the whole answer. The true path, a balance of healthy eating and exercise is, well, hard work, slow and a tough sell.
The New Book
I have been thinking of writing a book for a while and have been approached by two publishers to do so. A refresh of agile project management is one option, yet where my passion lies and where I believe the greatest leverage resides, is in effectively describing this balanced approach to leadership and project management. Strategies and visuals for finding that ever changing balance between people skills and process mechanics, order and adaptation, detail and intent.
I see these variables as inclusive ANDs not exclusive ORs. We need both sides, just in varying degrees based on project and organizational factors. For instance very early in a project, when the focus is on feasibility, scoping and ROI calculation then a traditional mechanistic focus is often a priority. Then when we are into requirements exploration, development, and execution a more agile approach is preferable. Finally as we undertake deployment and user training, traditional plan driven approaches work well again. All the while our focus as a leader may be shifting from a collaboration and consensus focus to an execution focus as the project progresses.
Maybe I am naïve to think this skill of careful balance can be explained and illustrated. The greatest business benefits lie not in the approaches, but the selection and application of these approaches – more a philosophy.
Toyota happily shares its manufacturing ideas with the world including its competitors. They are not worried about being copied because A) by then they will have moved ahead so far anyway, and B) the Toyota Way is not a set of techniques, it is a philosophy, a way of thinking and framing problems that is much harder to copy. Heck, the best Toyota engineers don’t even work at Toyota facilities, they are embedded within their suppliers helping to make them better suppliers.
Good managers know about this leadership / management balance, but rarely is it written about because it eludes being easily boiled down into a cook-book approach. I am not sure of the market for such a book. Apparently books only reach 2% of the population, and I am guessing the segment of people who read and think about balance and blend is much less than those looking for the next simple fix.
Anyway, this is where my thoughts lie at the moment, ways to help select that balance between leadership and management.
I'd like to pre-order copies for everyone on my team. Where do I sign up? ;-)
Seriously (well, actually, I was serious), 2% or not, you have an important thesis: Successful software delivery requires effective leadership, good judgment, and a keen sense of balance.
As I mentioned in Leadership - The Secret Sauce (http://blog.softwarearchitecture.com/2007/09/leadership-secret-sauce.html), these ideas allow you to "harness the intellect" of the people and achieve outrageous levels of performance.
And tying it back to the Toyota Way, I like the way author Gary Hamel makes this point in his "Management Innovation" article in the February 2006 edition of the Harvard Business Review:
“Only after American car makers had exhausted every other explanation for Toyota’s success – an undervalued yen, a docile workforce, Japanese culture, superior automation – were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.”
You make the great point that many of us fall into the trap of "the next simple fix" (just like the American car makers in that story). Let's do our part to encourage focus on what's important: leadership, judgment, and balance.
Keep it up.
Brian
http://blog.softwarearchitecture.com/
Posted by: Brian Sondergaard | March 22, 2008 at 07:32 AM
Hi - all this takes me back to reading this book:
http://www.amazon.com/Balancing-Agility-Discipline-Guide-Perplexed/dp/0321186125/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1206433386&sr=8-1
It deals with how to practically balance your approach based on what the project makeup is, although doesn't cover the area that you do...that the way to adopt an agile approach is to upgrade what already works (if possible) to create your own 'home brew' version, if you like
We are doing exactly the same on a project with over 50 staff and several scrum teams - not easy but important to find a sustainable, effective solution. Some say we are using Scrum as a 'front end' to develop 'work packages' decided by more traditional planning at the back end - I think that's a little too simplistic myself, but it's clear that giving developers 'just enough' flexibility and control is a Very Good Thing....I guess 'just enough' is where the balancing act comes in:)
Posted by: Russell | March 25, 2008 at 02:29 AM
Hi Brian,
Thanks for the support and feedback. It is reassuring to hear there is interest in this area.
Regards
Mike
Posted by: Mike Griffiths | March 25, 2008 at 12:44 PM
Hi Russell
Thanks for your comment. I like the “Balancing Agility with Discipline” book, despite its poor title (since agile is disciplined, TDD takes lots of discipline). Anyway, just as Boehm and Turner provided tools and dialogue for helping choosing the balance between planned vs adaptive approaches, I would like to add the additional spectrum of management vs leadership to the mix. So we would have the spectrum of planned vs adaptive on one plane and self directed teams vs Managed Development as a spectrum running at 90 degrees to this.
Regards
Mike
Posted by: Mike Griffiths | March 25, 2008 at 12:46 PM
Nice post Mike.
-Jonathan
Posted by: Jonathan Kohl | March 26, 2008 at 07:39 PM
Great post Mike.
I think there is definitely room in the agile space for a book like this. It's clear you have a real passion for bridging these two worlds, and it's clear you understand both very well.
A book like this could would serve both communities well.
Good luck!
Posted by: Jonathan Rasmusson | March 28, 2008 at 01:22 PM
Hi Jonathan,
Thanks for your feedback and encouragement.
Best regards
Mike
Posted by: Mike Griffiths | March 30, 2008 at 08:34 AM
Yes, I think you need to write a book too and collate all your ideas in one place. I've read all your PDF archive articles and there is a lot of good information in there as well as on other pages in this site. Maybe you could even include a CDROM or a download page with some of your project management tools on there?
Go for it.
Alex
Posted by: Alex | April 09, 2008 at 01:42 PM
I'm afraid I don't think this would be a good book - but maybe you could convince me. I've posted a response to this post here - http://www.agile-lab.co.uk/2008/04/without-theory.html
Regards,
Mark.
Posted by: Mark Stringer | April 22, 2008 at 06:18 AM