Organised by: Harry Nieboer (email@example.com) about.me/harrynieboer
Setting: my company in the Netherlands sends out employees to conferences (like the Scrum Gathering) and training. But how good are we performing anyway, and does investing in learning really help? How do you actually find out how good you are at agile? We started the discussing with three questions:
1. Who cares? Is this something management should care about? (at least according to the developers) Is this something the Scrum Master should be held accountable for? (she is the one with the mission of making the team work well together) Is this something the Team should be held accountable for? (could well be part of self organizing)
2. How would you assess your current agile capability? Should you use independent audits? Could you let your teams fill out the Scrum Checklist from Henrik Kniberg? (http://www.crisp.se/gratis-material-och-guider/scrum-checklist)
3. And then? Publish the results, to encourage competition? Act on the impediments? We discussed the above three questions and concluded the Why was missing. If you know what you want to accomplish, you can than derive what you should measure.
* For my company mostly doing projects for external clients, we are aware that we need to become a more agile company. More agile meaning being able to start up new projects fast, having environments and complete oiled agile teams available within days. The general understanding was that all should care. There were additional suggestions on how to do the assessments: surveys, 12questions (used at Nokia) and (free) checklists at http://scaledagileframework.com . There were suggestions on metrics to look for:
* How long does it take to get an idea to production
* Bug response time
* Ratio between value delivered and failures
* Business value
* Waste due to waiting (measured in queue length or total queing time)
* Cycle time Especially, you would like to measure leading indicators (and not lagging), helping you to change directions when necessary. And what to do with the outcome?
Publishing results can be risky (people might nog want to be open in answering questions the next time), although transparency was considered important. An other outcome would also be to change teams (transfer your best developer to a team having issues in this area, so they can pair and the team can grow).
Participants were: Sami Lilja, Gil Nahmias, Erin Jostes, Boris Jurcic, Oliver Gommer, Paul McGregor, Remi Kok and David Kane, and some ten others whose names we did not get.