2008.06.23 |  Jared Richardson |  Software Development

How Risky Is Agile?

I've heard from managers and developers all over the country that they're afraid to try Agile because they can't handle the risk that an Agile project brings. This type of attitude is a complete misunderstanding of Agile, but it's very simply addressed.

Here's a simple example. You've got five teams and a two year project. At what point, using Waterfall, do you realize which teams are in trouble? You don't know. You might catch it early, or you might get the disastrous "Can Do!" attitude from a manager or team lead who's sure their team will catch up, so they tell you they're doing great. But you're depending on status reports from someone who's got a strong vested interest in appearing to succeed. Their bonuses and raises depend on that perception. By the time we realize there's a problem, it's often too late to recover and get the project back on track, so our projects either fail or ships disastrously late.

On the other hand, what about an Agile project? Let's assume four week iterations. (Iterations vary from one week to six weeks. There are other Agile techniques, like continuous integration and test automation that make this possible.) So every four weeks each team has a smaller set of deliverables. This forces your teams to tackle smaller units of work, resulting in smaller, more manageable time estimates. (We all know that smaller estimates are more accurate.) Instead of trying to estimate six months worth of work, they tackle four weeks worth. It's easier to understand the problem and potential pitfalls of a smaller task.

So you're focusing on smaller amounts of work that you can more easily understand. You'll catch more problems because you're forcing the teams to think through the problems at a more granular level.

But when do you catch off track projects? At the end of the iterations... every four weeks. Say at the end of the first iteration, four teams meet their commitments, and the fifth team only finishes 10% of their tasks. Maybe that team just had a slow start, so we overlook their failure to deliver in iteration one.

But in the second iteration, the same team fails to deliver. Then again in the third iteration. Are you seeing a trend? How long do let a failing team continue to fail? In the waterfall world, you depend on regular status reports, not incremental deliverables. But a status report can easily be falsified, or just be overly optimistic. And there's also the well-known tendency of status reports to green shift as they bubble up through the management chain. But how do you green shift a failure to deliver? Especially if you use a product like 6th Sense that reports on completion rates automatically. There's no whitewashing a chart you don't get to edit.

If a team has problems delivering product, there can be an incredible variety of reasons. Bad requirements, new technology, developer incompetence.... who knows what the exact problem is? We don't... but once you realize the problem exists, you can get involved with the team and try to understand and fix it. That's a manager's job. Find problems and fix them. The first step is discovering the problems exist, and this is a time boxed iteration methodology shines.

Agile gives you this understanding in just a few iterations. Waterfall gives you this much later in the product cycle. Sometimes months or years into a large project.

So tell me again... which is the riskier development methodology?

Related Tags: , ,

3 Comments

owenfellows ( 2008.23.06 12:46 pm )

Agile is great but convincing a client that it will work for them is a different matter. Most projects like to get the requirements nailed down at the beginning of the project for various reasons.
1. They can probably get a few weeks of peoples time in the organisation to get them done instead of having to have sometime allocated over a 2 year period. The people that know what they want and what is possible are highly sort after resources and most organisations have a couple at best.
2. Contractually they want to know what they are going to get so that they can tell if they are getting value for money and who is at fault if something is not delivered. This pretty much kills agile in the true sense as it is meant to be an evolution but NO client, that I have every worked with, would accept the “You will get what you want be we are not going to tell you what it will look like or how much it will cost” statement.

Thats OK I hear you say as you can still do that upfront and then do agile development. Yes but then you also need client resources to check the deliverables every month and feed back the results. In a normal waterfall approach they can allocate some weeks for QA and other test phases instead of having to have someone on the project pretty much full time.

Then we get to the big problems what if you are relying on other system changes that you have no contol over. e.g.
1. New Webservices
2. Platform Migrations
3. New Systems that require data to be loaded before you can consume them so the format of that data, either in db or other source is not well defined (Not well defined because that work is in the first four week cycle).

