Skip to main content


Showing posts from 2012

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. Absolutel…

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 a…

"Continuous Delivery" - Jez Humble and David Farley

What is the foundational idea in agile software delivery? For me at least it is the idea that requirements for change in a system can be delivered one by one. The implications of this idea are far reaching, not least in the ability to track how those requirements change as the world changes. Yet too often those seeking to change to agile miss the difficult step, the prerequisite without which the pay-off of agility is unattainable. They adopt a methodology that provides the framework for the  interaction of teams and business, tracking progress and quantifying velocity without seeing that the one-by-one idea has changed things (or it needs to change things) at a much more fundamental level. Without being able to integrate, test and deliver each of the myriad of small changes reliably and - most importantly - rapidly/cheaply, this idea is uneconomic. If we are building, integrating, testing and deploying systems manually we cannot do it for every small change. We have to revert to a ch…

New Release for xProcess - feedback request

We're planning a new full release of xProcess in the next few weeks, which will incorporate all the features released in the beta versions last year and several additional fixes and changes. If you have any feedback from previous versions which have not been shared through the forums, or if you are able to download and run the latest source code version and provide feedback, please do so as soon as possible as such feedback is invaluable prior to the release. Thanks to all our users - we really appreciate your feedback and help.
To download the latest version use this link:

The Last Shall be First - Continuous Delivery

One of the key lessons of agile processes is that the final step in your process - delivering software to your customers - is the first in importance. The best way to optimize the process is to work backwards compared to a traditional software lifecycle. When Dan Haywood and I laid out the outline of our "Better Software Faster" book, we decided to emphasis this by putting the chapter on build and deploy at the beginning - the first after the introduction. It's where agile teams should start in new projects or process transformations. Ensure that you can automatically build, deploy and deliver a tested change to your system, before you spend a great deal of time in building anything. If you don't do this you'll end up with a great deal of wasted effort further down the line, or worse still a waterfall process struggling to free itself from inappropriate practices and vaguely agile terminology!

The Seven Habits of Spectacularly Unsuccessful Executives

Eric Jackson's article for Forbes under this title is illuminating. I'm afraid it put me in mind of some CEO's I have worked with (and I hope there are enough of those over my long career in the business to keep the libel lawyers at bay!). More than anything I think the tendency - not just in CEOs of course - to attribute success simply to one's own genius / hard work / insight / inspiration, and all failures to the work of others, is the destructive habit I would pick over all others. When circumstances and good work conspire together to provide outstanding rewards, one does well to recognise that it is not simply one's own talent that has produced it. When CEOs and management boards believe all the success was down to them, their companies are in serious danger!