The Essence of Agile

How much of Agile practices can you remove before it becomes no longer Agile?

I was having a discussion that other day with another project manager, and this fellow was saying that he didn’t think you could do Agile without having a card wall.  Now, I’ve done Agile development before using just an Excel spread sheet instead of a card wall to track the progress, so I know for a fact that you could do Agile without the card wall. 

So I said I disagreed and we left it at that.

A little while later, I thought about the matter a bit more and decided that I haven’t changed my mind.  It is not the card wall that determines if you are doing Agile or not.

Let me give an analogy.  The other week my 6-year old son and I were playing basketball.  We weren’t in any basketball uniform.  I was in jeans, and he was in his civvies. We were still playing basketball, weren’t we?

We also were not following basketball rules: each time he makes a shot, it’s worth 50 points. Each time I make a shot, it’s worth 1 point. We were still playing basketball, weren’t we?

Also, he didn’t have to dribble: he could run with the ball as much as he likes. We were still playing basketball, weren’t we?

Lastly, we were not even using a basketball ball. We were using a soccer ball (our basketball ball was too heavy for him). We were still playing basketball, weren’t we?  I believe so.

My point is that there is a core in Agile that represents the essence. The card wall is not an essential part of it.

The idea of the card wall originated from the concept of ‘kanban’, a Just-in-Time (JIT) system developed at Toyota many years ago (as far back as the 1930s would you believe it?).  I’ll write about what kanban is in another post, and explain the big difference between it and how the card wall is used in Agile development. 

The important thing is that in Agile, the card wall is simply a reporting tool.  It give you a synoptic (‘at a glance’) view of where things are.  It is not part of the essence of Agile.

The essence of Agile is constant feedback and constant adjustment. 

The card wall, the daily stand-ups, even the sprints, are merely communication and administrative techniques.  You can replace each one of these with completely new techniques (potentially better) and still be doing Agile!

A quote on failure

A great quote on failure and its implications:

 “My great concern is not whether you have failed, but whether you are content with your failure” – Abraham Lincoln

Everybody fails some time.  Olympic champions fail, the most brilliant scientists and engineers fail, the most astute and experienced businessmen, the most competent professionals, the greatest actors and actresses, everybody.

The only ones who don’t fail are those who don’t try. 

The great differentiator is what they (and we) do with failure.

Problem solving processes

Koberg & Bagnall, the authors of “The Universal Traveler”, propose a methodical problem solving process.  Their process closely resembles the systems approach to problem-solving, an example of which I’ll include below for comparison.

K&B’s process has seven stages:

1. Accept – accept the challenge of solving the problem (this is unique to K&B I think)
2. Analyse – familiarise yourself with the problem; understand its ins and outs
3. Define – determine the main issues; conceptualise and clarify the aims and goals
4. Ideate – generate possible solutions to the problem
5. Select – compare the alternative solutions and select the best one
6. Implement – take action to implement the solution
7. Evaluate – measure success; check how well the problem has been solved.  In addition, reflect on the experience and learn what you can from it for future applications.

To compare, here’s a typical approach for a ‘hard’ systems engineering approach, taken from Zust and Troxler’s “No More Muddling Through”:

1. Situation analysis – similar to the ‘Analyse’ section of K&B
2. Goal definition – define the parameters of what we want to achieve
3. Concept synthesis – development of alternative solutions.  Same as K&B’s ‘Ideate’
4. Concept analysis – analysis and evaluation of the generated alternative solutions.  Same as the first part of ‘Select’ in K&B
5. Evaluation – comparison of the alternatives (when none appear to be the obvious best choice)
6. Decision – selection of the solution

The most obvious difference is that K&B’s covers more ground: it treats acceptance of the problem as part of the process.  At the other end, it adds two stages: Implement, and Evaluate.

Come to think of it, if you only select a solution and not yet implemented it, you have not yet begun to resolve the problem.  It’s therefore hard to think of Zust and Troxler’s ‘Problem-Solving Cycle’ as a complete problem solving process (it’s still an excellent book and one of my favourites for systems engineering).

 

del.icio.us Tags: Problem Solving Process,The Universal Traveler,Systems Engineering