[Guest Post] – Let’s Play Name That SDLC: Volume 1

[Guest Post by David J Bland – With over 10 years of experience in the technology industry, he strives to find a balance between Agile theory and Agile reality, while expanding into complimentary process areas such as kanban and customer development.]

You can find him blogging on Scrumology.net and on Twitter @davidjbland.

Let’s play a game. The rules are very simple. I’ll show you a visual depiction of a software development life cycle and you respond with what you think it represents.


Name that SDLC!

Do you think you know the answer?

Oh wait, I forgot one more set of labels…


Wait… what?

Unfortunately, this is not a game that is very fun to play for aspiring Agile Coaches or newly minted ScrumMasters. This is a scenario I’ve encountered with new Agile teams who lacked:

a. Adequate training
b. A support system within the organization

Essentially you have teams that believe this work flow is in the spirit of Agile software development. To be quite honest, I stumbled upon exactly such a team a few years ago while working in a large enterprise organization. I browsed around their high priced Agile life cycle management tool and, well, it wasn’t pretty.

That experience left me wondering:

Do you feel that running an iterative waterfall sdlc in two week sprints is valuable?

I’d love to hear your thoughts in the comments below.

15 Responses to “[Guest Post] – Let’s Play Name That SDLC: Volume 1”

  1. Carlos Buxton
    February 22, 2011 at 9:32 am #

    this could be scary if the org really believes in their own agility, instead of a stepping stone towards that goal.

    I think different teams/organizations need different (and tailored) paths to get there, but I get a little nervous when those steps are “process-ized”.

    To comment on your question, I do believe there is value in it, specially for traditionally waterfall organizations with establish PMO’s. They tend to be the hardest to implement change in. However, the value vanishes if it becomes a process, like it sounds to be the case here, and the inspect/adapt cycle falls apart.

    In the end, you have hybrid model that highlights the worst of both approaches.

    • peter
      February 22, 2011 at 9:55 am #

      I agree, but I would say that there may be value in ‘process-izing’ some facets of the entire process to help an organization start to use pieces of agile…

      • Carlos Buxton
        February 22, 2011 at 7:45 pm #

        yes, I have to agree with that. It is very easy to implement agile from teh ground up in small/start up environments, where no processes to speak off exist and change is a natural companion.
        Larger environments “need” the structure, which begs the question, how agile can a large company be? That depends… but I think there is a sweet spot of agile-like behaviors that can be achieved as you change the culture to foster future changes.

        • peter
          February 22, 2011 at 10:14 pm #

          Large companies can’t be too agile… but they can start small. It would be awesome to see a large company truly rock Agile all the way, double rainbow.

  2. Patrick
    February 22, 2011 at 9:48 am #

    “is it valuable” is your question. I cannot predict that without any context, but I _guess_ such an approach can be a big step up from traditional waterfall thinking. What sets this approach aside is the fact that it forces people to think what they can do in two weeks time. So you end up (assumingly) with a nice set of requirements after sprint one. Then you’ve got two weeks to design a subset from those requirements. Then you build a subset of what you designed. Hopefully you can test it all in two weeks. The last sprint about maintenance confuses me. Do I need to maintain the stuff I just produced for two weeks to find out about something? Do we actually have working software at the end of the line?

    I think an approach like this is worth trying when a company or team clearly isn’t ready for full-blown Scrum for example. But it’ll only work with some major inspect and adapt attached to it. Wait a sec, I actually meant ADAPT instead of the lowercase version. Running this in fixed two-weeks sprints for a longer period will have some people wail from boredom and others wail from excess work.

    But I’d like to hear some stories from people who actually tried this and managed to not inflict major damage to the term ‘Agile’.

    • peter
      February 22, 2011 at 9:54 am #

      The interesting thing is that you can technically implement ‘agile’ anywhere into your process. That is what is great about Agile. You can kinda plop it right in there and start providing some value. Now is the ENTIRE process now called agile? Absolutely not.

      • Jussi
        February 22, 2011 at 10:08 am #

        I was asked a few years ago by the PMO “Can we implement agile here in the development phase, right between the traditional analysis and testing phases?”…That ended up being an interesting discussion. 😀

        • peter
          February 22, 2011 at 10:10 am #

          What came of it?

    • David Bland
      February 22, 2011 at 10:10 am #

      Maintenance Sprint = Bug fixing Sprint

  3. Dave Gordon
    February 22, 2011 at 9:58 pm #

    If all you want to do is time-box a waterfall approach, I don’t think you need to adopt a new vocabulary or tool set to do it.

    Agile works well if you’re comfortable with the risks associated with not knowing near the beginning of coding what the end result will look like, and waterfall works well if you’re not comfortable with those risks. Using Agile to create a new payroll system would be goofy; using waterfall to create a new app for the next generation of tablets would be goofy.

    Motto: Don’t be goofy.

    • peter
      February 22, 2011 at 10:13 pm #

      Well said. I like the idea. There are certain things that just make sense to use Agile for. Some you just need to follow what works…
      Don’t be goofy

  4. Chris Chan
    February 28, 2011 at 12:55 am #

    I got a nice giggle from your post.

    There is a difference between planned iterative and adaptive (agile) iterative and I think many people get this wrong (or confused).

    I have witnessed some projects not doing agile and not doing waterfall….kinda stuck in the middle. So not only do they not get the benefits of waterfall or agile, they inherit the worse from both. And what resulted was projects that were much worse off when compared to doing Agile or doing Waterfall alone.

    What’s even funnier is when management are so sure how agile works and then proceeds to show you a diagram that resembles your 2nd diagram.

  5. Linda
    April 17, 2012 at 7:58 am #

    I can tell you that my company is struggling through waterfall at this time. We attempted agile, but it wasn’t successful. This seems like a waterscrum approach, but waterfall has way to much time spent with documentation in my opinion, trying to find a happy medium is difficult.


  1. Tweets that mention [Guest Post] – Let’s Play Name That SDLC: Volume 1 | Agile Scout -- Topsy.com - February 23, 2011

    […] This post was mentioned on Twitter by Agile Scout, Agile Scout. Agile Scout said: RT @gboruk:[Guest Post] – Let’s Play Name That SDLC: Volume 1 http://goo.gl/fb/nUvO0 #agile #pmot” if you think this is agile, you failed […]

  2. Stop Blaming Waterfall | Scrumology - July 19, 2011

    […] quickly. If you attempt to use waterfall for an unknown solution, it will most likely need to be a mini-waterfall-like approach for it to have any value. If you choose to do this, you might as well go with agile and […]

Leave a Reply