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.

"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 change-freeze and a batch process for stabilisation and release.

So - back to this book. Why is it so important?

What Jez Humble and David Farly have done is provide a detailed and practical guide for teams to provide the foundation for their agile process. They could have written a shorter book and if they had I guess even more people would read it, but it would not have been so useful to this essential process in adopting agile - integrate, test, deliver every incremental change continuously. The book is packed with practical advice, experience and discussion of individual tools and practices. Although the book is clearly targeted at practitioners and will give them a treasure store of advice to move their project and organisation forward, I believe that managers and senior executives should also study this book - if not to examine the detailed discussion on every page, at least to understand the importance and complexity of "continuous delivery" in any agile adoption, and the enabling technologies that release its power. Continuous delivery is an aspiration. It's an assymptote that may approach the ideal but never attain it. So even if you have started down the route that Jez and David have outlined, you will find much here to inspire and guide your continuing journey. But if you still think agile development is only about defining and prioritising stories, and that continuous integration and automated build, testing and deployment are optional extras, you need to read this book now, before you waste an awful lot more of your company's money.

Scrum Log Jeff Sutherland: Release Duration and Enterprise Agility

Scrum Log Jeff Sutherland: Release Duration and Enterprise Agility: Here's a very compelling presentation about the importance of reduced lead times.

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: https://sourceforge.net/projects/xprocess/.

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

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!