Agile Knowns and Unknowns - a report from the 2008 DSDM Consortium Agile conference
The 2nd Agile Conference was held at the Excel Centre in London (Sept 24/25). Although not a large conference there was a feeling that this year there were more project management professionals attending then there were representatives of the already converted Agile delivery community. There is a built in tension in the conference theme between Agile in a project management sense and Agile in an I.T. delivery sense. Certainly it makes perfect sense that an Agile I.T. project should be managed according to Agile principles. What is less clear is whether Agile adds any value as a generic method or if what is being branded as agility is actually more akin to sensible and pragmatic project management principles that owe very little to the founding principles of the Agile manifesto.
In the presentation by Adrian Page from E-on and Dominic Stow from Fronde Systems their experience of implementing the programme described in ‘Radical Project Management’ by Rob Thomsett was described. Adrian had successfully reduced four disparate ‘change’ teams down to a single team reporting to him. He had introduced an approach across the Retail division of E-on that specifically focussed on both the content of project management, the plans, reports and deliverables, with the context of project management that gave focus to politics, stakeholders, expectations, sponsors and the like. So far, so sensible.
What was unclear was whether the adoption of terms such as ‘thought leader’, and ‘deep dive’ was helpful or rather served to make the concepts less accessible, and to appear more scientific then they are.
An interview with Peter Morowski of Borland Systems was enlightening. Peter described the adoption of classical Agile principles across Borland that were delivering quantifiable benefits. The object of the exercise was to deliver software releases more quickly, that were more feature rich and stable to enable the company to compete with IBM’s Rational product suite. As a software business, Borland is a natural fit for the adoption of Agile. What started as a grass roots movement in the organisation gained executive support which has allowed many competing variations of an Agile methodology to be consolidated into a single approach across teams dispersed geographically. Demands for new features are collected in a big metaphorical bag coming from their customers through marketing, product management, and the technical team. There is a new release every 3 months that is broken down into ‘sprints’ that result in a code build that demonstrates progress in a highly visible manner. These releases allow Peter to gauge progress and understand where there are bottlenecks that require his attention.
One aspect of the Agile approach is to have daily meetings known as ‘stand ups’ (because everyone stands up, thereby keeping the meeting short) where each person declares what they achieved the day before and what they plan to do in the coming day. This approach works well for motivated and talented employees, although it can be more testing for others as there is ‘nowhere to hide’. The Borland experience is that the employees who have tried Agile generally like the flat hierarchical structure and a work group that is self-organising. Although not to everyone’s liking initially, some employees have been encouraged to participate more through personal ‘performance improvement plans’ and raised their contribution correspondingly. Others however have left the company because they do not find it a comfortable environment. Overall, the reaction of the teams to the experience, of the company to the improvements, and of the customers to the product has been judged positively.
Peter made the point that effective business requirements management was an integral key to the Borland success, where they use UML use cases and scenarios as the basis of their requirements representation. Progress is then measured against the delivery of working code that satisfies a particular scenario. This way of working integrates requirements with testing with progress reporting and it is a fundamental to their success.
Because Agile dispenses with the familiar lifecycle stages of a project, analysis, design, coding, testing and variants thereof, the presentation ‘Gaining Boardroom Support for Agile’ addressed the problem of selling an approach that appears to fly in the face of what is commonplace to the enterprise executive. One way of countering this argument is to involve stakeholders from the outset, seek to highlight the fact that the differences bring advantages, such as disposing of the risk register with its green, amber, and red statuses that often fail to deliver project value.
Traditionally, the boardroom is interested in answers to the questions ‘how much is it going to cost’ and ‘how long will it take.’ A process such as Agile however, that dispenses with formal lifecycle stages, might be thought to make it harder to answer those questions and therefore to encounter resistance. Although historically the answers to ‘how long’ and ‘how much’ may have been vague and inaccurate, it is difficult to do without them without putting something else in their place. The answer is multi-fold. According to the DSDM Consortium (the conference sponsors) the project will always deliver a quality product that is on time and on budget. The variable in the mix is the functionality. Functionality is expressed as scenarios or user stories from what is termed the product backlog. The length of the project is divided into ‘sprints’, which, for instance, may be 3 months. Each sprint is itself divided into iterations which in this example might be 28 days long. At the end of each iteration there will be something to demonstrate to the product sponsor; working code.
Fundamentally it is no harder to estimate an Agile project than a traditional project, and the results are liable to be more accurate, because the Agile approach requires a more robust representation of user requirements than a conventional approach (waterfall, RUP et al). The variable is then the number of requirements the team is able to fit into the project sprints. As stakeholders in an Agile project are always encouraged to prioritise the absolute ‘must have’ behaviour over the ‘nice to have’ behaviour, the chances of a product of value being produced is greater than in other approaches.
The DSDM consortium have launched a useful and concise guide to project effort estimation by Mairi Osborne and Barry Fazackerley, that introduces all the various approaches that may be taken to estimation. All of the methods, to a greater or lesser extent, equate the accuracy of the estimate with the thoroughness of the requirements representation. The better the requirements, the better the estimate. The more recent techniques of ‘story points’ and ‘use case points’ are arguably the most useful. Therefore there is a powerful premium on being able to strike a balance between well-articulated and unambiguous requirements that can be produced early. Unfortunately, none of the presenters addressed this need and its seeming contradictions.
Agile offers different advantages and challenges to different stakeholders. Where a third party is involved in a competitive tendering scenario for a customer, things can get tricky. Mike Rowlands is a director of LShift, a software development company in London with a diverse portfolio of customers. Agile development suits their organisation which exists to deliver working systems, not to produce intermediate project artefacts. They follow the structure of DSDM Atern and pitch to customers to engage in a feasibility stage during which requirements are captured and evaluated. The customer may then choose to stay with LShift or to take the early work to a different supplier; either way they have used storyboards, scenarios and use cases to first flesh out the scope of the project. After the early engagement, LShift are happy to quote a fixed price to deliver the project, rather than the more common time and materials estimates that the big players enter into to do such work as the government projects that often go so spectacularly over budget. Mike is resigned to not winning that kind of work. He knows he would have to bid unrealistically low, based on limited information and then hope to recoup his costs through change requests. This is a process that he sees as being corrosive to the customer relationship, and simply not much fun.
To return to the question as to whether Agile has escaped its software roots and is really an alternative project management methodology? If you are running an Agile software development delivery then the project manager has a new jargony name, the ‘scrum master’. The project structure is very flat, in that all the team members are developers. Other roles, such as analysts, and architects are not explicitly mentioned as being part of the team, although they must be in there somewhere, it simply isn’t quite clear where. The scrum master is much more like a coach on a sports team then a traditional project manager. Her job is to get the best out of her players, it is not to slavishly produce project plans and progress reports. Instead progress is measured on ‘burn-down’ or ‘burn-up’ (not ‘burn-out’) charts.
Whether Agile holds any answers for project management in general is harder to say. Like in so many past initiatives (flavours of the month) they burst onto the consciousness with new terms that make commonplace activity sound more exciting than it really is. Agile is no different, it comes with a whole set of terms that sometimes make the simple ideas less accessible because they require the reader to first navigate the language.
The Agile principles were first articulated as a response to imprecision, an imprecision in requirements. If your project is characterised as having imprecision, then Agile may be right for you. Otherwise, project management remains as it always has and the ability to deliver successfully rests on competency, be it radical competency or that of common sense.