I agree that Agile is less risky but it is more resource intensive. If you have a small project team full time on a project for 2 years and you make your own requirements then it will work. If you are working in, or for, a large organisation then it becomes increasingly more difficult as focus and effort either changes too rapidly or far too slowly.

I would like to know how you would solve these problems with Agile.

Arjan`s World » LINKBLOG for June 25, 2008 ( 2008.25.06 5:04 pm )

[...] How Risky Is Agile? - Jared Richardson ‘ Agile gives you this understanding in just a few iterations. Waterfall gives you this much later in the product cycle. Sometimes months or years into a large project ‘ So what is risk anyway? [...]

Jared Richardson ( 2008.30.06 10:42 am )

re: owenfellows

I’ll try to address a few of your questions and comments.

First, for reference, the Agile Manifesto http://agilemanifesto.org/

“Agile is great but convincing a client that it will work for them is a different matter. Most projects like to get the requirements nailed down at the beginning of the project for various reasons.”

Knowing what you’re working on when you start to build it is always a good idea. Not many gardens get started without some sort of plan.

“Thats OK I hear you say as you can still do that upfront and then do agile development. Yes but then you also need client resources to check the deliverables every month and feed back the results. In a normal waterfall approach they can allocate some weeks for QA and other test phases instead of having to have someone on the project pretty much full time.”

Wow… so, in your opinion, the client would rather do all the product review at the end of the cycle, and risk missing the mark completely, rather than spread out the same level of effort over time and vastly improve their chances for success? It may be that they don’t understand the trade off. It’s not so much additional client resources as it is spreading out the reviews. Instead of storing up 600 man hours at the end of the project (a fictional number), why not have 100 man hours per month for 6 months?

“Contractually they want to know what they are going to get so that they can tell if they are getting value for money and who is at fault if something is not delivered.”

Review the manifesto again. Agile is about customer collaboration, not contract negotiation. If you can engage the customer as a partner, letting them review and redirect your work as you go, the hope is you avoid the contract debate and the lawyers that go along with it.

“This pretty much kills agile in the true sense as it is meant to be an evolution but NO client, that I have every worked with, would accept the “You will get what you want be we are not going to tell you what it will look like or how much it will cost” statement.”

This is a common misconception that came out of many alleged “agile” projects. The goal isn’t to get the customer to give you money and see what you can get done. It’s about letting the customer
review and change your work as you do it.

The alternative is to freeze the requirements and hope that (1) the business environment doesn’t change for the months (or years) and (2) hope that the requirements, written in English, are sufficiently clear to dictate how to code every facet of the product. Of course, we don’t code in English (or any other spoken language) because it’s not precise enough. But we think it can completely describe the system we’re building?

“Then we get to the big problems what if you are relying on other system changes that you have no contol over. e.g.”

Mock objects easily handle the missing software. Integration tests in continuous integration ensure the software under your layer is still working as expected.

“I agree that Agile is less risky but it is more resource intensive.”

If it’s less risky, then it’s worth the extra effort to get the customer what they need. But I haven’t found it to be more expensive. Failure is expensive. Agile is logical (to me at least).

In the same way a continuous integration system tightens the feedback loop between the developer and the code, Agile tightens the feedback loop between the team and the product description.

“If you are working in, or for, a large organisation then it becomes increasingly more difficult as focus and effort either changes too rapidly or far too slowly.”

So help me out here…. if the business focus changes too fast, then having frozen requirements is better? I’m not following that line of logic.

I have seen projects (primarily government related) where the requirements don’t change for 2 years, but even then the development team can benefit from time boxed iterations, continuous integration, test automation, and daily meetings. Even if the single item you point to, customer interaction, is skipped, there’s still a lot of value to be gained from the other practices.

Examine Agile with an eye to the practices that bring business value and be sure not to throw the baby out with the bathwater. There are some gems to be mined even if you can’t do wholesale Agile adoption.

Comments

You must be logged in to post a comment.

Blog Members





    Register

Previous Post:
Part of History Yesterday?

Next Post:
New Video: Auto-Populated Timesheets