The pursuit of the “agile business”, where multidisciplinary teams focus on solving business problems through the continuous evolution of capability, is seen as a response to the frequent failure of large, “waterfall” business change programmes.
But many organisations have mature financial and quality-control mechanisms that have been built around traditional waterfall ways of working. So when should you “go agile” and when should you stick to a traditional waterfall approach? This is a question that has confused many organisations as they prepare to undertake major programmes of business change. And it is a question that, according to Dave Machin, partner at The Berkeley Partnership, suggests they haven’t fully grasped what “agile” means.
Even when the nature of the programme prevents the use of the agile philosophy, many of the techniques can still be used very successfully
The Berkeley Partnership has many years of experience working in “hybrid” project environments, integrating agile working practices into large organisations with complex legacy systems and support functions geared to waterfall ways of working.
Mr Machin says: “It isn’t a case of when to use agile and when not to use it; at enterprise scale, I don’t think change projects are ever quite 100 per cent agile. It is about understanding which parts of agile are applicable and appropriate based on the nature of the change programme being undertaken.
“Agile is both a philosophy, and a series of tools and techniques. Being truly agile means adopting both. But even when the nature of the programme prevents the use of the agile philosophy, many of the techniques can still be used very successfully.”
IT projects have traditionally had a fixed scope, with the variable being team size and delivery date. Agile philosophy recognises the delivery date is fixed, and the team size should be stable, and defines the scope of work delivered as the thing that should change.
Mr Machin says: “If speed to market is key, if you’re trying out a new technology or business strategy, if you have an ambiguous project scope and the requirements are unclear at the start, going through an iterative, ‘build something, try it, have a look at it and then go again’ process can be a great solution.”
Instead of splitting the work into phases structured around activities, agile structures the work around delivered functionality, encompassing the gathering of requirements, the design, build and testing of functionality, within a sprint.
In a sprint-based structure, work is organised into two or three-week bursts, from initial requirement stage through to complete testing and delivery of working software. Each sprint starts with a planning session at which the team defines and agrees the work they’ll complete during the next sprint. This is done by reviewing the “product backlog”, a list of requirements, sequenced in the order in which they’ll be delivered. That sequence takes into account business priority and value as well as requirements, which are dependent on each other, and those which are risky and should therefore be tackled early.
At this stage, agile tools and techniques can come into play, specifically a technique known as “planning poker”. Individual team members produce estimates for the amount of work a story requires, which are reviewed and discussed by the whole team, with the process repeated until a consensus estimate is reached. It ends with the sprint retrospective and the team considering improvements for the next sprint.
In one project The Berkeley Partnership ran with a large energy company, the team found that following the “textbook” agile approach – tackling the design, build and test of each user-story one at a time – led to the inefficient repetition of some user-interface (UI) design work.
“Recognising this and breaking the overall UI design out as an up-front task made the teams considerably more efficient,” says Mr Machin. “While this specific approach might not be textbook, thinking carefully at the end of each sprint about what is and what isn’t working well is a key part of the prescribed sprint retrospective meeting.”
A traditional waterfall-style integration and acceptance-test phase was also added as a final check to ensure links with legacy systems, which were subject to traditional maintenance and release cycles, worked as expected. This also provided the final broad-based confidence in the solution among the user community.
Mr Machin adds: “Agile textbooks may argue that this is not necessary, but the confidence generated by a traditional acceptance test, particularly among businesspeople who are used to that discipline and haven’t used agile techniques before, was key to this project’s success.”
A key advantage of agile methodologies is they accept that requirements are likely to change over time. Instead of extensive up-front planning and design, multidisciplinary teams of planners, designers, developers and testers work on successive iterations of the product over fixed periods of time.
“With projects that are a regulatory response or that require a large group of people to achieve consensus before implementation, it becomes much more difficult to use agile methodologies, so the nature of the requirement will influence which tools and techniques are appropriate. However, some of the techniques are always applicable, albeit in a different way,” says Mr Machin.
“Consensus-based planning and the planning-poker approach are great techniques to use with software developers or systems integration teams, even in a waterfall project. And holding regular demonstrations and retrospectives within a waterfall build phase can improve efficiency, and help flush out design problems and bugs well in advance of traditional integration and acceptance testing.
“Equally, in an essentially agile project structure, including some waterfall-style, batching of activity and stage-gating can improve efficiency and help to build trust. Even the most agile of change programmes need good project-management discipline and appropriate levels of control.”
For more information visit www.berkeleypartnership.com
