When should we do Agile?

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

Let me refine the question a bit.  For a specific project or set of work, when do we do Agile or should we use something else (waterfall)?  (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 via 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. Enough to do ‘pretty good agile.’

Note: If they are going to play ‘agile’ 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, were 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.

Here are 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 best 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 they see the full Team as being responsible for success.

If you do not have a Team (worth calling that), then I question the value of doing Scrum.  Maybe, just maybe, waterfall might be better.  Or maybe something else. (But, if you really want to be successful, or more successful, you really really should use a real Team.)

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 an 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 not do the work.  Yet, at least.  (Yes, urgent is perhaps only another way of saying important.)

The importance and urgency have 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 do not value — as much as we should — speedy delivery 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 not so in the ‘real’ world), then I recommend Agile-Scrum.

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

Why?

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 we knew a lot more useful information on Day 0.  But the truth is we never know even 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, in the event, actually useful.  This fact (that we lack perfect knowledge up-front in every domain) is key 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??!!  People are somewhat random.  Great in some ways, not so good in others.  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, I have found the 7 heads of the Team (or whatever your Team size is), work better, virtually 110% of the time, and 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 projects 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 complexity that is largely unknown when we start.

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. IMO.

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. Still, if played unprofessionally Scrum might be worse than waterfall played professionally.

But why would we ever play any method unprofessionally?  (And yet we do.)  We can say that Scrum the first time with professional intent is almost always better than the waterfall you have been playing for years now. (Wow, what does that tell us about waterfall?)

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, urgent, 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 (done with equal professionalism).

Hope this helps you.

« « Courses We Offer || Impediments – Charlotte Class Jan 2-3 » »