As a SUGSA Scrum Day sponsor I distributed a little booklet I compiled. I titled it “Do Better Scrum”. Since then several people has asked me for copies. And Tobias Meyer was kind enough to suggest several improvements. So here is the second edition which you can download and use as you wish. If you have a smart digital print shop like Top Copy, you should be able to get them to print and bind it for you as an A5 booklet with a colour cover for around R10 per copy. Let me know how you find it.

Download “Do Better Scrum”

At the first South African Scrum Day, held in Cape Town on 1 September, 2009, I gave a talk on the topic of agile metrics. You can just download the slides and save yourself the pain of listening to me!

Peter Hundermark – Agile Metrics from Carlo Kruger on Vimeo.

We all know the saying “measurement drives behaviour”. Therefore Agilists are understandably wary when management demands metrics to prove that their investment in Agile practices is paying off.

I’ve done some work to identify a small set of Agile metrics that I believe to be helpful. I have drawn particular inspiration from an open space workshop facilitated by Pete Behrens (CSC, CST) at the Orlando Scrum gathering and have also been helped by my colleague Mike Freislich.

This PDF contains my conclusions thus far. I must confess that not all of these metrics are yet in place at any of my coaching clients, so I do regard this as a work-in-progress and expect the power of empiricism to show me my mistakes over time. I would also value the input of my reader .

Scott Ambler talking in Cape Town. For free! One of the Agile thought leaders, now working at IBM Rational. Also a notorious Scrum maligner. I had to go. If only to be equipped to do damage control. So I pitched up with as open a mind as any Scrum Coach and Trainer could…

After coffee and muffins, nearly 200 people filled the small Sports Science auditorium. Scott gave a discursive and entertaining three-hour talk that spanned a number of threads. His blunt style evoked laughter as the audience identified with many of his observations. Here are some of the things I heard him say – I think.

Myths and Facts

• Software development is an art rather than science with people rather than technology at its core.
• IT organisations all over the world are messed up in more-or-less the same ways; all making the same mistakes, due to all basing their way of working on the same set of false premises.
• They discover a problem, put a band-aid over it, discover another problem, fit another band aid and so on. Nothing actually gets fixed.
• Traditional project management is based on lying, and stakeholders know this.
• Earned value management is another lie – there is no value until the software is delivered. It is just not the right metric.
• The US has a $600 billion data quality problem. And it’s not getting smaller.
• We (IT) are not professionals – we don’t get respect from anybody.
• Most organisations choose to fail – it’s more comfortable to fail in familiar ways than to succeed in unfamiliar ways.
• Project retrospectives don’t work – the lessons ‘learned’ are not put into practice, because the project has ended and there is no longer motivation to do so.
• Doing things against natural human behaviour will always fail.
• Every hand-off is a risk and a point at which defects are introduced.
• Media richness theory tells us that the best way to communicate is face-to-face and the worst is via written documents.
• Change management is a euphemism for change prevention and is unethical.
• Logged defects older than a year are waste and should be deleted.
• The most valuable artefact to Agile developers is working software; the least valuable is Gantt charts.
• There is no statistical difference between the success of projects in organisations who implement the CMMI and those who don’t, whether Agile or not. There is a significant difference in success between Agile and not.
• Collocated Agile teams report a 79% project success rate compared with 73% who are “near located” and only 55% who are “far located” (requires air travel).
• Collocation results in increased job satisfaction.
• Near location often needs only a “decorating decision” to save 6% and payback is achieved in one week!
• Regarding distributed teams: (1) don’t; (2) observe Conway’s Law – distribute in relation to your architecture; and (3) use appropriate tools and techniques.
• Most distributed development is based on a lack of trust.
• Beware of off-shoring: if you’re failing now to manage your own people locally, there is no chance you will succeed in managing people off-shore.
• Fire the evil bastards who hang art on the wall in your IT department! Fill all walls with white boards or whote board wallpaper.
• A repeatable process in software development is nonsense. In every instance there will be changes for scaling, distribution, domain, people, …
• The bureaucrats are out of control…and so are the HR people!
• You can change your organisation [fix it] or you can change your organisation [move to another]!
• Lean (“optimise the whole”) helps explain why Agile works
• Two-thirds of software features built are rarely or never used (Standish report) – so don’t build them! The product backlog addresses the risk of building the wrong things.
• Business wants estimates in order to manage financial risk. Agile makes this unnecessary – we only have to fund one iteration (at a time).
• The iron triangle – one of scope, schedule and cost has to be variable; if you fix all three vertices, quality becomes the undesired variable.
• Traditional development is gambling! We need to remind management that they got burned in the past and there is (now) a better way.
• Fixed price work is unethical. As wannabe professionals we need to stand up to the bureaucratic treadmill.
• Every developer should attend a two-day “introduction to usability” course. And an “introduction to security” course.
• There are simple ways to refactor databases – to learn how, buy Scott’s book!

Call to Action

Scott made a clear call to action amongst IT and business managers in organisations:

1. Start experimenting with Agile. This is the easiest decision in decades for management to make! There is a very big upside with very little downside.
2. Train your people.
3. Get some help (coaching).

