Wednesday, January 1, 2014

When should we do Agile?

This is a question many have asked, and here is my approach to it.

Let me refine the question a bit.  For a specific project or set of work, when do we do Agile?  (This might be the first project or the next project that comes to us.)

Note: This is NOT: (a) Should we implement Agile in this company or group? (b) If I just started implementing Agile, and I want to implement it gradually, how do I choose which projects to go agile first.  We are NOT trying to address either of these questions here.

First, one never chooses without an option.  Here we have two other options: (a) do not do the project, and (b) do it with waterfall.
But, I get ahead of myself.

First, let us define agile as Scrum – plus whatever engineering and other practices the Team already has or could quickly adopt.

Let’s also ask a few more questions:

1. Does the Team want to do Agile?
In this case, let’s assume they would prefer to try Agile rather than do another waterfall project.

Note: If 2 members of the Team hate Agile or Scrum, they will probably make it fail.  I do not recommend Scrum in this case (assuming you must have them on your team). If only 1 person hates Scrum, often we can get him or her convinced in the experience of it.

2. Will the Team do ‘pretty good agile’?
Let’s assume they learn enough, either through books or courses or coaching, or all three.

Note: If they are going to play ‘agile’ completely unprofessionally… my attitude is ‘why bother’.  Let them play waterfall unprofessionally and give waterfall an (in this case undeserved) bad reputation.

3. Is there any change or learning that will occur?
To be frank, I have never been on any project in my career where significant change did not occur.  I have been on a few projects where learning was significantly inhibited. But never on any projects where learning, and learning faster, was not important.

Note: I suppose if the effort were completely repetitious work, then it might be more efficient to do it in a waterfall way.  This does not seem to be the case with Toyota in assembling cars (they use a Team approach roughly similar to Scrum), nor is it ever the case with any knowledge work I have seen.

Some domains of learning: customers (beneficiaries, end-users, buyers, etc, etc), problem(s), solution, product, requirements, minimum marketable feature set, competition, technology, the business environment, the team itself, etc, etc.

Some domains of change: All of the above. Include also the company, the organizational structure or management reporting, the economy, etc, etc.

4. Do you have a Team?
Scrum is built to be a Team sport. It is based played with a real Team, and with a stable Team.  The Team can be of unknown capability or even weak capability, and Scrum adds the ability to identify the biggest weakness and fix that one first.  We want the Team to be ‘strong’, by which I do not mean capability. I mean more that they identify themselves as a Team, and the see the full Team as being responsible for success.

If you do not have a Team, then I question the value of doing Scrum.  Maybe, just maybe, waterfall might be better.  Or at least, something else.

Now, if you have very important work to do, and it must be done, or wants to be done, quickly, then you should be able to argue and easily get a decent (not perfect) Team. So, usually if you can;t get a

Team, you have a very unimportant set of work (compared to other sets), or, your company is not able to act reasonably.  If the later, I might try Scrum to start to show them the value of having a real, stable Team.  It might work.

5.  Is the work important and urgent?
If the work is neither important nor urgent, then I would probably recommend mainly that you just no do the work.  Yet, at least.  (Yes, urgent is perhaps only another way of saying important.)

The importance and urgency have important effects in Scrum. The higher they are, the more value Scrum tends to bring. In many different ways.

Two examples: (a) The more important a project, the more likely you are to get a real, stable Team. (b) The more urgent the project, the more likely the agile ‘learning’ approach to defining when the first release is ready will be helpful.

In my opinion, we project people all do not value enough speedily delivering something worthwhile to the customer.  Speed, time to market, beating out the competition — these things are far more valuable than almost any project team rates them.


As you can guess by now, if the above conditions are met (which seem to me quite minimum and obvious, but apparently that is not so in the ‘real’ world), then I recommend Agile-Scrum.

But let’s talk about why in a different way.


1. Learning.  Scrum enables more learning than waterfall.
2. Adaptation to change. Scrum makes it easier to adapt to change (in any dimension) than waterfall.
3. Lack of perfect knowledge up-front.  Waterfall would work a lot better if it were true that we knew a lot more useful information on Day 0.  But the truth is we never know 70% of (all the different types of) the information we need on Day 0. In fact, we are never clear, until the project or release is finished, how much of the information we did have on Day 0 was actually useful.  This fact (that we lack perfect knowledge up-front in every domain) is a key input to items #1 and #2 above.
4. Feedback. Scrum enables much more feedback than waterfall.
5. Random Carbon Units.  We are dealing with people here. All kinds of people. The Team, the customers, etc, etc.  Who knew people were so important??!!  In any case, a key input to items #1 and #2 above.
6. Innovation.  Scrum enables more innovation than waterfall.  (This is the positive side to the random carbon units. Random = unexpected = innovation (at least sometimes).
7. Two heads are better than one. This is an old old idea. But with our projects, we have found that the 7 heads of the Team (or whatever your Team size is), with our work, virtually 110% of the time, are smarter than 1 or 2 people.


Notice the things I did not mention.  I did not mention complexity or size or uncertainty.
But let me comment briefly on each.

Complexity.  I never see any simple project anymore.  At least simple in all dimensions. Also, I think complexity is a bad stand-in for better terms: learning, change, lack of perfect knowledge up-front.

For example: if the complexity were well-known up-front, then it is not the same as wading into a set of complexity that is largely unknown.

It is true that a more complex project in Scrum might be played differently than a less complex project in Scrum.  But the level of complexity per se is not a decision factor between Scrum and waterfall.

Size. We have found that Scrum is better for large projects than waterfall. If played professionally.  Size tends to mean more unknowns, more learning, more adaptation to change. On the other hand, if played unprofessionally Scrum might be worse than waterfall played professionally.

Uncertainty. Again, I find the concept in this context not very useful.  The relevant questions are, first, (a) how much learning, and (b) how much change.  Only when these approach zero do I want to do waterfall.  And this never happens to me.

One scenario. Imagine a large, important, complex and uncertain project.  Would you rather do it waterfall or agile (Scrum)?  First, let us grant that Scrum must be played differently than in a small, important, urgent, less complex, but uncertain project.  Probably more ‘up-front’ work.  Probably more people will be involved.  Someone will invoke more rules (useful or not). Etc. Etc.  Still, I would rather play Scrum (if done professionally) with the large project than play waterfall.

No comments: