Saturday, June 20, 2015

Short Scrum and Long Scrum

There are many many ways to play Scrum. In some sense Scrum is infinitely flexible.

But let us pretend for a moment that there are only two types of Scrum, which I will call Short Scrum and Long Scrum.

Short Scrum

In Short Scrum, maybe where a Sprint is completed in a day, we do not have a long Product Backlog. Maybe the Product Backlog only contains enough work for one day or maybe two days (one or two Sprints). Imagine also that a ‘whole product’ (however we define ‘product’) or release can be completed in one or two days (one or two Sprints) or less.

With the Sprint length of only 1 day, we might have ‘Daily Scrums’ every hour (e.g., over an 8 hour day). The Sprint Planning Meeting might last 20 minutes. And the Sprint Review at the end of the day might last 10 minutes. And the Retrospective again might be 10 minutes.

Short Scrum would be useful when a Team has lots of small things to do, and those things are changing quickly (e.g., daily, and maybe being identified during each day). (For now let us assume still that the Team is the ‘ideal’ size of 7.) And you want feedback very quickly (each day). And the Team can build ‘working product’ (something that can be demo-ed that is in some sense complete) in 1 day most of the time.

Obviously ‘Short Scrum’ is a special situation or set of situations. Still, there might be many situations in the US (or the world) like this. Thousands or millions.

And, obviously, some situations might be similar to this, but not have exactly these numbers.

Getting the feedback every day can be enormously helpful.

One classic example is a small family doing a set of chores over the weekend.

This model also implies a high level of interaction in the team, during the day.

Also note that the concept of ‘long term planning’ has little meaning. Maybe long-term planning might be planning for the week. And note that Scrum (the simple framework) does not mandate any Release Planning.

The Velocity concept might be minor or not there, especially if it is not useful. For example, if the

Team is taking on a different type of work each Sprint (each day), then Velocity is unlikely to be consistent. Also, since a ‘release’ is happening every day, there is probably less need or no need to have the forecasting knowledge that velocity can give the Team. Still, in terms of continuous improvement and perhaps for other reasons, velocity might still be useful.

Few or none of these ‘criteria’ are ‘hard and fast’, but one certainly can imagine situations like this.

Long Scrum

In Long Scrum, imagine the Sprint is 2 weeks long. And imagine that it will take several Sprints (e.g., 8) to complete the product (meaning possibly: release the first release of multiple releases).

The Product Backlog might be very long (e.g., 6 months of work or more), and might include items that we might never get to.

The Sprint Planning Meeting might be as long as 4 hours (although usually somewhat less), and a Sprint Review might last as long as 2 hours (if useful). And the Retrospective might last 90-120 minutes, and of course help the Team increase their velocity.

And we have the ‘normal’ 15 minute Daily Scrums.

This type of Scrum is more useful when the Team has a big mountain to climb, and has some understanding of the mountain beforehand. (The mountain is a ‘product’ with a decent vision of what the product will become. The product is anything that that Team might ‘build’… tangible or intangible, physical or electronic or ?. But we do want the pieces to be demonstrated.)

Imagine that the Team has the worked divided into 8 small pieces (small stories) for each Sprint. And it takes some time to get each piece to be working. But, at the end of 2 weeks, all 8 pieces can be working. And it is useful to get feedback from business stakeholders: ‘do you want what we have built so far?’ And the right people will come every 2 weeks (in part because we have built enough to interest them).

The Product Backlog might still be changing, but the basic scope of the product is not usually changing a lot, or at least we do not expect it to change that much. We at least think we know what to build each Sprint, although in the Demo we sometimes discover that the business stakeholders do not like some pieces (some stories).

In this situation the concept of long term planning (well, planning over the 6 months, which would definitely seem ‘long term’ to the Short Scrum team)… is useful. And needed, necessary. In part because the business and the customers and the marketplace require some relatively good prediction of when the product will arrive or that ‘it’ will arrive by X date. Time is quite key in this way, at least usually.

So, Velocity is more needed. And more do-able, in part because the work is relatively more
consistent. And the Team needs to stay together, so they have time to discover their real velocity.


***

I have three main points in describing Short Scrum versus Long Scrum.
1. Scrum can be played many very different ways, and yet all can be called Scrum.
2. Some of you will mainly be playing Short Scrum….where the work is changing frequently and being identified only a few days before it is done. Still, you can use Scrum.
3. Short Scrum can seem very different than Long Scrum (to both sets of people), and yet both are Scrum. There are also, of course, varieties of Scrum that are some hybrid of short and long.
Hope this is helpful.
Your comments please…

