Jun 20, 2007

Outsourced Agile

Andrew has posted about a guy named Alex in Romania having a big rant about using agile in an outsourcing arrangement.

His argument is founded on everything that can go wrong with an agile project if you miss the fundamentals of agile and forget to "inspect & adapt" your process to fit the situation.  And while he doesn't outright say it, from what I can tell he's tried to use XP (extreme programming) for his engagements.  That in itself is a tough ask - XP is a very demanding methodology to follow (why do you think it's called extreme) and is really intended for internal short term projects, not outsourced arrangements where slightly more rigorous processes are more appropriate.

And in case you're wondering I've run agile projects for large external customers before, so I know a thing or two.

Let's take a look at some of his arguments:

1. The strong points of agile development don't turn out, in practice, to be that strong.  Less paperwork isn't a good thing.

Who said an agile project shouldn't have documentation?  Who said you can't document anything? And, um, are you nuts!! You can document requirements as you go - use cases, user stories, acceptance criteria, signed off UI mock ups, all sorts of things.  Documentation in an agile project should be "just enough documentation" not "no documentation".

2. Stress and Unproductivity

Apparently it's stressful and unproductive to communicate with your customers and tell them what you're doing.  I think someone needs to think seriously about what business they're in.  Outsourced development is a service, and implies that customer communication is important.  Agile methodologies stress the importance of communication.  I don't see how this is a negative.  If anything it's a positive as proper communication will result in improved outcomes for the client.

3. The First Meet-Up.  (You can't estimating the size of the job)

Apparently in an agile project you're not allowed to estimate.  What a crock!  I'd like to point you to Mike Cohn's book on Agile Estimating and Planning.  Agile says "don't lock down your estimates in stone", not "don't estimate".  Every project needs estimates, plans and priorities.  So make an estimate, and revisit that estimate as more information becomes available.

And how does the ability to do an initial up front estimate get impacted by the methodology you use to deliver it?  If a customer wants to know how long the piece of string is, it won't make any difference if you use waterfall or agile, it's still an estimate.  Waterfall just deludes the customer into thinking that the estimate is accurate, all the way up to the missed delivery date!

4. What you deliver has changed from what was asked for and now they're upset

The project draws close to conclusion and the client begins to realise that the delivered solution will be different to what was asked for at the beginning and that this is a surprise to them, and they'll make you redo large parts of it.  HELLO!!  If there's been any communication going on then the variations that have been made will be based on what the customer asked for and put in a prioritised list.  Oh, hang on, he didn't do any documentation and he doesn't like talking to the customer.  Hmm, no wonder things went pear shaped.

The statement that the "In the classic approach, it is impossible for both you and the client to be anything but happy" is just downright ludicrous!  A delivered to spec project does not equal customer happiness.  And while a spec may be "frozen" it's a guarantee that requirements will change.

5. Daily progress and showing the customer each day what has happened is bad.

I agree, so why do it?  Why not show the customer at the end of an iteration.  Every 2 - 4 weeks, and show how you've delivered on commitments (and possibly gotten ahead a little).  The customer doesn't need (or want) to sit shoulder to shoulder with your team 8x5, but they do want to know what's going on.

6 Daily change requests. (when the client changes their mind every day).

Hmmm.  And here I was thinking that in an agile project an iteration had a fixed scope, where commitments are made and delivered.  I think someone missed the point about planing in an agile project.  Change priorities, change scope, change as much as you like, but none of it takes effect until the next iteration.

And the statement that "With the classic approach, change requests like this are impossible, since the specifications are frozen." goes against point 4 above - does anyone really think that a customer with a plethora of unactioned change requests will still be happy when you deliver to the original spec?

7. Clients know programming and will tell you how to do your job.

Is he serious?! You're responsible for your work, the customer is responsible for the specs.  If you've got a customer who thinks they can manage your staff for you, then it won't matter how you run your project, it will fail.

8. Clients who want to run the show.

Why is a client getting involved in the programming?  I just can't fathom it.  The involvement of the customer in an agile project is for the clarification of requirements, business rules, etc.  NOT for assistance with the code.  Honestly, what is going on here?

 

All Alex's rant does is highlight the mistakes he's made.  It's another great article on what NOT to do when adopting agile practices, especially in a client/vendor arrangement.

2 comments:

  1. Hi Richard,

    I think that Alex's points have some merit. The issue that I have (I'm not sure about him) is that there is a delicate balance of power that needs to exist in a project team for the project to run smoothly. Often I have seen this tilt too far in one direction or another. A heavyweight methodology IS able to maintain that at the expense of falling prey to different problems.

    If you experienced no problems using Agile, that may just mean you were fortunate (or a very wise manager). To reuse a rather dubious maxim: Absence of evidence (of a flaw) is not necessarily evidence of absence (of the flaw).

    Andrew

    ReplyDelete
  2. Hi Andrew,

    I've got to disagree there. The balance of power issue exists regardless of what methodology is used. Watch any project and you'll see the same behavioural patterns. A divided team typically fails, a united team typically doesn't. Methodology has little to do with that (though I think agile is better because it empowers those who actually do the work).

    ReplyDelete