At first, when Scrum and when Waterfall?

August 25, 2013

When your company is first starting Scrum, how do you decide which projects use Scrum and which ones do it ‘the old way’?  (Let’s assume the old way is a form of waterfall. You are waiting to transition them from waterfall, later.)  Assuming for now (for a transition period) some projects must remain in waterfall.

So, here are some factors that might tilt a project more toward Scrum:

1. Is the Team willing to try Scrum?  The more positive they are toward Scrum, the better.  At first it will be new, bumpy. You want a Team willing to work through the bumps to get to some success.

In part, you need a little success in your company to get the more skeptical types to feel comfortable using Scrum.

If the Team starts to be skeptical about Scrum, they may start to make it fail.

2. Will someone help with the Impediments?  The more this is positive, the better to choose this work.

3. Good product owner.  If you can get a good PO available 80% for Proj#1, and for Proj#2 the PO is weaker and available 40% — choose #1.

4. Reasonable stability of work during the Sprint.  If in project 1 ‘they’ will not want to change the work during the Sprint much, and project 2 needs the work more often to change in the Sprint, then choose 1.  But this is reason #4.

Allowing some work to change in the Sprint is more advanced: both for the Team and for the broader organization.  Avoid it at first.

You want the Team to commit to work in the Sprint Planning Meeting, and start to see the positive momentum of completing it by the end of the Sprint.  Fewer changes (zero is even better) increase the chances.

5. Do-able project.  It is fine to give a new Scrum Team a challenging project. But do not give them an ‘impossible’ project the first time out.  Simply because they are just learning Scrum.

Sometimes you have to anyway.

6. The skill sets within the people on the Team are more fungible.  Fungible is a fancy financial term.  It means that person A is more likely to be able to do (some of) person B’s work.

We want that with Scrum.

Also we want situations where things can be done more ‘all at once’.  For example, we don’t feel that we must finish all of M work before we can do any of N work.  We can mix M and N work in the same sprint.

7. More likely to change.

I will use that phrase, but let me explain. Project 1 is more likely to change, meaning that we are likely to have more discovery around the features to deliver for project 1. Project 2 will have less change.  And project 2 is a project that we feel confident we know how to do.  Many of the people in the team feel they have done similar projects like project 2.  And we have high confidence that project 2 will have few major surprises.

In that case, I think Scrum will help project 1 more. Because Scrum will enable the Team to learn faster and adapt faster.  For project 2, at least now, it appears that learning and adapting will not have as much value.

Still, I find it hard to say this. I have had too many projects that seemed ‘stable’ at the beginning, and yet when we got into it, all hell broke loose.  There was plenty of change and learning.  So, watch out for the accuracy of your initial assumptions.  You know how the word ‘assume’ works.

***

I think those are the major factors.  I may have left out one or two.   I will probably revise this post after a few comments.

 

« « What are impediments? Definition of Impediment || Scrum is Hard! (Scrum is fun!) » »

Posted in: Getting started, Key problems
Tagged: Tags: , , , ,

6 thoughts on “At first, when Scrum and when Waterfall?”

  1. Jan Pieter Noordermeer

    The advantage of Scrum (or DevOps) is greater when the team lasts longer and has time to improve itself. In stead of doing work for only one project, let the team maintain one or more systems. Scrum is ment to be product-oriented, where projects regarly are not. Scrum is well suited for dynamic environments.

    ↓
  2. Joe Little Post author

    Hi Jan. I like your points. And, yes, I would generally prefer to do Scrum always.
    Perhaps I did not make it clear enough, but for this post, I am dealing with that early transition issue: we have very limited capacity to do Scrum (in our company for now), so for those one or two Scrum teams, which are the better projects to select for them?
    Does that phrasing suggest further thoughts?
    Thanks, Joe

    ↓
  3. Eileen

    A great article Joe! Have you any tips for how a systems analyst, ie that is strong on design but not so much on coding, should fit within a Scrum team? Would have been the lead in waterfall but struggling to find a fit in scrum.. Thanks!

    ↓
    1. Joe Little Post author

      Hi Eileen,
      Couple of things. There is an overly-simplistic notion in some parts of the Scrum community that all that exists in the universe are these roles: PO, SM, Team (meaning Coders and Testers). First, the Team role does not necessarily mean Coders and (separately) Testers. And secondly, not necessarily ONLY coders and testers (eg, in a software effort).

      So, all the skills needed to build the product should be in the Scrum Team. Maybe an SA is a pig in the Team.

      Next, the Scrum Team never gets to fully 100% of the skills inside the Team. (Ok, maybe with some rare exceptions it does get to 100%, in my experience.) So, there are some ‘chickens’ that help a Scrum Team. Maybe an SA is a chicken.

      Often a PO has enough SA skills. Or used to be an SA before she became PO.

      Finally, the Scrum Guide talks vaguely of ‘business stakeholders’. And, in my experience, these BSHs (business stakeholders) can or should come in all types.

      I find a good formation is to have about 4 BSHs working closely with the PO. The BSHs are chickens, but very important to the PO. The PO must make sure they are good (not too hot, not too cold, just right, etc.). So, an SA could be a BSH also.

      Finally, we must say this. Like lots of old Waterfall roles, there are some people who were in those old roles (some specific people) who do not get ‘agile’. They tend to want to do ‘more study upfront’ (than needed) and get into ‘analysis paralysis’. Some SAs are subject to that. You, I am sure, are not one of them. But that explains some things.

      So, the real question is: What to do with ‘Eileen’? So, we look at what different teams need, we ask Eileen about ALL the skill sets she has, we ask her what she likes to do and is willing to do, and then we find a reasonable fit. In the Team role, we have different people, each usually with many skill sets. These guys have all kinds of simplistic ‘stamps’ on the bodies from ‘the old days’: Coder, Tester, Analyst, etc, etc, etc. But we now have John, Amit, Mary, Sven, Kiki and Eileen. Each of whom brings a bunch of things. And we make it work. In that soup, we have enough skill sets for the Team to succeed.

      Did I help?
      Thanks, Joe

    2. Eileen

      Hi Joe

      Yes thanks that’s helped a bit. We’ve currently got SA in the BSH supported PO position, but SA not ‘getting’ Agile, never mind Scrum, is another challenge. But the skills audit might be a good place to start. It’s not me (I’m SM), might even see if there’s budget for formal training.

      Thanks
      Eileen

Leave a Reply