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".

The New Action Mechanism

With the release of xProcess v3.5 we have implemented a new way of collecting data through Actions:
http://sourceforge.net/apps/mediawiki/xprocess/index.php?title=Reporting (the Recursive Solution). Existing actions can still be used but those that have a tendency to generate large amounts of data may need to be rewritten in order to get the benefit of the new mechanism.

The following example reworks the Work Log for Person action.

In which ever Process you want to, create a new Action called 'Get DailyRecords for Person'. This will return a set of daily records in a date range and is the FetchSet Action.

The first difference we see in v3.5 is that there is a new Editor for Actions. The Editor is split into three tabs:

• Editor tab – a text area for the OGNL Expression

• Details Tab:

• Action Name - the name of the action
• Applicable to - What it is applicable to (any element is the default)
• UI Action - should it appear on context menu for element its applicable to?
• On this tab are a further two tabs; Parameters: add the Parameters that will be presented to the user when the Action is run. These parameter values are sent into the OGNL expression when run. We will come onto the Export tab later.

• Test Action Tab:

• On the Test Action Tab you can choose an Element to run the Action on to test it and enter the parameters for that action. It is recommended that you create test Elements for this, as the Action may change that Elements data.
• The lower part of this tab shows the output when the test it run

For the 'Get DailyRecords for Person' we just need the OGNL for retrieving the daily records, so in the Actions Editor we enter in:

#project = projects.isEmpty() ? null : projects.iterator().next(),#from

= (#project != null) ? #project.getDayProperty("fromDateForReport") :

null,#to = (#project != null) ?

#project.getDayProperty("toDateForReport") : null,

#dailyrecords = getWorkLog(#from,#to,null)

Hit Ctrl+S to save the Action.

The next Action to create is the 'Generate Work Log Details'. This Action is the Subordinate Action. You can have one or more Subordinate Actions, and these Actions are run against the data set that the FetchSet Action returns. The OGNL to enter in this Actions Editor is:

#output = '"' +

day + '","' +

assignment.task.project.label + '","' +

assignment.task.label + '","' +

assignment.requiredResource.roleType.label + '","' +

time/60.0 + '","' +

logEntry + '","' +

confirmed + '"',

#output = #output + '\n',

#output

Hit Ctrl+S to save the Action.

The final Action is the 'New Work Log for Person'. It's OGNL gets called before the FetchSet and Subordinate Actions, so we use that to provide the column header that will be written to file:

#project = projects.isEmpty() ? null : projects.iterator().next(),#from

= (#project != null) ? #project.getDayProperty("fromDateForReport") :

null,#to = (#project != null) ?

#project.getDayProperty("toDateForReport") : null,

#output = 'Work Log for: ' + label + '\n'

+ 'From: ' + ((#from==null) ? 'earliest booked time in data source'

: #andfrom) + ' To: ' + ((#to==null) ? #$today : #to) +'\n'

+ 'Date,Project,Task,Role,Hours,Log Entry,Confirmed\n',

#output

Then go to the Details tab and:

• Make the Action applicable to Person
• Click on the Export tab and tick the Export Action checkbox. Give it a .csv extension
• On the FetchSet Field click on the '…' and select the ' Get DailyRecords for Person' Action
• Now click on the Add button in the Subordinate section, and select the ' Generate Work Log Details' Action
• Hit Ctrl+S to save the Action

We can now test the Action via File | Export | xProcess Export | Custom Reports. When the Action runs it uses the FetchSet Action to retrieve a set of Daily Records on Projects for the selected Person. This Daily Record set is then iterated over passing in the Daily Records to the Subordinate Action.

Since each time a Daily Record is iterated over a line is written out to file, it prevents the building up of large data to be written out to file, and possible memory issues.

Reporting in xProcess

The mechanism for defining custom reports in xProcess is straightforward. It uses "Actions" (expressions which use OGNL as the language for navigating the xProcess model) and the string returned by the Action is exported to a file with whatever file extension is appropriate. There are several examples delivered with the Simple Process which are worth exploring and maybe modifying if you need a specific type of report for your project. See "How to define a custom report in v3" for more details.

Recently with users defining larger reports on projects that have been running for multiple years a problem has emerged with this mechanism - out-of-memory errors. As the text for the report is held in its entirety in memory, prior to any of it being written to file, it is clearly not too difficult to define an Action that will fail in this way if you have a reasonably large data source. To see and comment on the technical solution proposed for this problem, see the wiki for the open source project here: https://sourceforge.net/apps/mediawiki/xprocess/index.php?title=Core_Design. The new mechanism allows records to be written out one by one, but it will require reporting Actions to be rewritten to take advantage of the mechanism.

Watch this space for more details.

Update! See Tim's article on the new mechanism - http://xprocess.blogspot.com/2010/08/new-action-mechanism.html