Despite his sniping at Scrum, I was pleasantly surprised at the sense he made. And I hope local organisations heed his call – my phone should ring off the hook on Monday…

I’ve been updating myself on the activites in the Prince2 camp to update this project management framework. One thing that stuck is the lamentations about the large number of PINO projects. PINO is an acronym (actually an initialism) for Prince In Name Only. In the Scrum world this has commonly been called ScrumButt, drawn from “we’re doing Scrum, but…” as well as the frequent desire to kick such teams in the butt!

Martin Fowler, one of Agile Manifesto signatories has blogged recently on “flaccid Scrum” (http://www.martinfowler.com/bliki/FlaccidScrum.html). FWIW, I agree with him.

We must constantly remind ourselves (and those whom we seek to influence) that:

• Scrum is silent on which “software engineering” practices to use, but not on their use.
• We must continuously assess our way of working against the Agile principles.
• Undone work (aka technical debt) will continue to cripple delivery of value as long as we continue allow it to accumulate.
• Scrum is just a tool to expose deficiencies and dysfunction in the team and the organisation – the problems remain ours to tackle and solve.

So while we continue to battle our demons, how about honestly calling some Scrum implementations SINO (Scrum In Name Only)?

At the Scrum Gathering in Orlando last week Pete Behrens facilitated an Open Space session on “Metrics and Myths”. We considered four categories of measurements: productivity, quality, predictability and value. In each we each contributed measurements that are either “metrics” or “myths”. We stuck them up on a wall as you can see in the photos. In this first post I’m simply showing the pictures I took of the session. In subsequent posts, I aim to construct some reasoned arguments for a few Agile metrics Mike and I consider valuable to any organisation transitioning to Scrum.

Metrics & Myths

Here is a rather long reading list that I have assembled over the last few years. Books marked with an asterisk (*) are those I have read and personally recommend. The rest are those I have found to be frequently recommended by other Agile practitioners. Within each section the books are listed more-or-less in the order that I value them.

Agile methods and principles

*Agile Software Development with Scrum by Ken Schwaber and Mike Beedle [the “Black Book”—essential reading for good ScrumMasters]

*Agile Project Management with SCRUM by Ken Schwaber [the “Gray Book”—supplements the first Scrum book with real life examples]

*The Enterprise and Scrum by Ken Schwaber [essential reading for coaches and for enterprise rollouts]

*Extreme Programming Explained by Kent Beck [a great book for team members]

*Lean Software Development by Mary Poppendieck and Tom Poppendieck [A good intro to Lean]

*Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck and Tom Poppendieck [a great read for managers who want to understand Agile]

*Agile Software Development – The Cooperative Game (2nd Edition) by Alistair
Cockburn [a very inciteful view of product development]

*Organizational Patterns of Agile Software Development by James O. Coplien and Neil B. Harrison [a great book for software architects and other team members]

Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin

Agile Software Development in the Large: Diving Into the Deep by Jutta Eckstein

The Art of Agile Development by James Shore

Additional context

*The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks [a classic]

*Peopleware: Productive Projects and Teams by Tom DeMarco [another classic]

Slack by Tom De Marco

Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity by Joel Spolsky

Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams by Steve Maguire

Teamwork

*Facilitator’s Guide to Participatory Decision-Making by Sam Kaner (2007) [a gold mine for coaches]

*The Wisdom of Teams by Jon R Katzenbach and Douglas K Smith (1993) [a bit dated, but still useful]

Collaboration Explained by Jean Tabaka

The Five Dysfunctions of a Team: A Leadership Fable by Patrick M. Lencioni

Continuous improvement

*Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen
[essential for ScrumMasters and coaches wanting to run good retrospectives]

Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth [the classic text]

Accelerating Process Improvement Using Agile Techniques by Deb Jacobs

Requirements and planning

*User Stories Applied by Mike Cohn [essential reading for good Product Owners]

*Agile Estimating and Planning by Mike Cohn [essential reading for good Product Owners]

Development practices

Refactoring by Martin Fowler

*Test Driven Development: By Example by Kent Beck.

Pair Programming Illuminated by Laurie Williams

Refactoring to Patterns by Joshua Kerievsky

Test Driven: Practical TDD and Acceptance TDD for Java Developers by Lasse Koskela

Practices of an Agile Developer: Working in the Real World by Venkat Subramaniam

Release It!: Design and Deploy Production-Ready Software by Michael Nygard

The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas

Working Effectively with Legacy Code by Michael Feathers

xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros

Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall, Steve Matyas, and Andrew Glover

Refactoring Databases: Evolutionary Database Design by Scott W. Ambler and Pramodkumar J. Sadalage

Code Complete: A Practical Handbook of Software Construction by Steve McConnell

Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Apps by Mike Clark

Agile Project Management

*Agile and Iterative Development: A Manager’s Guide by Craig Larman
[provides a useful overview and comparison of the main Agile development methods for those who don’t know which method to choose]

Agile Project Management: Creating Innovative Products by Jim Highsmith [this book is on the list because so many other people recommend it; I have read it and I don’t]

Manage It!: Your Guide to Modern, Pragmatic Project Management by Johanna
Rothman

Managing Agile Projects by Kevin, J. Aguanno