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?

Scrumulatory - the feedback

Thanks to the training delegates who took part in my scrum simulation game this week, and for the feedback from the game. +Patrik Kosowski, Suzanne Holmberg, +Emil Särnstrand, Christian Larsson, Jens Olsson, Jorgen Persson you were great!

First and most important feedback - we need a new name. Scrumulatory? You must be kidding. Scrumopoly? Scrumplicity? Scrummy? Burn-it-down? There's got to something better!

Equally important is the feedback about how to simplify the rules while keeping the emphasis on Scrum learning and Scrum decision making... rather than cards and mental arithmetic! I hear you Emil. More preparation by the facilitator and fewer rules to read before you can start. There are several changes in the pipeline now for the next outing.

Overall people gave positive feedback along with the suggestions for improvement so it's definitely getting another outing at the next course. One useful suggestion was to make the game open for others to play and modify. Absolutely. If you'd like to try it with your group or training course, send me a message and I get a copy of the rules and basic equipment over to you. Once we get a reasonably stable set of rules, we'll share it open source so it can have a life of its own.

Play is the basic structure for human learning. Enjoy!

Scrumulatory - the new Scrum simulation game!

Looking forward to playing the new Scrum simulation game "Scrumulatory" at my Scrum course tomorrow. Should be fun!" It contains many of the aspects of a real Scrum projects and lets participants get to grips with key visualisations of the Product and Sprint Backlogs. The winning team is not necessarily the team that gains the most revenue from delivered stories, but the one that copes best with the uncertainties that projects throw up.

"A History of the World" by Andrew Marr

How do you cover the Big Bang to present day over six continents in under 600 pages? Andrew Marr has tackled the problem brilliantly in this highly readable and insightful popular history. The pace is fast (obviously!) but he still dives into interesting stories, factoids and individual biographies. Furthermore the book has a direction and clear themes that leave you with a new perspective on many aspects of modern world politics. Thoroughly recommended.

Story Points Considered Harmful

Here's a really interesting and thoughtful discussion of story point estimating by Vasco Duarte: Software Development Today: Story Points Considered Harmful - Or why the future of estimation is really in our past.... He's just followed it up (Software Development Today: A better way to predict project release date!) with analysis from one project which shows that forecasts based on counting stories were more accurate than forecast based on story points. I'd like to see more data, which hopefully will be forthcoming from other projects submitting data, but given the cost of estimating - whether using story points or other metrics - these results provide a very good basis for forecasting in a much simpler way. I look forward to more on this in the future.

Concordion specs for xProcess

We've recently started writing the specs for xProcess changes with Concordion which is an open source tool for writing acceptance tests- here's some initial feedback.

This is probably a topic I'll come back to, but for now if you're interested in seeing the first examples produced, they are available with the source code download at Source Forge. The initial area where Concordion is being used is the specification of constraints and dependencies. This is a complex area and we felt just adding unit tests for the xProcess scheduler would be insufficient to capture the nuances of the effect of adding a constraint; for example a task ending after the start of another one. This constraint alters not only the end date of the task, but also the order in which certain aspects of scheduling take place, which could affect the forecast dates of other tasks. Comments in the test code are simply not good enough to capture this behaviour, but Concordion provides ideal flexibility and clarity to document and test such behaviour. So far the experience has been very positive.

Below is an example of the generated output from Concordion following the test run.

Example output

Note - the links in the generated output below are to local files and therefore not accessible!

Constraints and Dependencies

Constraints may be defined on a task to limit when the task may either start or end. For example a task may be constrained to start after a specific calendar date, or a date which is manually defined on another task such as its target start date. Constraints may also reference the forecast date of another task, in which case it may be referred to as a dependency.

Dependencies defined on a task from another project use the forecast dates from the last time that project was scheduled - see Dependencies on another project - (note: such dates will be "NEVER" if the depended-on project has not yet been scheduled). Dependencies on tasks in the same project however require that the depended-on task is scheduled before the depending task. The depended-on task may be promoted in schedule order (start-after-end-of constraints) or the depending-on task may be demoted in schedule order (other forms of dependency such as start-after-start-of constraints). More details can be found on this and following pages.

Example 1. - With no Constraints

Assume that today is Wednesday 2012/4/12. (2012/4/12 )

Given

• a small project starting today
• with one fully available participant available 8 hours per day for the duration of the project
• having 2 date-based tasks (overheads of 20% each on all participants, one for the duration of the project and the other for the first week)
• 10 effort-based tasks with 16 hour estimates, named a-j,

The following table sets up the tasks:

Task Name	Task Type	Hours / %	Earliest Start	Earliest End	No. of Participants
a For Horses	effort-based	16			1
b For Mutton	effort-based	16			1
c Forth Highlanders	effort-based	16			1
d For Rential	effort-based	16			1
e For Braun	effort-based	16			1
f For Vessence	effort-based	16			1
g For Police	effort-based	16			1
h For One And One For All	effort-based	16			1
i For Novello	effort-based	16			1
j For Oranges	effort-based	16			1
General Overhead	date-based	20%	2012/4/12	2012/10/18	All
Starting Overhead	date-based	20%	2012/4/12	2012/4/19	All

When the project is scheduled the project forecast start will be: 2012/4/12

Then the start and end dates of the workpackages will be as follows:

Workpackage	Forecast Start	Forecast End (50%)
project	2012/4/12	2012/10/18
a For Horses	2012/4/12	2012/4/17
b For Mutton	2012/4/17	2012/4/20
c Forth Highlanders	2012/4/20	2012/4/24
d For Rential	2012/4/25	2012/4/27
e For Braun	2012/4/27	2012/5/1
f For Vessence	2012/5/2	2012/5/4
g For Police	2012/5/4	2012/5/8
h For One And One For All	2012/5/9	2012/5/11
i For Novello	2012/5/11	2012/5/15
j For Oranges	2012/5/16	2012/5/18
General Overhead	2012/4/12	2012/10/18
Starting Overhead	2012/4/12	2012/4/19

A dependency of one of these tasks on a task that is lower in priority will change the order of scheduling and result in different forecast dates for the project.

How Constraints change this result

• With Calendar dates
• With dependencies on another project
• With start-after-end-of constraints
• With start-after-start-of constraints
• With end-after-start-of constraints
• With end-after-end-of constraints
• With cyclic dependencies

Results generated by Concordion.