Scrum falls short in at least one area in my opinion

Many of us have come to love Scrum, including me. Scrum has been a huge success overall and has turned many a development team around and for the better. Yet in my opinion, I think Scrum falls short in at least one area.

Concept to Cash

Firstly, it's commonly accepted that Scrum does not consider the whole life-cycle i.e. it's a great framework for helping development teams tame the development life cycle but it does not tackle all areas from "concept to cash". Lean and Lean with Kanban certainly appears to be an alternative to Scrum or at least coupled with Scrum to provide and all round concept to cash highly effective framework for producing software products.

Definition of Done

Secondly, and more in particular, where I believe Scrum falls short has to do with it's definition of Done. Well, truthfully, the definition of Done is not really even a part of Scrum but once again, it's commonly accepted that defining what Done means on Scrum projects is an important part of it.

Potential Shippable code - what does this really mean?

Most Agile thought leaders define the output of an iteration as an increment of potentially shippable code. And more often than not, it appears to be acceptable (please tell me if I perceive this incorrectly) that this potentially shippable increment of code is not actually live production code. And therein lies my beef with Scrum.

Lean

I think the Lean folks have this right - they are very interested in the value stream and minimizing the cycle time of this value stream from concept to cash. So my feeling is that this definition should be changed from "potentially shippable code" to "shipped code".

Iteration Output = Live on Production Servers

On out project teams, every iteration represents a new increment of code LIVE ON PRODUCTION servers - no discussion, no arguments.

This takes serious discipline and focus. And most of all it requires very careful planning. If you get too much work-in-progress you will never turn this in to a reality.

Way to many companies fall short

I find way too many companies after each iteration still trying to close things down in order to get this potentially shippable code shipped. More often than not there's on-going QA etc. long after the iteration is over. This is not a healthy state of affairs.

Take the hard line, change the definition, you won't look back.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Comments

[Tobias Mayer]

Hi Jack,

When you use phrases like "Scrum does not consider the whole life-cycle" and "Scrum falls short [...] with it's definition of Done" I suspect you are misunderstanding the nature of Scrum. Scrum is a simple framework whose clearly established presence will cause organizational dysfunction to rise to the surface.

Scrum doesn't actually do anything, people do things. Scrum, coupled with common sense can be applied at every level in an organization. To say it doesn't consider the whole life cycle is simply saying some people don't know how to use Scrum in a holistic way, and are bound by development practice thinking. Not the same thing at all.

The definition of done has to be taken in context. If you are working on a web application it is common sense to complete work and push it to live servers every sprint. If you are working on embedded software for appliances that only get updated every six or twelve months, along with hardware and other changes, then clearly it is impossible to "release to production" every sprint.

The point of "potentially shippable code" means it can be shipped any time the PO/Customer requests it, without the need for additional testing or bug fixing. It is exactly that: shippable. The phrase is carefully chosen to be context independent.

Most teams that want to add things to Scrum (usually some version of Lean or Kanban) are doing so because they don't get the simplicity of Scrum, and are failing in one area or another. Rather than adding anything to Scrum we should be looking at what to remove from our processes that doesn't damage the core Scrum framework. In well-functioning Scrum, less is more.

[Derek Mahlitz]

I agree 100% with Tobias. I see so many teams trying to change the process to fit what they do instead of changing what they are doing. Basically Scrum is bringing all the problems to the surface but teams want to change Scrum so they don't have to change themselves.

[Chuck van der Linden]

Also in violent agreement with Tobias.. He's said much of what I wanted to. Yet I find a have just a few more comments:

