I was talking with some smart people at a client. They said: "We do a Sprint -1 where we do rapid prototyping. We do a Sprint every day, produce a new version of the GUI, etc and review it with the customer team daily. It lasts for 2 weeks, or did last time. It is mainly visuals to help us in discussions with the customer about what they really want. Generally low fidelity, generally throw-away code (to the degree it is coded)."
I am, perhaps slightly famously, against the Sprint Zero concept. I will describe that more fully elsewhere. But the basic idea is that I don't like a Sprint that results in no working software. More generally, I don't like a Sprint Zero because it includes (mostly/only) work about which the team can get no objective feedback from someone useful...did it contribute toward what the customers really want?
So, it is mainly the lack of real feedback that troubles me.
So, how does the situation presented by this client compare to this?
To me, the client is doing an excellent job, at least so far as we can tell from the conversation, in trying hard to understand what the customer really wants. In general, I find abstract conversations with customers are of low value, while conversations that include visuals, and include, where relevant, some work flow, can be much much more useful. This seems to be the case.
That they produce some 'working product' DAILY that can be usefully discussed with the customer to get feedback seems excellent. Yes, this working product is not working software as we typically have in a Sprint in Scrum. But this seems far less important in this case than that they are increasing and tightening the feedback loop with the client.
That they call the 1 or 2 week effort Sprint -1 does not thrill me, honestly. It suggests to others that a Sprint Zero concept is ok, even good. That someone speaks of doing a daily 'sprint' within the Sprint -1...well, as an English major I want to quibble about word usage. (Minor really.)
That the prototypes are throw-away does not seem, on the surface, ideal. But maybe quite appropriate.
To me, the main thing is that they are increasing rather than decreasing the feedback. And tightening (speeding up) the feedback loop. This has to be good.
What is less clear (at least from that conversation) is how well the feedback is happening through the rest of the delivery effort. Perhaps more on that later.
Net, net: Some people feel that every accommodation made between Scrum and reality is necessarily not doing Scrum 'right'...although maybe still the right thing to do. It is true that too many people are subtracting from Scrum (which we tend to call 'ScrumBut'). And in almost every case we find that to be....not good for them, really.
But adding to Scrum, and I want to call the above usage of 'Sprint -1' an addition, adding to Scrum is, in general, necessary and typically a good thing. Yes, a Sprint Zero (as described above) would be a bad addition, in our view, but in general additions to Scrum are necessary and useful.
The key is: are the additions made in the context of lean-agile-scrum values and principles. Such as, the principle of increasing the feedback so that the bad news does not get better with age.
Sometimes, two or more lean-agile-scrum principles will come into conflict in a specific case. Then the question is which principle should have precedence.
Wednesday, March 2, 2011
Subscribe to:
Post Comments (Atom)
6 comments:
I have to disagree with you regarding sprint zero. I like the concept. I think your assumption that sprint zero doesn't deliver anything and thus is not reviewed or approved is mistaken. Sprint zero should have a clear deliverable, It could be a mockup, prototype, document, model, etc. Something tangible should result though it may be thrown away and not become part of the final system.
Hi Vin,
Well, as you saw, I am ok with a Sprint that delivers prototypes or something (other than working software) that enhances feedback.
To be honest, when I hear people talk about Sprint Zero, it typically has several bad smells. But you are right that we should not blame the words per se for that.
So, I am at least in principle ok with a Sprint whose main deliverable is a mockup or prototype or model that is used -- in that sprint -- to get real feedback that is highly useful.
Having written lots of docs myself, which were considered deliverables, I am more than suspicious that documents enhance (usefully enough) the feedback.
So, it is not a 'tangible' deliverable that makes or breaks the issue. It is the usefulness of the feedback derived from the deliverable that is key.
Again, as you read, to me a prototype that is 'throw-away' is not in principle the deal-breaker. Again, this is ok (maybe not ideal) to me if the feedback derived is high.
Do we really disagree?
Thanks,
Joe
Here are some of my concerns with the stance of this post:
- Sometimes, a sprint zero is actually warranted and, as you state, going back to the principles of feedback are essential.
- Spike out a small story and take it through your environments to shakeout your dev environment and your process; that is an implicit deliverable to get early feedback on the process itself
- Typically, on large engagements and projects, in global, distributed scenarios and with large enterprise software projects, getting the basic system framework for iterative scrum development is an achievement in itself and is a logical sprint zero activity
- value is where and how you define it
- Principles (feedback, interaction, working software, collaboration, etc.) should always override Practices (dogmatic pairing, ratios of staff, Scrum, FDD, etc.)
- There are multiple stakeholders in a software project, and the IT department (and security and audit teams) are as well. These could possibly be validated early in the release cycle, Sprint zero makes a good candidate sprint to address these
Hi Anon.
You state that you have some concerns with the stance, but I am not clear how we disagree.
#1. As I said in a comment above, I am talking about 'Sprint Zero' as I have seen it in the field. YMMV...or may have varied. So, what are the conditions under which you would say it is ok? And when not ok?
#2. Not sure what you meant here. I could guess. But not sure. As one example, I tend to think that we want more than just feedback on the *process*. We want feedback from the customer or a real good customer representative...are we really building something you want?
I find Sprint Zeros don't enable that feedback.
#3. I agree that often Infrastructure, Architecture and Design (as I call it) does require some up-front work. But typically I want to also start doing some User Stories from day 1 too. To test the IAD and to get the customers used to coming to demo day (Sprint Review) and giving feedback.
#4. Well, I agree that value in a given situation does require definition. What are you really driving at here?
#5. Well, maybe, sometimes. I might argue this point. But how does this statement support your case for Sprint Zero? I am contending that (usually) Sprint Zero seriously reduces feedback. I think you are saying high or increasing feedback is better (we agree on this principle, I think). So, I think you are saying that a Sprint Zero can (and does in some cases) keep feedback high or increase it. Right?
#6. I think you are saying that security and audit issues need to be addressed in a project. (Agreed, in general.) And that this should "all" be done in Sprint Zero. (Correct?) My response is, why take up *all* of a Sprint doing work that enables minimal feedback. Rather, let's spread this work out over several Sprints, and still keep at least some user stories in a Sprint 1 (that also includes some security and audit work). Reasonable?
Thanks,
Joe
I've been experimenting with an extension to scrum built around a design-only phase which produces "usable documents" instead of "releasable code" and has a couple of additions. So far it seems to be working out. It is not a Sprint Zero, but follows scrum guidelines. I'll probably do a post about it fairly soon, but I tend to agree that additions to SCRUM are good, subtractions are less good.
Hi Damon,
In general Agile is biased against "design only" phases. We like to see things in the real world quickly, and get feedback.
But sometimes these are unavoidable (contractually required, etc).
May we ask why you are doing these experiments?
Thanks.
Post a Comment