"What's your favourite technique for estimating stories in Scrum?"

My number one favourite? Not estimating them at all! 

Instead, ensure stories do not exceed an agreed size that ensures they fit easily within a sprint (ok - I agree that's estimating, but it's much simpler estimating than tee-shirt sizes (S, M. L or/and too big) or points (1, 2, 3, 5, 8,  and too big). Then spend the time you've saved estimating the size of stories on estimating the number of stories in the various epics in your product backlog. Measure velocity in stories not points (or use only two sizes: 1 point and too big) and forecast the completion of epics and minimum-marketable-features based on the throughput of stories (velocity) and the number of stories. 

As well as saving a ton of time, it turns out your forecasting will be just as accurate as if you'd spent ages agonizing over each story! See for example +Vasco Duarte's blog about the evidence for improved forecasts from this approach.

The key question - as +Neil Killick points out in his recent "People Need Estimates" - is what problem are we trying to solve with our estimating? 

I was working with a team recently who were concerned that they had missed their forecast for the second sprint in a row. The retrospective meeting came up with several suggestions about how they could improve their forecast for the next sprint. I asked the team whether there was anyone (outside the team themselves) who was interested or concerned about their forecasting ability. The last few sprints were running at a throughput that was over double the average for the previous year. If the team continued to focus on the improvements they were making, the business could easily adjust to this higher efficiency. The business did not need (or probably believe) the over-optimistic forecasts that the team were making. Shown the evidence of actually completed work, the business will adjust to the new opportunities the improvements open up.

There are 6 general practices of Kanban... and I'm happy with that!

There are 6 general practices of Kanban, and in spite of my preference for groups of 3 (see "There are 3 ... Principles of Kanban"), I'm really happy with that. (I guess 7 would have a nice golden ring to it... but now I am being silly.)

The core practices are:

1. Visualize
2. Limit Work-in-Progress
3. Manage Flow
4. Make Process Policies Explicit
5. Implement feedback mechanisms
6. Improve Collaboratively, Evolve Experimentally (using models & the scientific method)

Nevertheless I've found it useful to start a team off by emphasising three of these (no really):

1. Visualize 
2. Limit Work-in-Progress
3. Improve

Before we can manage the flow we need to see it, and so getting a Kanban board with items moving across it really is the first step. Limiting work in progress is the essence of Lean and fundamental to all agile processes. Surprisingly to most teams, it nearly always brings an immediate impact in increased throughput and reduced lead time. And finally, as the foundational principles tell us, continuous improvement is the whole point. Let's start improving from day one.

There are 3, no make that 4... no really, shouldn't it be 3 Principles of Kanban?

+David Anderson first formulated the Foundational Principles of Kanban a few years ago:

1. Start with what you do now
2. Agree to pursue incremental, evolutionary change
3. Respect the current process, roles, responsibilities & titles

I like that. It makes clear that Kanban is about changing your process (it isn't a process) and also that it's about changing your process in an evolutionary way - step by step, with a viable generation after each significant change. There's no known destination to the ideal, forever-great process, that we can produce a plan for getting to. Unlike the old farmer who replied to a request for directions with "You can't get there from here!", we have to get there from here, so let's start here.

I also like it because there's three! So much easier to remember.

But wait there's more. Recently the principles have been updated and there are now four. I'm sure someone will tell me when and by whom it was added, but I confess I don't know. I just know the fourth one's arrived. Even Wikipedia (2013-04-16) knows it, so it must  be true! So here are the four:

1. Start with what you do now
2. Agree to pursue incremental, evolutionary change
3. Initially, respect current roles, responsibilities & job titles
4. Encourage acts of leadership at all levels from individual contributor to senior management

Yes number four's a good one. It should definitely be there. But do we really need four? Three is much easier to remember, quicker to share, and - when two of the principles say almost the same thing - three could be a potential improvement.

So here's my suggestion for when someone next updates the Principles of Kanban. That is, when they update the three foundational Principles of Kanban:

1. Start with what you do now (including the current roles, responsibilities & job titles)
2. Agree to pursue (incremental) evolutionary change
3. Encourage acts of leadership at all levels (from individual contributor to senior management)

If you want the snappy version, omit the phrases in parentheses.

See also "There are 6 core practices...".

Better Daily Planning Meetings: Asking the Right Questions

+Joe Vallone provides a very useful insight into the right emphasis for daily stand-ups. In his blog Better Daily Planning Meetings: Asking the Right Questions he suggests slightly modifying the well-known standard questions (what did you do yesterday? ... etc.) to:

1. What did you get done yesterday?
2. What will you get done today?
3. What is preventing you from getting work done?

This moves the emphasis from the activities to goals and helps a team focus on finishing work rather than simply doing it.

There's a similar purpose behind the standard Kanban practice of "walking the wall" from right to left, finding where tickets are stationary and seeking to unblock them. Flow only happens when things get done!

Scrumban - How to win friends and influence people?

My guess is that Ladas provokes extremes of like or dislike to his writing, depending on whether you happen to agree with him or not. Nevertheless I fall in the middle (well three and half stars rounded up perhaps!) as, while I do find the uncompromising ridicule of non-lean/less-lean processes somewhat wearing, I do think he's got some important ideas to share.

So I'm with the author on the main thrust of his argument, but just to dismiss eXtreme Programming for example as a reinterpretation of the V-model, seems less than just for one of the key advancing influences for agile in the first decade of this century. Similarly Scrum comes in for some merciless treatment - many people are going hate this book on an emotional level long before they parse the content - and especially if they interpreted the title as a description of an agile method that combines elements of Scrum and Kanban. That's not what Ladas means by Scrumban. He's discussing instead what evolution of process would take place if a team was using Scrum and adopted Kanban, while relaxing Scrum's rule-immutability. His answer is that many of Scrum's practices will change and you will end up with a much leaner process, with less work-in-progress, and independent cadences for queue replenishment, improvement events and releases. In other words you end up with a typical Kanban system. Hmmm... take care what you assume is in this book when you read the title!

Any way if you can get past his style, Ladas gives us some very interesting observations on Lean software development systems. In particular I found the "feature brigade" section fascinating - a discussion of how a Kanban process for software development could be built by analogy to a fire brigade's chain of buckets. The point about such a system is that it is self-levelling, since the point at which the fireman with an empty bucket meets the one with the full bucket is variable, depending on the current rate of working of the two participants. Such self-levelling of Kanban systems, if it can be achieved with simple feedback mechanisms like this, will lead to real advantages as they are scaled.

This is an idea worth persevering with the book for!

Lessons in Agile Management by David J. Anderson

Holiday reading this year was David Anderson's "Road to Kanban" book. I had a similar initial reaction to this book as Malcolm Gladwell's "What the Dog Saw" - it's a compilation of previously published work (in this case from Anderson's blog) and if I didn't read it the first time why should I read it now?! In fact both books won me round very quickly. There's a lot of new work invested in "Lessons in Agile Management", in grouping related articles and commenting from a contemporary perspective on the developments in the agile community. There are also just valuable and insightful articles on many aspects of software development and management that I found both refreshing and original. Kanban is a relatively new kid on the block when it comes to agile frameworks - the major incumbent Scrum is consequently suspicious and negative towards it - but as this book shows, its roots are deep and arguably more secure than many views of agility. I would recommend this book to anyone wanting a broader understanding of the thinking behind Kanban and the principles it's built on. You will get a more balanced view than is possible from the texts that just focus on the methods artifacts and techniques.

Could Kanban be defined in a "Scale-free" manner?

Scale-free or scale-invariant processes are like fractals. They work independently of scale - from the intergalactic to the molecular if you like. Could a scale-free definition exist for an agile process such as Kanban - a process that would be robust and effective from the personal and small team scale to the scale of whole or multiple enterprises?

The Wiener process (random or Brownian variation) is scale-invariant (from Wikipedia)

I've recently returned from three days in Hamburg on +David Anderson's Kanban masterclass and this was one of the questions that was raised during the sessions. Uncontroversially Anderson stated that Kanban, like agile processes such as Scrum, XP and FDD, is not scale-free. Different definitions of Kanban exist at different scales. Personal Kanban applies to individuals and small teams. It uses a subset of the methods and techniques defined in Anderson's Blue Book and may have other techniques which are not applicable at higher levels. Equally Portfolio Kanban, which does not yet have a reference text, but exists in the experience of enterprises applying Kanban to multiple interconnected organisations and projects, is different enough to smaller-scale flavours of Kanban to be considered different in essence, not just in scale. 

I admit to finding this discussion frustrating since I think there is at least the possibility of defining Kanban in a scale-free manner. This would not be true of Scrum for example because the "immutable" roles, artifacts, events, and rules of Scrum are specific to the single-team scale. When you scale Scrum, even to a single scrum of scrums, the rules and practice have to be different at the larger scale. If we take the Blue Book definition of Kanban it maybe suffers from exactly the same problem. But the book is too large to be the process definition. Chapter 2 of the book might be a candidate, but it is not specific enough nor contains enough detail to test compliance.

I'm looking forward to the publication of a basic Kanban definition - Anderson stated it was in the pipeline - as my own feeling is that it should aim to be scale-free, at least over these three levels. Anderson positions Kanban as a process for organisation improvement in the knowledge work space. As such the practices relate to how to visualise work and improve, rather than the specifics of organising teams or indeed software development. At least at the first level of definition - the simplest and sparsest definition - keeping it scale-free should be both possible and useful.

Postscript: A possible candidate for a scale-free process is Feynman's Algorithm:

1. Write down the problem.
2. Think real hard.
3. Write down the solution.

One could argue this is a process only for a single person - I'm sure he intended it that way. But arguably it is scale-free. It's just the difficult and interesting part of the process as far as team problem solving is concerned (how do you write down the problem? how do you think together? how do you write down the solution) remains completely obscured. In the end it is only a trivial scale-free process.

Is there such a thing as a (non-trivial) scale-free agile process?