Firstly 'deployed code' has a pretty bad smell as a defintion of done when the project isn't deploying each sprint's code (which is especially common when building a complete system from foundation up, where there's not enough there to deploy (or sell) for several sprints)

Furthermore, I would argue that the need for a good 'definition of done' is NOT IN ANY WAY UNIQUE TO SCRUM. This something that is required for ANY and ALL potentially successful projects. ALL projects no matter how they are managed (scrum, waterfall, lean, whatever) have to know what they are supposed to be doing. Otherwise you keep going without end, and it's the 'xanadu project' all over again.

The other issue I have with your definition, even if we presume it's a project that does deploy the results of each sprint to production, is that depending on the process for doing so, you are potentially going to be idling nearly everyone in the team while the IT folks roll out to a staging env, conduct tests, etc. Immediate rollout to production servers might work for some folks like amazon with hundreds of webservers, where they can prop to a small percentage and use live customers to test how it's working (and just take those few servers off line if there's a problem) but not every org works that way. Some have (and for good reason) a pretty well regulated process for deploying new code, and it's a process that would leave the entire team just standing around. I think in that case it's better to have the team starting on the next sprint, but available in the event of a problem. In much the same way a dev might move on to a new story card while the one they just finished is run through acceptance tests, knowing they might have to stop and go back to fix something they missed.

I think the problems you describe with all sorts of QA and other activities 'after' the end of a sprint doesn't have to do with using 'shippable code' as a definition. Because frankly, if it's not passed QA and those other processes, it's not fracking shippable is it now? so guess what, 'yer not DONE' no matter what you might want to think. Those problems don't get solved by changing the definition of done, they get solved by addressing how QA and DEV are working with each other, and not allowing developers to be the ones to declare that something is 'shippable'. Because CLEARLY, if a bunch of work (outside of a set IT process related to deployment) is needed to make the 'shippable code actually shippable' then it wasn't shippable in the first place. You Never met the criteria to be done. If they team isn't meeting that criteria in the first place, then changing the criteria isn't the solution. Your problem isn't the criteria for doneness, the problem is that SOMEONE declared you were done, WITHOUT MEETING THE CRITERIA. 'whall that's yer problem right there.'

[Jack Milunsky]

@Tobias. Thanks for your comments. I think what you have said is very valid. I can't disagree with anything you have stated. But just one point from my side. I am not suggesting we change Scrum in any way. I am just suggesting that when it comes to the definition of "Potentially Shippable" code that there is better clarification of what that means. I think many companies take that to mean potentially and not shippable. I concur that in certain contexts you can't go live.

Jack

[Martin]

"Shipped code" as a required result of every sprint kills one of the main benefits of scrum - short iterations between stakeholders and the team, which allow us the agility we all seek. "Potentially shippable" should mean IMHO "we can ship this, if the client is still ok with the result. But we might need another iteration, according to the outcome of the demo".

[Scott]

Jack,

I would agree with Tobias and Chuck as well. I would also throw out there that many people seem to take a similar thought approach, that Scrum is a development process. In fact if you take the essence of Agile Scrum, add a little creativity, you can use it to expose just about any area of a business in which you wish to improve, become more competitive or encourage collaboration. I have taken the essence of Agile Scrum and been able to apply it to many non-development related endeavors.

In the grand scheme of things, done is not even remotely as important as whether or not you are delivering value. If what you are shipping (code, accounting sheets, shovels, etc) delivers value; attempts to deliver that value according to what is most important first; and exposes problems with how or what you are delivering, then that is what is most important. If you define a shovel as being "done" or "shippable" today, that does not mean that customers may not change what they like in a shovel tomorrow.

As a COO, you may want to try using some of these techniques in a small management project (non-software related). You will likely find that it helps you improve your business. This is one of the areas that I work with businesses to help them deliver value. The ideals behind Lean, Agile, Scrum, etc, all lead to one thing: better, happier, more reliable, more visibility, goal driven rather than task focused, etc.

[Gary Thomas]

Really agree with Jack here regarding interpreting "potentially shippable code" - I've had the experience of some teams, management, and even some scrum masters (mis)use this phrase.

End result is backlogs and sprints that consist of "phase 1", "phase 2" for features, technical items, etc., but each sprint's deliverable is basically unshippable. Business folks are then back in the position of asking "when is this project going to be done?" with all the resulting problems.

All in all, this seems like a throw back to Waterfall, RUP, etc. except that there is now a monthly schedule to follow.

I wouldn't call this a shortcoming of Scrum per se, though. This seems more an issue of Scrum evangelism and education.

[Jeremy]

So how do you deal with the "hump" caused by the need to get a "critical mass" of parts together before you have anything that is actually shipping/shippable? Without extending iterations out and defeating the purpose?