Becoming agile
The move to becoming an agile organisation brings change. It impacts on the traditional culture and introduces new ways of working on projects – so not everyone will be convinced! What does it take to successfully introduce that change?
Agile project management has come a long way since its emergence in the world of IT back in the 1990s.
Yet the concept is still surrounded by misgiving, misconception and even mistrust by many, particularly if it entails a shift in culture, changing the way things have always been done – you know where you are with tried and tested processes, tools and techniques.
Not that using such processes is wrong, but as APM Hon Fellow Alistair Godbold wrote in his blog Process - the good, the bad and the ugly: “For many projects as they move from merely complicated to complex, sensing and responding quickly and flexibly to change become more and more important, some processes can inhibit this, or at best slow it down.”
Barbara Roberts, director of the Agile Business Consortium, agrees. “Processes are great, but you should always also engage brain – is this the right process, is it working?”
Agile isn’t always the answer. Even the most enthusiastic agile exponents accept that there will always be projects run on traditional lines and that project managers with traditional, recognised competencies, skills and qualifications will always be needed.
The issues arise when this established ‘waterfall’ way of working and its accompanying processes cannot react and respond quickly enough to the complexities and uncertainties of an ever-changing world.
Neither is the potential for the agile approach confined to software development in which it has its roots. Barbara Roberts has worked with sectors across the spectrum, from the extremely agile such as an advertising agency to the heavily-regulated end of pharmaceuticals and defence. Because it is a philosophy, agile can work for these industries, too.
She points to the D-Day landings of World War II as a study in the principles of agile, with equipment and procedures tested, refined and tested again before the first soldier embarked for the Normandy beaches. Yet APM’s own research indicates that its adoption is still largely restricted to IT.
Much has been written and published on the pros and cons of following the agile path and the theory of how to do it. APM is also reviewing its approach to agile project management for the forthcoming APM Body of Knowledge 7th edition. But there is still the question of overcoming the inevitable resistance to changing a long-established culture, both from organisations and project professionals.
Agile is a mind-set not a methodology, which is why introducing it into an organisation that relies on traditional set processes calls for a change in attitude, explained Barbara, who offers advice based on experience of helping to achieve that change.
“The reality is that the traditional concept of project management is now flawed. Adopting an agile approach is recognition of the volatility, uncertainty, complexity and ambiguity (VUCA) in a changing world.
“Whether you like it or not, agile is happening and if you only focus on traditional project management, your pool of work will get smaller and smaller.
“The start point is to get senior management to accept that the way they are working isn’t ideal – and they usually know that things are not quite as they should be, that the world is very different to even 10 years ago and they need to do things differently.”
The choice is straightforward, she said. Organisations can transform or leave things as they are with the risk of ending up with ‘water melon’ projects – green on the outside but red on the inside, resulting in overrun, overspend and failing to deliver the required result.
It has to come from the top, and a convincing case can be made to management by pointing to the benefits to the bottom line, she added. Arguments in favour include the constant focus on delivering best value at each point in time.
“Incremental delivery provides early return on investment and releasing budget for each increment or tranche of change gives better control, rather than an approach of ‘I’ve started so I’ll finish’. The agile portfolio view recommends assessing the value of the next phase against other initiatives waiting to start.
“It helps to ensure money is always spent on the right initiatives. Even adopting some of this thinking can help an organisation start the move towards more agile thinking.”
The move to becoming agile can start modestly with a couple of pilot projects that have uncertainty or volatility that would suit an agile approach. HR needs to be involved from the outset to ensure the right people are in place with the necessary soft skills, especially around collaboration and communication, with training for the whole team, including the business and the project manager.
“This is not de-skilling project managers, but rather building on what they already have,” emphasised Barbara. “Agile is an opportunity, not a threat. Allowing people to use their skills to the full, to excel, is a great motivator.”
The reasons for the move to agile should be explained to stakeholders – how it will be different and what they will gain from it.
“Prove agile with pilots and then you can start to introduce more agile techniques and more agile projects. But also recognise that not every project will benefit from agile, and that is perfectly normal.”
Agile in action
Taking an agile approach does not mean ditching traditional project management, both can be used to achieve the desired result, according to Martin Little at the Department for Work and Pensions (DWP).
Martin is director of the Fraud, Error and Debt Programme, where agile project management was introduced for software development four years ago.
“It’s not about adopting either waterfall or agile to the exclusion of the other,” he stressed. “That is not how it works or should work. It’s selecting the right tools for the job and agile is another tool to add to the existing toolkit to deliver the outcome. Where there is a lot of uncertainty, agile really helps you to work through a problem and mitigate the risks presented by uncertainty.
“We are using it to deliver elements of a project where it is not certain what the right solution is for the outcome you want, but with traditional project management tools and techniques wrapped around that.”
The DWP is a huge organisation with some 80,000 staff, 1,200 of which are part of the project delivery profession. Martin currently heads up a multi-million pound programme of six projects, of which five involve using technology to transform services for DWP staff, local authorities and for service users. The programme is aimed at delivering savings of £1.5bn and is part of the government’s major projects portfolio.
The digital projects are run along traditional lines for the business case, planning, managing costs, benefits, delivery and implementation, led by a project manager who has overall responsibility and accountability. Where an agile approach with its scrums, scrum masters and sprints comes into its own is in the actual building of software that does the job those using it need it to do.
Before agile was adopted for this element, the department used a traditional waterfall approach throughout – setting out detailed requirements for the tech wizards to go away and develop before rolling out the end product. It was only at that point after 18 months or so of building the software that it was put to the ultimate test of real staff using it. If it didn’t work in the way expected, it had to be changed and that could take up to another 18 months of re-designing, building, testing, deployment and feedback.
“Even after workshops and consultations with stakeholders to ascertain what they need, it can be very difficult to set out all the requirements at the beginning to get the right outcome, which is why there is so much uncertainty,” explained Martin. “It carries a great deal of risk because what you end up with could be quite different to what the user really needs.
“That is what drove the move to agile because it is more iterative and centred around the end user.
“Rather than spend a lot of time on upfront, doing detailed planning over a long horizon, with agile you are doing detailed planning for one cycle at a time over a shorter horizon. You are minimising the uncertainty in a problem you are trying to fix.”
Development is focused on getting something of value to the users as early as possible – a minimum viable product (MVP) – and then adding further improvements and features regularly. The length of a sprint cycle will vary from team to team, but is often just a couple of weeks. At the end of each sprint, the enhanced product is tested and released to users, allowing regular and immediate feedback.
“This delivers value to the customer and the business,” said Martin. “User research and feedback enable you to prioritise the requirement as you better understand the user’s needs and the short sprint cycles mean that you can make changes quickly. It reduces risk by helping to get the best solution for the customer.”
The agile approach was introduced in response to the creation of Government Digital Services (GDS) aimed at promoting and adopting best practice in software development and delivery.
From the outset, there was considerable investment in training staff and recruiting new people who already had the right skills. The DWP established its own academy, bringing in specialists to help teams master the agile way of working.
“It’s not a process you can switch to overnight or learn on a two-week course,” added Martin. “It is a journey, developing capability over time. We are still learning and building that capability.”
The DWP recognised that using both waterfall and agile approaches on one project could create tensions. The key to resolving this was collaboration and working together.
Going through the academy enthused project staff to adopt, use and promote the agile approach. Time was also spent with others within the organisation to help them understand why things were being done differently and if they needed to do anything differently as a result.
Taking the agile route has also helped to increase transparency for stakeholders through regular ‘show and tell’ sessions at the end of each sprint. The team explains what it has done during the previous fortnight, shows what has been built and the research carried out, obtains feedback and outlines plans for the coming two weeks.
“Stakeholders like this user-centric approach,” he continued. “It definitely helps with stakeholder engagement and getting their buy-in. It builds a much closer relationship between solution developer and the end user.”
But does it work?
“It is absolutely working,” said Martin, citing a recent project to create a new service for the DWP and local authorities working with benefit claimants. The team began testing the service with 20 users in one office who found problems on day one. By working in this interactive way, those issues were fixed within two days.
“In fact we made quite a few improvements in the next two-week sprint. There were still challenges, because there were knotty problems to resolve, but by taking an agile approach we were able to be very responsive and make changes more quickly. The feedback from those who are now using the service has been really positive.”
Lesson learned
Because if the iterative and incremental nature of agile, mistakes or the potential for them can be spotted at every small step and adapted or even halted before it’s too late for the project and the budget. Each ‘mistake’ becomes a lesson learned, an opportunity to do better in the next phase, according to Barbara Roberts.
The top lessons learned so far at the DWP as it continues on its agile journey include:
- It takes time to build agile capability as an organisation – it’s not a quick fix;
- It’s a big change for your stakeholders and you need to support them in adapting to the change;
- It doesn’t just change how you deliver, but also how you govern delivery – you will need to adapt your governance model.