TL;DR: Work smarter, not harder.

I have noticed that all systems have some natural capability for productivity, value delivery and quality. As the people in the system gain experience in the system, their performance will start reaching that systemic speed. Just like with a ship, this happens quite easily, but when the “hull speed”* is reached, the amount of effort / power to go faster dramatically increases, up to the point that a certain speed seems unsurmountable regardless of power expended. In systems, we can perceive this e.g. in overtime, which does not yield real benefit since the extra effort translates to more mistakes and other negative factors that detract from real progress.

I continually observe that also in the ball point game, where people psyche themselves to try harder, but they still get the same result.

Recently I “rediscovered” the PDCA cycle, made famous by W. Edward Deming, consisting of Plan, Do, Check and Act phases, and forming the base for every process improvement cycle. According to Wikipedia (http://en.wikipedia.org/wiki/PDCA):

PDCA (plan–do–check–act) is an iterative four-step problem-solving process typically used in business process improvement. It is also known as the Deming circle, Shewhart cycle, Deming cycle, Deming wheel, control circle or cycle, or plan–do–study–act (PDSA).

PLAN – Establish the objectives and processes necessary to deliver results in accordance with the expected output. By making the expected output the focus, it differs from other techniques in that the completeness and accuracy of the specification is also part of the improvement.

I’ve come to realize recently that there are two types of Scrum. One is goal-driven, the other is story-driven.

The Story-Driven Scrum

This approach seeks to identify and prioritize user stories (or any requirements) small enough to fit in the iterations. In these Sprints, the team commits to delivering the selected set of stories. These stories can be estimated and the amount of results can be measured for longer term planning. This approach works best when enough design work can be done in advance to eliminate most significant elements of uncertainty prior to committing to work in a Sprint. I could call this type the Mike Cohn Scrum as this approach is excellently defined in his Agile Estimation and Planning book.

Last Tuesday, on 4th of May, 2010, I was participating the TIEKE Brief #10 “Scrum – ketterästi” as a speaker. I was closing the brief with a title “Reality Check”. There is much hype and unfounded optimism on Scrum and Agility that I felt it was appropriate to try to ground some of that. Scrum and Agile is hard. Change is hard. It’s easy to write bad software expensively; it’s very hard to try to do as good software as you only can with as little waste as possible. It is known that most Agile transitions fail to meet the expectations.

While the presentation should be appearing also on the TIEKE site, I’ll post it to my presentations page (also linked to this post). It’s in Finnish and in a very much simple format. Should I expand in text? Okay, will do quickly…

Agile isn’t a silver bullet. It doesn’t solve most of the problems typical organizations have. It will expose them. It’s up to the organizations to fix their bad habits or poor operation. Scrum is pretty quiet on “how” (purposefully, because it isn’t a methodology), so we must turn our attention to other sources. Lean Software Development gives a pretty good overview on the kind of product development Agile environments should foster. An upcoming book by Stephen Denning, labeled Radical Management, takes a more comprehensive look at how businesses can become radically better. Dan Pink made a great case in his TED talk about how rewards are actually damaging our businesses and our innovation. Etc. There’s lots to learn for us.