Leadership

Why agile development is a vital weapon in the CIO's arsenal

Agile project methodologies are helping CIOs to stay ahead of the competition.

Agile is the rising star of the IT department, promising to deliver projects in a fraction of the time that it took using traditional 'waterfall' methodologies.

Waterfall-led projects involve detailed documentation of every step and specification of a project, with delivery of the finished product or service at the very end of the process. Agile, in the case of one of its most commonest forms known as Scrum, simplifies the planning stage and breaks down large programmes into iterations that deliver potentially workable products or services within two to four weeks. The result is the delivery of regular upgrades, rather than waiting years for a entire system to be delivered.

By taking the agile approach to IT project delivery the Wellcome Trust, the UK-based charity that aims to improve human and animal health, was able to deliver 69 IT projects last year - ranging from upgrading 1,000 desktops to Office 2010 in four months to implementing electronic payslips.

Since the trust's IT department began the shift to agile methodology in 2009, the department has delivered projects that have helped realise £1.9m-worth of cost savings.

Mark Bramwell, head of IT for the Wellcome Trust, said: "It's allowed us to support growth, to work smarter and more effectively and realise productivity gains and savings."

The agile approach immediately slims down a project's preparatory documentation and design work. The trust has replaced months of drafting design specifications with sessions where the IT team, their outsourcing partners and business users hammer out ways to solve business problems.

"We can typically condense six months of activities down to a small number of days or weeks," he said.

"It's about 'Let's not try and pin down everything on day one, because we're not going to know all the answers on day one'. Instead it's 'Let's get the important messages and the concepts clear on day one and then identify what the problem is we're trying to address, and what the likely benefit is'.

"If we religiously followed Prince (PRojects IN Controlled Environments) cover-to-cover we'd still be sat here documenting, and I believe we wouldn't have delivered half the capability we have."

Agile's benefits extend beyond rapid deployment, Bramwell said, as the closer communication between the IT teams and business users leads to a solution that better meet the needs of the business.

"Our understanding of what we're trying to achieve is much better, so we know the root causes that we're trying to address," adding that it has helped identify situations where a need can be met by an existing system or software.

Making agile work requires what Bramwell describes as a "relationship change" within an organisation, needing both the IT team and the rest of the business to devote regular blocks of time to discussing project requirements and outcomes, which they need to fit around the daily demands of the job.

"Working in an agile way means you need more access and time from your colleagues within the business to be able to sit down and co-create solutions. You've got to have strong productive relationships to work in this way."

The IT team also has to adjust to working with less comprehensive documentation, and be able to handle repeated changes to a project's specification.

"You've got to be able to live and deal with ambiguity, and within that be able to mitigate risk. It's an evolutionary journey in terms of programme delivery, rather than a rigid, structured programme delivery."

Another danger with agile projects, Bramwell said, is that they can get stuck in the design and creation phase, as the team gets addicted to constantly revising the what they project will deliver.

Bramwell said: "You deal with this through good project management, good business analysis, good governance, and reminding people there're still benefits to be delivered, targets to hit, and still a cost of ownership associated with a programme."

He estimates that it took about 18 months to get his team of 42 IT staff and outsourcing partners up to the "maximum effectiveness" in terms of agile delivery.

But he said that he found that the IT team have been keen to embrace agile: "People take great pride and motivation in delivering more. If you spoke to anybody at the end of a year, would they take more pride in having delivered 10 projects quickly and well or one project?"

Agile's modular and less documented approach clearly isn't suited to every IT project, for instance those involving large infrastructure upgrades or to develop a mission critical piece of software.

But Bramwell said that any business that doesn't have agile capability risks being left behind by its rivals.

Agile organisations, Bramwell said, "have one eye on the horizon so they're anticipating what the changes are going to be, and if leftfield events come they are able to respond to them more easily - so they are much more ahead of the game than the competition."

About

Nick Heath is chief reporter for TechRepublic UK. He writes about the technology that IT-decision makers need to know about, and the latest happenings in the European tech scene.

9 comments
TownsendA
TownsendA

What Agile is coming across as is that "forget the planning just do something"!Typical user and management responses. Its the PM who makes a difference and the complexity and lifespan of the project are big influencers. If you want to mess about with MS and desktop jobs maybe Agile is OK. The problem with starting development early is that mistakes are more difficult and costly to correct, something the waterfall method tries to avoid.

dmigliori
dmigliori

Agile is interesting and as someone other said it could fit into a PRINCE approach. just pay attention to a couple of things. Most project suffer from two critical factors: 1) Lack of project management (you are not able to control your project in terms of managing budget, timelines, scope and quality) 2) Lack of business sponsorship If you don't fix these issues swithcing to agile project management will make things even worst, since 1) Whitout strong control on the agile iterations everything could happen 2) Whitout strong sponsorship from the business all the approach will rapidly fail since you'll loose the spin from an iteration to the next one So my personal conclusion is that agile can make a healty project environement even more performing, but if you have a sick project environement it will not solve your problems

