First a brief background. Shortly after I started working on agile projects here, we began to realise that there were things that we were forgetting to do. Some were little things but others were quite important and had an impact on the business. One example was forgetting to update the tags that provide site statistics. When the day after implementation it appeared as if every visitor suddenly dropped off the site at the same page the fault was obvious, but we needed to remember that sort of stuff. To compound the problem we were a rapidly growing company and new people were starting almost every week. So we started creating “generic stories”.
Initially, this sounded like a fabulous idea – we could load them into TFS and print out cards for timebox planning workshops. Cool!
But then the list started to grow. The handful of stories became a substantial list and the stories spawned tasks that had man-hour estimates against them. Soon there were over a hundred of the things covering everything from the critical to the obviously trivial stuff we simply could not forget (like deploying to system test). The project managers were using this ‘extended checklist’ with varying degrees of commitment. Basically it was hit-and-miss at best. I was publicly not in favour of generic stories right from the start. They just felt wrong, but although I could provide a number of reasons why, it was months before a better way occurred to me.
What followed was an exercise in looking at who had responsibility for each item, and clarifying those responsibilities. I then created a framework for governance based on the concept that the project manager could no longer be held responsible for everything on the project; that the stakeholders in an agile team had that responsibility. So for example, responsibility for ensuring compliance with development standards lies with the Architect, responsibility for ensuring that the application complies with security standards lies with the Security manager, etc. The framework provided checkpoints at appropriate places in the Atern lifecycle at which we could ask those stakeholders whether they were satisfied that the project was proceeding to their satisfaction. If so, the go-ahead is given. If not, the team is prevented from proceeding any further.
This concept, I have discovered, is not new. Scott Ambler created the Disciplined Agile Delivery approach which is very similar in concept and also method-agnostic. My framework is unashamedly based around DSDM Atern because that is what we use, but the concepts can be applied to Scrum as well. As published in-house, it comprises a life-cycle diagram with hyperlinks for a short checklist of role-specific activities at each stage, checkpoints with instructions on what questions the Change Board will ask and which stakeholder is required to provide each answer. Supporting material is provided in the shape of role descriptions and responsibilities and a collection of ‘Agile Guides’ as reminders of how to do things like estimating, planning, user stories, retrospectives, stand-ups etc.
I am convinced that this is the right way to govern agile projects – give responsibility where it belongs and simply ensure that they are keeping all their stakeholders happy. After all, they are the people who really care when something goes wrong. What this framework provides is a mechanism whereby they get visibility of any problems and the opportunity to do something about them before it’s too late.