Kanban vs Scrum - less shootout more engagement needed!

David Anderson's book on Kanban provides a real insight into the practices and essentially the motivations for Kanban, particularly applied to process improvement. Since my reading happened to coincide with Ken Schwabers's dismissive posting about the method - saying that in contrast to the serious nature of Scrum it was a "nice distraction, for distracted people", it was helpful for me to look at all the examples, practices and theory in the book with as critical an eye as possible. I am a supporter of Scrum and believe it is the best starting point for team's starting out with a mandate to choose their process. However my recent clients have over 100 scrums working in parallel with a lot of other process surrounding them. They need methods for analyzing the waste in the processes and incrementally improving, based on sound metrics and evidence.

Kanban provides this kind of framework for improvement and I would strongly recommend such clients use it, as the basis for informed process development. As Henrik Kniberg points out in his companion volume to Anderson's, "Kanban and Scrum making the most of both", the methods are not incompatible. The fewer constraints that Kanban imposes on processes means that from a Scrum starting point, some of the constraints of scrum could be relaxed if benefit was deemed to flow from it. I presume this is why Schwaber objects to the method so strongly - if the starting point of the process is waterfall, one might end up with a slightly improved waterfall but not the major benefit that would flow from a true agile process. However if Kanban is followed effectively changes to a Scrum starting point would only be made if evidence was available for incremental improvements in the key business metrics. Yes there are risks involved in moving away from tried and tested agile processes. But that's where rewards lie too.

I'm not convinced by arguments between methods that focus on the character of those proposing them, when the substance of the methodologies are not examined. I expect more from the proponents in this case, more substance, evidence... and maybe a little more humility. Process improvement is not a one shot change from waterfall to agile. It requires insights from many different quarters to produce the best possible result for the business.

Why?

If you've not already picked up Simon Sinek's "Why?" video it's worth a watch. Thanks to Jean Tabaka for highlighting and expanding this thought in her presentation at GOTO Aarhus. Inspiring.

Google announces new programming language for the web at GOTO Aarhus

Gilad Bracha and Lars Bak, designers of Dart, Google's potential replacement for JavaScript, came on stage at GOTO Aarhus this morning both dressed as Darth Vader, proclaiming they had gone over to the Dart side. While replacing the lingua franca of the web is not going to happen any time soon (even in the opinion of these guys), the language does look interesting. It has optional strong typing claiming both the flexibility and ease of running of a language like Smalltalk, with type safety (to a point), modularity / team programming features and better code completion tools of languages like Java.

Interestingly the second presentation of the day was also from a Googler (Alex Russell) whose contention was that the problem for web developers was not the language (!) but the platform, with most of delays and impediments to powerful web programs coming from the need for network roundtrips.

Anyway, it's definitely worth taking a look at the early prototype release of Dart which is available here: http://www.dartlang.org/

Finding tasks in your Personal Planner

If you can't see the tasks you expect in xProcess Personal Planner check the filters. If all the boxes are unchecked, all tasks assigned to you should show up. You can then reduce the list shown using the filters.

Another thing that can make tasks harder to manage is if you are assigned to several projects. In this case consider using just one xProcess project and moving the other tasks to parent tasks with this project. The auto-scheduler in xProcess handles each project separately so if you are assigned to several you have to divide your availability between the projects first. On the other hand if you have just one xProcess project you can control the order in which the various parts of the work are schedule using priorites (see "Driven by priority").

Measuring Progress and Performance in Large Agile Developments

Large agile programmes can suffer from the worst of all worlds - management managing with "on-time-on-scope-on-budget" in mind with a methodology which is designed to allow all three of these variables to change during the project. Having spent the past 18 months grappling with this problem in one of the largest agile projects in Europe, I'm off to Denmark for the GOTO Aarhus conference next week to share some of my conclusions with delegates - and hopefully learn from others' experiences.

The concept of measurement in software projects is not new. But nor, over decades of trying, has it it been hugely successful. While it is tempting to draw up very long lists of what can and should be measured to improve team performance, I am very much of the opinion that less is more, and that the place to start is the basics. Every project must measure cost; and if they look at the calendar they can measure time. Agile methods use story points to measure size, which although it is a relative metric, only providing an estimate to the story's size compared to others in the team's backlog, it is possible to build a picture across many teams of the backlog size for a whole programme. These 3 metrics of cost, time and size are the foundation metrics that all teams need. While Earned Value Management (EVM) is a traditional method for measuring the degree to which a team is following a plan, it can be modified for use with agile projects where the scope of the backlog is dynamic. It's potentially a very powerful tool for management to home in on problem areas and it's one of the techniques that I recommend for hybrid life-cycle projects.

The 3 metrics (cost, time, size) provide the basis for moving on to more interesting but much less measurable parameters such as quality, business value and productivity. These are the real quantities we'd like to know definitively. Unfortunately "interesting" maps to "elusive". As W. Edwards Deming said, "The most important figures that one needs for management are unknown or unknowable... successful management must nevertheless take account of them".