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

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.