Agile known unknowns
Dr Peter Merrick reports on the 2nd Agile Conference held at the Excel Centre in London where he finds an built-in tension between Agile in a project management sense and Agile in an IT delivery sense.
It makes perfect sense that an Agile IT 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.
Adrian Page from E-on and Dominic Stow from Fronde Systems shared their experiences of implementing the programme described in Radical Project Management by Rob Thomsett. Adrian said he had successfully reduced four disparate change teams down to a single team reporting to him, and had introduced an approach across the retail division of E-on that specifically focussed on both the content and context of project management that gave focus to politics, stakeholders, expectations, sponsors and the like.
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 appear more scientific than they actually are.
An interview with Peter Morowski of Borland Systems shed some light on the issue. 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 quickly, that were more feature rich and stable, and able to compete with IBMs Rational product suite.
Demands for new features are collected from customers through marketing, product management and the technical team. The results are then broken down into sprints every three months, allowing Peter to demonstrate progress and understand where there are bottlenecks that require his attention.
The Borland experience showed that the employees who have tried Agile generally like the flat hierarchical structure and a work group that is self-organising. Although not to everyones 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, the company and the customers to the product has been positive.
Peter made the point that effective business requirements management was integral to the Borland success. UML use cases and scenarios formed the basis of their requirements representation and progress was measured against the delivery of a working code that satisfies a particular scenario. This way of working integrates requirements with testing and progress reporting, and is fundamental to their success.
Because Agile dispenses with the familiar lifecycle stages of a project - analysis, design, coding, testing and variants - 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 encounter more resistance. Although historically the answers to how long? and how much? may have been vague and inaccurate, it is difficult to do without them unless something else is put 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 three months. Each sprint is itself divided into iterations which might be 28 days long. At the end of each iteration there will be something to demonstrate to the product sponsor - a 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.
All of the methods, to a greater or lesser extent, equate the accuracy of the estimate with the thoroughness of the requirements representation. 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, director of LShift, a software development company in London with a diverse portfolio of customers, said Agile development suits organisations looking to deliver working systems but can hinder bids to deliver a project in the early stages.
He added that he would have to bid unrealistically low, based on limited information, and then hope to recoup his costs through change requests. A process he describes 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 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 isnt quite clear where. The scrum master is much more like a coach on a sports team than a traditional project manager. Their job is to get the best out of their 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. As with so many past initiatives 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.
- Dr. Peter Merrick holds a Ph.D. in software engineering from the University of East Anglia. He does training and consultancy in PrinceLite, a methodology that focuses on unambiguous early lifecycle requirements representation. www.princelite.co.uk
0 comments
Log in to post a comment, or create an account if you don't have one already.