[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 Replies to “[Guest Post] – Let’s Play Name That SDLC: Volume 1”

  1. hmmm…
    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.

    1. 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…

      1. 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.

  2. “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’.

    1. 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.

      1. 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. 😀

  3. 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.

  4. Pingback: Tweets that mention [Guest Post] – Let’s Play Name That SDLC: Volume 1 | Agile Scout -- Topsy.com
  5. 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.

  6. 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.

Leave a Reply