Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re^2: "Bah! Scrumbug!" (Lessons from the scrap-bin)

by ruoso (Curate)
on Dec 15, 2010 at 14:18 UTC ( #877275=note: print w/ replies, xml ) Need Help??


in reply to Re: "Bah! Scrumbug!" (Lessons from the scrap-bin)
in thread "Bah! Scrumbug!" (Lessons from the scrap-bin)

While I completely agree with you about the "investment today produces tangible value today", I must say that this is probably the most common error made by so-called agile teams.

Let me step back a bit and ellaborate...

A project (according to both PMI and Prince2 standards) is something that has:

  • a start
  • an end
  • delivers a specific product.

It's a common misunderstanding that scrum (or xp, or whatever) is a "Project Management" methodology. This is simply not true, because in Scrum the so-called project doesn't have an end and it doesn't deliver a specific product. Scrum (or xp, or whatever) is a "Software Development Process". This might seem like a silly conceptual nitpicking, but it does make a huge difference.

Agile methodologies are very much useful for contracts of ongoing maintainance and evolution of a already running software, because in that case, the idea of "release soon, release often" is the most efficient way to deliver the most value-added to the customer. Keeping it in strict time-frames gives a better manageability of the integration, release, deployment cycles. Although this is often called that way, it is not, by any formal definition, a project. It's an ongoing process.

The basic practical difference between a "project" and an "ongoing process" is the management of the stakeholders and the expectation of the scope of the work. When you have an ongoing process, you should do now the work that adds value now. When you have a project, you have a "specific product" you must deliver, and it doesn't matter how much you try to transfer the role of "requirement analisys" to the customer, it is only going to get back to your face. In a project you really need to do the "big design up-front", otherwise you'll have too much scrap, and nobody wants to pay that.

And this is probably the hardest part to understand. Even if you want to embrace agile methodologies, you need to understand that the first release must be managed as a project, with a start, an end and a specific product to deliver. You need to do all the requirement analisys of this first release (I even recommend making an effort to turn it into the smallest possible project), but you can't do that first release in "sprints", because it doesn't make any sense precisely because you are not adding any value because the system is not in use yet.

So build your planning, assign the resources, keep room for fixing bugs and eventual misunderstanding of the requirements. And move to a agile methodology as soon as the system is up, running and successfully deployed. But never before that.

Rework is not always scrap, but rework when the system is not yet deployed is always scrap. Most failing Agile "projects" I've seen were failing because they forced agile in the "first release", and the customer simply refuses to pay for rework or to features misprioritization while the system is not yet deployed.

daniel


Comment on Re^2: "Bah! Scrumbug!" (Lessons from the scrap-bin)
Re^3: "Bah! Scrumbug!" (Lessons from the scrap-bin)
by chromatic (Archbishop) on Dec 15, 2010 at 16:57 UTC
    ... rework when the system is not yet deployed is always scrap...

    I question that because:

    ... keep room for fixing bugs...

    ... and:

    In a project you really need to do the "big design up-front", otherwise you'll have too much scrap, and nobody wants to pay that.

    "Just plan harder so you don't write bugs" is hardly realistic.

    (If you define "scrap" as "stuff you have to throw away because it has provided no value", then you have a circular definition you can only break by redefining "value". You get to pick what you rework: is it the BDUF spec several months later or is it code minutes to days later?)

    Even if you want to embrace agile methodologies, you need to understand that the first release must be managed as a project, with a start, an end and a specific product to deliver.

    Every reputable agile method of which I am aware suggests this explicitly.

      The problem are not in the bugs -- bugs are inevitable. What you can avoid is going in one direction for a time and then realizing that was not the right direction before delivering any value to the customer. This is the kind of rework that nobody wants to pay for, and that happens too often in some so-called agile teams -- specially the ones that try to agil'ize the first release.

      daniel

        As I wrote before, every reputable agile method to my knowledge suggests delivering a product with actual customer value (no matter how minimal) from the first iteration. Which agile methods to your knowledge suggest differently?

        It may happen more often in agile teams, but then there's less to "throw away", as they make small steps, and detect they're wrong earlier. If you first spend 6 months designing, then 6 months implementing, and it turns there's a flaw in the design and it's back to the drawing boards. It may have taken you a year to get to a case that needs scrapping, but there's a huge cost for that one time.

        But still, it's not the same as scrapping metal. If you have a production line producing expensive, complicated cuts, doing the last cut wrong is expensive. The metal has to be scrapped, and the time spend so far is completely wasted. But coding isn't the same - there's no "scrap" in the sense of a complete wasted effort. As Thomas Edison said "I have not failed. I have found 10000 ways that do not work". Taking a decision (whether it's in the design phase, or in the coding phase) that turns out to not work, does have value. You now know what doesn't work.

        One may argue that a baby that keeps falling over is wasting effort: it should spend a few months studying how people walk, then walk on its first try. But babies don't. They try. They fail. They learn from failure. In the end, they walk.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://877275]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (6)
As of 2014-08-22 03:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (146 votes), past polls