Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

I still think it ironic that when looking at the actual Agile manifesto at <a href="http:&#x2F;&#x2F;agilemanifesto.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;agilemanifesto.org&#x2F;</a> (which is short and uncomplicated), that the first line is &quot;Individuals and interactions over processes and tools&quot; and these days practicing agile, at least in a big-house corporate environment feels like anything but.

My team moved from scrum to a kanban style process a couple years ago. The benefits were immediate. We no longer have drawn out sprint planning meetings where we discuss requirements of features that we never end up working on in that sprint. We don’t waste time debating complexity of features. Everything is now just ad hoc. When we need more requirements definitions, we pull the necessary members of the team together and discuss it. When we see that there needs to be architectual discussions and high level planning, we do it immediately when we recognize the need for it. The idea that you can try and commit to or even forecast how much can be completed for a period of time is pretty absurd. Just identify the minimum requirements of what needs to be done and do it. Retrospective is still productive. But sprint planning is a waste of time IMO.

We had Ken Schwaber come in to our shop early on in Scrum when we were struggling to get a new product going, and at its basics Scrum made tons of sense. Get a small group of people together to figure out how to make the highest priority items to ship to the customer (each written in a few sentences), then <i>leave that group alone</i> until the sprint was done. The &quot;commitment&quot; was on delivering the value in the few sentences, not matching mockups, specs or some never-ending chain of tasks.<p>It was a really simple and effective approach, but where it broke down was: there&#x27;s a lot of people&#x2F;roles&#x2F;depts who have no idea how to work incrementally. UX &quot;needs to work ahead&quot;, product &quot;needs the whole backlog&quot;, Ops &quot;have their own backlog&quot;, etc.<p>Scrum didn&#x27;t work with everyone hawking over a few engineers - then it just becomes task tracking bullshit.

Now I would suggest to deprecate &quot;sprint&quot;. It is not healthy to sprint continuously. Sane software development is much more like a marathon.

Funny to see this. I thought getting commitment was one of the soft mechanisms of scrum. An annoying one, because power dynamics are always at play. Still a mechanism, though.<p>I think I&#x27;m supportive of the idea on removing it. Seems the goal is ultimately to find ways in rhetoric and action to align the teams in working to the end goal. Which, often, might require tradeoffs to reach a timely delivery. And timing is a requirement.

Yes yes yes. It never made sense to me that our ticket sizing was supposed to be an estimate and yet the planning that used those estimates was considered a commitment. Totally insane.

I am a big fan of scrum precisely because of the word commitment (I hand&#x27;t realized it was removed). Forecast means we need to use a larger estimate next time. Commitment means: &quot;how can we still get this live&quot;. In a good culture the answer to this should rarely be work extra hours or reduce code quality - it should be reduce scope of functionality. Without the commitment you often get micro feature creep, where a bunch of non-essential micro features are added. A bit like this (<a href="https:&#x2F;&#x2F;lawsofux.com&#x2F;parkinsons-law.html" rel="nofollow">https:&#x2F;&#x2F;lawsofux.com&#x2F;parkinsons-law.html</a>). It is also the obvious moment in time to tell a product owner &quot;we need to remove functionality x or not ship&quot;. Without the commitment that important conversation is never had. In my experience micro &amp; macro feature creep is one of the biggest issues in sw development. Obviously you can still do the above with the word forecast, but forecast empowers you less to actually change anything (apart from better aka higher estimates next Sprint). On a general note: I feel scrum is often misused to &quot;manage&quot; engineering teams, when it is really a productivity tool that the team should use for itself.

I wrote an article on the negative psychological impact of commitments in sprints (<a href="https:&#x2F;&#x2F;www.linkedin.com&#x2F;pulse&#x2F;scrum-makes-you-dumb-daniel-jones" rel="nofollow">https:&#x2F;&#x2F;www.linkedin.com&#x2F;pulse&#x2F;scrum-makes-you-dumb-daniel-j...</a>). It&#x27;s great to see renewed focus on shifting away from a term that has been used to make developers&#x27; working lives unpleasant, leads to lower-quality code, and gives false certainty to stakeholders.

This PDF is pretty nice. Regarding the differences of Kanban vs Scrum. <a href="https:&#x2F;&#x2F;www.crisp.se&#x2F;file-uploads&#x2F;Kanban-vs-Scrum.pdf" rel="nofollow">https:&#x2F;&#x2F;www.crisp.se&#x2F;file-uploads&#x2F;Kanban-vs-Scrum.pdf</a>

Is Agile &amp; Scrum still relevant? I am seeing more and more consultants who used to selling this stuff have moved upmarket into Lean and Digital Transformation of companies.

Can we deprecate scrum in 2018?

This is perfect.

<a href="http:&#x2F;&#x2F;programming-motherfucker.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;programming-motherfucker.com&#x2F;</a>

Tag [2011] is missing...