What I don’t agree completely on is that the 51% has to be the right 51%. This is one of the joys of Scrum and the sprint concept. If a sprint is slightly off kilter, you didn’t waste a whole waterfall, just a sprint.

I feel like I missed the tie back to Scrum and not just the 51% solution so I’ll be adding an update to the post.

Good to hear from ya!

While I’m a big proponent of SCRUM and agile development in general (it served us really well on our Senior Design project and in some short quick react efforts at work), you have to have the *right* 51% in order for this approach to work. Too many people (this includes me) fall into he trap of “this is what we want it to look like at the end” and calling that their 51% solution. The solution should be the path forward, not the end goal. If you have an amazing idea for an embedded systems project, for example, and the hardware you’ve been given does not have a feature that your end goal requires, it doesn’t matter how well defined your “solution” is. You will make progress towards an impossible goal and it’s only a matter of time before you go off the end of the cliff. Not to mention the inherent problems with using agile in contract situations where you have X dollars or X hours to produce something and may not be able to afford the twists and turns you’d like.

It’s easy to fall into a trap of not considering what’s going to happen outside of those two week bubbles. Everyone should have a picture in the back of their mind of the overall vision, not just the Scrum master.

Mike