tag:blogger.com,1999:blog-7930876570525471458.post7814807045709235286..comments2023-09-08T07:50:02.120-04:00Comments on Agile & Business: Scrum, Sprint Zero (NO), and PrototypingJoe Littlehttp://www.blogger.com/profile/13413810050491070483noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-7930876570525471458.post-13655156033192170722012-07-10T22:46:49.726-04:002012-07-10T22:46:49.726-04:00Hi Damon,
In general Agile is biased against "...Hi Damon,<br />In general Agile is biased against "design only" phases. We like to see things in the real world quickly, and get feedback.<br /><br />But sometimes these are unavoidable (contractually required, etc). <br /><br />May we ask why you are doing these experiments?<br /><br />Thanks.Joe Littlehttps://www.blogger.com/profile/13413810050491070483noreply@blogger.comtag:blogger.com,1999:blog-7930876570525471458.post-18043959671592674292012-06-20T21:42:41.235-04:002012-06-20T21:42:41.235-04:00I've been experimenting with an extension to s...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.Damonhttps://www.blogger.com/profile/04624021463911847960noreply@blogger.comtag:blogger.com,1999:blog-7930876570525471458.post-20284972221869846912011-03-03T00:38:32.316-05:002011-03-03T00:38:32.316-05:00Hi Anon.
You state that you have some concerns wi...Hi Anon.<br /><br />You state that you have some concerns with the stance, but I am not clear how we disagree.<br /><br />#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?<br />#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?<br />I find Sprint Zeros don't enable that feedback.<br />#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.<br />#4. Well, I agree that value in a given situation does require definition. What are you really driving at here?<br />#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?<br />#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?<br /><br />Thanks,<br />JoeJoe Littlehttps://www.blogger.com/profile/13413810050491070483noreply@blogger.comtag:blogger.com,1999:blog-7930876570525471458.post-3883928501693777012011-03-02T23:54:10.106-05:002011-03-02T23:54:10.106-05:00Here are some of my concerns with the stance of th...Here are some of my concerns with the stance of this post:<br />- Sometimes, a sprint zero is actually warranted and, as you state, going back to the principles of feedback are essential. <br />- 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<br />- 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<br />- value is where and how you define it<br />- Principles (feedback, interaction, working software, collaboration, etc.) should always override Practices (dogmatic pairing, ratios of staff, Scrum, FDD, etc.)<br />- 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 theseAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7930876570525471458.post-70273533360364758882011-03-02T23:33:55.549-05:002011-03-02T23:33:55.549-05:00Hi Vin,
Well, as you saw, I am ok with a Sprint t...Hi Vin,<br /><br />Well, as you saw, I am ok with a Sprint that delivers prototypes or something (other than working software) that enhances feedback. <br /><br />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.<br /><br />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.<br /><br />Having written lots of docs myself, which were considered deliverables, I am more than suspicious that documents enhance (usefully enough) the feedback.<br /><br />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.<br /><br />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.<br /><br />Do we really disagree?<br /><br />Thanks,<br />JoeJoe Littlehttps://www.blogger.com/profile/13413810050491070483noreply@blogger.comtag:blogger.com,1999:blog-7930876570525471458.post-78853584408457312402011-03-02T22:29:54.163-05:002011-03-02T22:29:54.163-05:00I have to disagree with you regarding sprint zero....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.Vin D'Amicohttp://brainslink.com/noreply@blogger.com