Scrum vs. Kanban? Not really…

Peter Stevens, over at 

Scrum Breakfast has an interview up with Mary Poppendieck on Lean, Scrum, Kanban and Leadership. The part of the interview that caught my attention was a question on the relationship between Scrum, Kanban, and Lean in general.

I like Mary’s response a lot, where she basically states that Scrum and Kanban each have their own strengths, and each is suited for their own specific set of circumstances.

Scrum is basically a method of accomplishing work through cadenced iterations. Kanban is a method of accomplishing work through limiting work-in-process and managing flow. I have found that some work especially creative work is more effectively managed with iterations, while other work especially naturally sequential work is more naturally managed with Kanban. — Mary Poppendieck

She also stresses that, whether you choose to use Scrum or Kanban, the point is that you keep improving on your way of working, so:

Lean would have every company view these techniques as starting points that are constantly improved, so after a few years, Scrum and Kanban should evolve and change to something quite different than their starting point. — Mary Poppendieck

This suits the way that I view these things very well. Use the tools most suited for the situation, and see where it leads you.

Of course, the best way to choose is to try each, and measure results. Which brings us to another question: what and how do we measure? At the moment, I’m leaning towards flow (time for work to flow through the system), and Henrik Kniberg’s Happiness index. Getting that last one adopted anywhere is going to be an interesting challenge, though…

Learning is key

An old article I just came across, posits that learning is the thing of value in software development:

When we present this hypothetical situation to students – many of them with 20+ years experience in building software – they typically respond with anywhere between 20% to 70% of the original time.  That is, rebuilding a system that originally takes one year to build takes only 2.5 to 8.5 months to build.  That’s a huge difference!  It’s hard to identify another single factor that could affect software development that much!

The article goes on to discuss in detail how learning is enabled by agile processes. The advantages of quick feedback cycles are not just ‘fail early’, but also ‘learn early’ (and continuously).

Agile Feedback Loops

Agile Feedback Loops

Why Scrum Developers Should Get Paid More!

Peter Stevens has a nice write-up on the differences in responsibilities between Scum projects, and traditional project. As can be expected, responsibilities are distributed broader in an Agile team, with much (or all) of the responsibilities of a project manager being spread over the Product Owner, Scrum Master and the development team.

Especially interesting is that they found some responsibilities not being clearly defined in a traditional team (ROI, process improvement), while it was there in Scrum. I’m not sure whether that’s quite fair, since tracking ROI is only rarely actually done in Scrum projects, but the responsibility is explicitly there.

Scrum Breakfast: Responsibilities in Scrum, or Why Scrum Developers Should Get Paid More!.

Wave goodbye!

The retirement of Google Wave is pretty big news. There’s a lot of discussion on how Google failed. Failed because they misjudged the acceptance, failed because they overhyped, and failed because they waited too long before finding out whether users would actually like it. And all those things did happen, and some of them were probably mistakes.

But the main thing that I get out of this, to be honest, is quite a bit of respect for Google in how they handled this. They had an idea, followed up on it, saw a possibility of creating a product out of it, experimented, poured resources into it, tried it out in the wild, publicly supported it… And when the time came, they admitted it wasn’t working out as hoped for, and in a timely manner pulled the plug. Writing the whole thing off as something that generated some useful technology, and hopefully some valuable insight in end-user wishes.

This is how you innovate. You take risks. You try new ideas. You get feedback from your (potential) users. You fail.

And if you don’t fail enough, you’re not trying hard enough.

For a company of Google’s size, failure is necessary on a larger scale.

Now if you’ll excuse me, I have some failing to do…

Update: I just love it when people back me up: Eric Schmidt said: ”We celebrate our failures. This is a company where it is absolutely OK to try something that is very hard, have it not be successful, take the learning and apply it to something new.”

The Role of the Manager in Scrum

Pete Deemer has written an article on InfoQ, Manager 2.0: The Role of the Manager in Scrum which disucusses the role of the manager in an Agile organisation.

The situation sketches that he gives are all too familiar, and anyone working on a transition to Scrum (or any other Agile practice) would be well advised to read this article.

The quote that rang the most bells for me was:

“If there exists a fundamental belief in the effectiveness of the “command and control” approach within the management and executive ranks, and a heavy dependence on intimidation, threats, or punishment (such as shaming or humiliation) as a management tool, it is going to be particularly difficult to make the transition to a new way of thinking. As a result, an adoption of Scrum risks being incomplete and dysfunctional, producing little if any improvement for the organization.”

The warning not to have (ex-) managers as Scrum Master is another important lesson, though. The habit of following orders is just so very hard to break.

EA Survey: talk the talk!

Scott Ambler is in the habit of doing some very interesting surveys. One that caught my attention this morning was on Enterprise Architecture.

The interesting part is the tables on success and failure factors. The highest rated success factors are about involvement and communication with both business, management and the development teams.

The highest rated ‘reasons for cancelling enterprise architecture programs’ are getting insufficient time, not being able to prove any benefit, and rejection of the EA work (and sometimes the EA) by the development team. Again, all factors of involvement and communication.

So there you have it: If you want to get some architectural improvements off the ground, the important thing is that you need to talk about it. Sell it to the business, by providing them with convincing arguments on how this change will benefit them. Talk to the development teams, and get them involved. Not just in execution of the idea, but in improving the concept and generating alternatives. You can’t know everything, and even if you did, you’ll get more done if the teams are involved in defining the needed changes.