minstrelmike
minstrelmike

The reason agile works for us is because I can produce something the next day that _forces_ the business people to pay attention. Usually in the first meeting they're carping and whining about wasting time when we (IT) just need to build them something. They don't answer the questions I want answered and think I'm being picky and don't want to do any 'work.' Same old same old. Next day, I give them a web page to work on and tell them this is the system unless they want to put some more work into it. Then we start talking about each of the buttons and they realize that if there are 3 different possibilities, I NEED ANSWERS FOR ALL 3 SCENARIOS. They have to put work into it. That's the user insight that _never_ occurs in the waterfall model. For me, the best part of Agile is that it either forces the users to get involved or it lets the developers know no one cares. It's a time-saver either way.

charles
charles

Sorry to be a naysayer but having used agile on several projects I don't find it to be the silver bullet that it's cracked up to be. The assertion that repeated rework and lack of design are things that make developers more effective is clearly misguided. Initially agile just puts lots of pressure on developers to deliver very fast and at the expense of quality. Then when they get used to it they learn to pad their quotes with huge margins for error sometimes five times the reasonable estimate so that each task becomes an epic and is split across many sprints but guess what, they always deliver at the end of the sprint. I find very few project managers or executives in higher management who are willing to subject their time to the same scrutiny that developers have to put up with in Agile. As for the comments on Prince methodology the author clearly has no idea what this is about since Agile methodologies can sit quite happily within the Prince framework. The reason Agile has been so eagerly adopted is that it is the latest flavour of the month and to be anti Agile is to be anti progressive, not a career enhancing stance for most programmers. This silver bullet like many before it will disappear into the mists of time, another failed solution for overrunning IT projects. Good projects are delivered through good project management not by the latest development fad.

Ricky Tandiono
Ricky Tandiono

Agile helps in bringing the business user and IT closer and lower the possibility of failed project as with waterfall, often that the system design might not touch the detailed operational need of the business user. Agile with its constant short development cycle help to address this. But there is also a problem compared to the waterfall where in the waterfall, the involvement of the business user is heavy at the start and at the end, but for agile, it need constant interaction with the business user. Very often that the business user always busy and does not have enough time to constantly meet with the IT and review the product delivered, hence this can lead to the downfall of the agile methodology.

joecamaro
joecamaro

What if you have a dispersed, diverse set of end users and you do not have a well defined system scope? Does Agile help then or do you need to spend some time scoping and understanding what the needs are before launching an Agile effort?

Zzyzyx
Zzyzyx

You don't necessarily need to have it all planned up front in all cases. The value of the Agile approach is that the customer gets value from the project with a "potentially deployable product" sooner than with the traditional approaches. Since many times there are unknowns in what the end user really needs, you can mitigate that risk by delivering perhaps some initial core functionality first and then expand upon that functionality as new "needs" arise. This is where the "product backlog" comes in. There is a list of things on the product backlog and you are continually adding new requests from the user. As the product owner prioritizes that backlog some of the new needs may be prioritized above previously entered items. This flexibility means an Agile project is always focusing on the features that provide the customer with the greatest value. Planning is NOT REMOVED but occurs at regular intervals rather than all up front. On the other hand, it might be difficult to build a bridge using an Agile approach. It would be difficult to start the east bank abutment at one point and then being Agile build the second abutment up river. Some projects may not lend themselves to being Agile and like the bridge may require most or all of the planning up front.

Zzyzyx
Zzyzyx

Agile thinking has been around for quite awhile. And you are absolutely right that "good projects are delivered through good project management." That is no different for an Agile approach. Agile has key principles that must be utilized in order for the approach to work. Saying that "We'll do Agile for everything BUT..." is like saying I'll do the traditional waterfall method and gather requirements BUT I'm not going to do a design document or I'm not going to put milestones in my project. You get the idea. That thinking doesn't work for waterfall and it won't work for Agile either. If you are willing to embrace the approach then it can be a good tool in your toolbox. The article points out that it isn't your only tool and some projects might not be as well suited to an Agile approach. So, again your right it is not a "silver bullet" or "one ring to rule them all". Lastly, when you have folks that are used to doing things in a particular "waterfall" way it can be hard to switch paradigms. You can't just wake up one day and say that we are going to do Agile from this point forward and we are going to do it flawlessly. It took the trust's IT department 18 months to get up to speed on this approach. It helps if you can find an industry expert or an outside firm to provide some support or training while you take on this new process. Agile does work. There is plenty of evidence to show that it is a viable and sustainable approach.

Ricky Tandiono
Ricky Tandiono

In a way, agile helps when you do not have a well defined system scope as you can build first then improve once those generic features is there and user help build it by testing it. Rather than you never build it because you can never really determine what's the final scope or how the system should be built. But this then also have a downside that sometimes the user project scope can lost its focus. Good direction, project management and clear goal of the system will help to maintain the application development to achieve the goal.