Aterny Blog

Latest From Our Blog

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. Continue reading
CMMI generally has a pretty poor reputation amongst… well everyone except the process geeks. It is generally perceived as bureaucratic, pedantic, heavyweight and ultimately ineffective. So you can imagine my joy when my boss recently said we have been given a target of achieving Level 2 by the end of the year and Level 3 by the end of 2012. My first reaction was to find out more about CMMI; it's purpose, structure, goals and practices. A quick look at the SEI website and the v1.3 model for development revealed some interesting facts: CMMI is method-agnostic; it doesn't matter whether you use PMI, PRINCE2, Scrum or DSDM Atern, the goals are the same. The goals are actually things you should be doing anyway. Things like planning, requirements management, engaging stakeholders, project monitoring and so forth. CMMI provides a list of practices for each process area, but does not tell you how to implement those practices. I am now, much to my own surprise, confident that, not only can we achieve Level 2 this year, we SHOULD. After all, achieving Level2 is not the real objective. But CMMI can provide us with a model for complying with Atern's eighth principle – Demonstrate Control. We have a consultant visiting us on Friday to see the way we work. It will be interesting. Continue reading
Arguably the most powerful tool in the agilists kit is the regular retrospective. Done properly, these short meetings can have an amazing effect on a team's effectiveness. This article by Lyssa Adkins emphasises why it is so much better than just "lessons learned" Continue reading
I was thinking of starting this blog with a rambling story about what I do and a potted history of how I came to be doing what I do. But then I read an article this morning that gave me a better idea. It is this article on the origins and purpose of user stories. I like to think I've been agile (or at least trying) for just three years now but in that time I have become passionate about them. Not dogmatic, just passionate. That article is full of useful information and insightful opinion and it puts some interesting context behind the reason we use user stories so ubiquitously. But, in my experience, it is all too easy for us to take the principles of simplicity and deferring of decisions too far (see my comments after reading the article). Planning is, as we all know, essential. And while we need not – indeed should not – generate highly detailed plans, we do need to understand the size (or as a French colleague calls it the "weight") of each story sufficiently to estimate the time it will take to deliver it. But some requirements are complicated, have pre-requites and need preparation time before a team can move the card into the "In progress" column of the story board. The principles discussed in the article mentioned are not wrong. Far from it. But they need to be considered carefully. When do we turn a simple three-word requirement into something we know enough about to be able to estimate? When do the usability tests take place to shape the basic design and flow of a web site so that we avoid wasteful re-work? The answer, I believe, lies in rigorous prioritisation, recognising the need for story preparation, utilising Kanban to monitor the flow of work through the pipeline, and in spending enough time up front to determine the breadth of the projects scope sufficiently to estimate the total effort. I know of a project in which too little initial planning was done. After the first release was delayed six months – yes, six months! – the cost was re-estimated at four times the original figure. That, dear readers, is just irresponsible, and clearly demonstrates that, to be credible, agilists need to plan. Carefully. More on the topic of planning in a future post about agile methods. Continue reading