Saturday, June 6, 2015

Balancing the work in the Sprint (coding vs testing)

Dean asks:

Greetings Joe,
 
Your Lean Agile Training website content has provided some great insight in helping me improve my agile principles and practices.  There is one thing I haven’t been able to clear out of my mind.  Perhaps there is a principle I’m not applying or a lightbulb that hasn’t come on.  Maybe I haven’t come across the right advice in a book or blog.  My conflict is keeping my full team ‘busy’ through out a sprint.  We typically apply a 3 week iteration and there seems to be a pendulum from coding to testing.  Those strong on testing don’t have full capacity during coding and coders aren’t at full capacity during testing.  Coders doing work at the end of the sprint won’t have their code tested and therefore don’t meet the DOD.
 
Is this a common mistake or have I missed the boat on something?
 
Joe replies:
 
This is a common concern.
 
Let me assume that you are the ScrumMaster.
First, it should not be your concern particularly that the Team is occupied all Sprint.  The Team should care about that.  Because the Team should have a mission that they feel they must accomplish promptly.  Or they are not really a real Team.  They are a Team INO (in name only).
Next: We do not want to think of the Sprint as being in two parts: (1) coding and (2) testing.  Rather, for a 3 week sprint (I prefer 2 week sprints) with a Team of 7 people, we have at least 13 stories.  And we think of each story in 2 parts (coding and testing, in very simplistic terms).
For each story, the coding and the testing work can begin at the same time.  First, decide how much info will be know beforehand (Ready Ready Criteria).  Then the coder starts to figure out the code (he thinks) while the tester figures out the tests (he thinks).    They work in parallel.  The tester should be building automated tests (of course….won’t explain why here).
The key concept from Lean is ‘single piece continuous flow’.
Then, when the code is ready, the tester tests it (automatically mostly), and of course there will often be bugs.  And then those are resolved quickly.
The simple rule that Jeff Sutherland uses is “No code can be written in the sprint that will not be tested in the spring.”  Among other things, this means that if the testers get behind, the coders must help them (if only by fetching the iced tea).  And vice versa.
Again, they win as a Team and they fail as a Team.  This is a key idea that they really must believe if they will do Scrum professionally.  (It is a sport for real Teams.)
Now, if they will help each other, they may have to learn new things to be able to help each other effectively.  This is a good thing.  And what knowledge workers naturally want to do.
Talk through these ideas with the Team.  They will help figure out the details, such as exactly how to help each other, what to learn, etc, etc.
One push back:  Well, actually some ‘teams’ have many push-backs. First is often some variation on ‘we don’t want to work as a team’.  Understandable in the sense that they have not ever been asked (for 5-10 years) to really work as a Team.  And some (few) people do not (ever!?!) want to work in a Team.
But a key push-back is: This seems like a lot of extra work for us. It would be more efficient if we did the work in big batches (usually, as they are doing today).
The penny game is one big way to convince them about this.  (I have written about this on the blog.)  In a certain sense, what they feel is somewhat correct.  What they are not seeing is all the savings that accrue when doing the work this way.  Mainly since the ‘bad news is not getting worse with age’.
Enough for today?  Comments? Questions?

Wednesday, December 10, 2014

Toronto – Impediment List

Here is what the Toronto course identified as impediments.  Not in any order (although understood that it must be ordered).
  1. Overlooking risks
  2. Big scope
  3. Team competence
  4. Too many defects
  5. Team changes
  6. Processes not clear
  7. Product owner involvement
  8. Under estimated
  9. Requirements not clear
  10. Requirement change not being communicated
  11. Not what client expected
  12. Finance
  13. Resource (probably mot the right people or not enough people)
  14. Schedule (too tight)
  15. Poor communication plan
  16. Stakeholder (poor, missing, etc.)
  17. Knowledge (lack of)
  18. Training (lack of)
  19. QA (test)
  20. Lack of focus
  21. Buy-in
  22. Scope creep
  23. Bad Req
  24. Too many opinions
Some of these should say ‘(lack of)’.
We recommend a public impediment list. Of course, the list itself is not the point.  But rather AGGRESSIVELY attacking the impediments and fixing all the impediments is.
We like to have one list for ALL the improvements we need to be made (for the Team). From people issues to Blockers, to tech issues and changing culture.