Bizarro-tive development

Anyone familiar with Superman also knows about Bizarro, a doppelganger of Superman.  Bizarro looks like Superman, but is opposite in every way.  Instead of saving people, he kills them.  Instead of eloquent speech, he talks like Tarzan.  He’s not from Earth, but from Htrea (Earth backwards, clever).  And so on.

A colleague reminded me again of the challenges of explaining iterative development to a manager who had been living with waterfall for many years.  The timeboxing concept came through, but iterative and incremental, not so much.

We drew our original six-month schedule on the board and chopped it up into monthly iterations, saying we would deliver at the end of each month.  We should have been more specific on what “deliver” meant, because this was what the manager then suggested:

  • Iteration 1: Envisioning
  • Iteration 2: Planning
  • Iteration 3: Development
  • Iteration 4: Refactoring
  • Iteration 5: Testing
  • Iteration 6: Stabilization

Each iteration is timeboxed, which is good, but this is just slapping arbitrary exit points on waterfall.  Not iterative, but bizarro-tive development.  Once we explained further, this was the next suggestion:

  • Iteration 1
    • Week 1: Envisioning/Planning
    • Week 2: Development
    • Week 3: Refactoring
    • Week 4: Testing/Stabilization
  • Iteration 2 – lather, rinse, repeat

Still not exactly what we were talking about.  True iterative development has most or all aspects happen every day, and some points in the iteration some things will happen more than others.  But we’re never doing just one aspect, and slapping phases into iterations isn’t iterative development, but it’s what Bizarro might do.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • What’s funny is that I remember having that *exact* same experience with traditional project managers about 5 years ago.

    At your employer.

    Glad to see the progress.

  • *sigh*

    Proving again change is not always progress…

  • Try flipping him around. Tell him you want the following phases:

    - Envisioning/Planning Stage (think about the design)
    - Testing/Stabiliation Stage (write unit tests).
    - Development Stage (write the code)
    - Refactoring Stage (any cleanup)

    Tell him that’s the order you want to do the phases in. Then tell him you want to allocate 3 minutes to each stage.

    If he says you can’t do them in 3 minutes each, ask him if he has 15 minutes for you to demonstrate. :-)

  • Have him call me…lol…no seriously.. *smile*

  • Isn’t that how RUP tries to sell itself as “agile” ?

  • @Evan

    This is the type of guy that start putting up a 15 minute timer after a demonstration like that. Gotta be reaaaal careful in shaping expectations.


    Exactly. Jeffrey Palermo called it “Scrummerfall”