It could be agile?
Something dramatic has been happening to the way technology teams manage projects in companies across Australia and globally. A concept only a few years old is revolutionising the way that software is developed and projects are managed.
Otherwise conservative financial institutions are throwing out their old in-house project methodologies and embracing the principles, values and tools of the Agile Manifesto.
The Agile Manifesto was released in 2001 as a reaction to the traditional waterfall software development approaches which were the then accepted standard. Agile promotes iterative, adaptive approaches to developing technology solutions, and embraces flexibility and continuous improvement.
As Jim Highsmith, one of the co-authors of the Agile Manifesto put it in 2010: “Linear thinking, prescriptive processes and standardised, unvarying practices are no match for today’s volatile product development environments.” Everywhere you look, tools, templates and processes developed over many years are being replaced or updated with Agile methods. Contractors with genuine Agile skills and experience are considering a second house by the beach and eyeing early retirement. In the course of a few years, the technology world has adopted Agile approaches on a massive scale.
This article was first published in Australian Banking & Finance.
How fast should companies be jumping aboard the Agile bandwagon and are these or more traditional techniques more relevant for the kinds of project challenges facing financial organisations today?
In the past few years, the strategic need for change in the financial services industry has grown dramatically. Much of this need can be traced to two key events.
Firstly, the industry has been facing a wave of regulatory change since the global credit crisis of 2007. Institutions have had to implement a series of system and process changes to meet new legal and regulatory demands coming out of the US, or originating here in Australia. These projects tend to be mandatory and have fixed deadlines, which reduces the amount of investment available for discretionary, strategic change projects. Secondly, digital disruption has challenged traditional business models and methods of interacting with customers.
Bank customers now expect to be able to transact 24 hours a day through their phones, tablets, watches and PCs. The big four banks in Australia house some of the largest software development teams in the region, with much of the development effort aimed at maintaining effective, secure and consumer-friendly websites and mobile applications.
Banking and finance organisations therefore have to deliver successful projects to deal with these events, make strategic changes and maintain their technology infrastructure.Technology teams must deliver more projects more successfully than before. Can Agile help address this challenge?
An increasing pace of change
While there is a consensus that Agile practices can help improve project outcomes, there is also some opposition to them in the technology and business community. Agile supporters can display an almost religious dedication to their methods which can lead to suggestions that the cold, hard business case for Agile investment might not stack up.Agile non-believers can be alienated bythe concern that they must not object to the Emperor’s lack of new clothes.
It is also a complex subject which is understood well by few technologists and even fewer senior executives.
There is a suspicion that some organisations have taken major investment decisionsin Agile technologies without truly understandinghow best to implement them – or if it is a good idea or not.
Agile methods have a great deal to offer and are a welcome challenge to the established approaches to software development which fail expensively so often. But they are not the right solution for every project and need to be implemented well to bring the benefits they promise.
Implementing Agile badly will be an expensive mistake. Here are some Agile pitfalls to watch out for.
Is Agile the solution?
Agile principles can be applied to most projects, but are particularly appropriate where requirements are fluid or unclear, timelines aggressive, business cases uncertain and where project teams can work physically closely with their client.
Conversely, if strict formal requirements exist, then a waterfall approach may be better.Some organisations are opting to overhaul their core project management methodologies and introduce Agile across the board.
This requires very careful consideration. Some Agile concepts can successfully be applied to all projects, but many projects will still be more easily delivered in more traditional ways.
Using Agile for unsuitable projects
Agile brings concepts and approaches which are very different. A significant traininginvestment and change exercise is needed to introduce Agile. Project managers and team members who are trained and experienced in using Agile, and who can apply its principles appropriately, are needed to make it a success. The principles can be effective when applied well, but hybrid or partial Agile projects can be problematic. Avoid “fake” Agile projects that are run with a waterfall approach using pseudo-Agile language.
Not sticking to Agile principles
Project managers have been known to claim that Agile projects reduce the need for governance controls. “We don’t need a business case, defined objectives or status reports because this is an Agile project!” In fact, the opposite is probably true. As Jim Highsmith puts it: “Anyone who practices ad hoc development under the guise of Agile methods is an imposter.” Less clarity around direction and requirements means that the project governing body needs more input and oversight than usual. Sponsors and steering group members will themselves need an understanding of Agile to effectively oversee an Agile project.
Reducing governance and oversight
The answer is that an increasing pace of change and variety of projects demands a more flexible approach. Deloitte’s use of Predictive Project Analytics and our work assessing many client projects has taught us that a one size methodology does not fit all. Project processes and controls need to be adjusted to match the particular complexities and risks involved. So do introduce some agility into your portfolio management, but think carefully before making a drastic shift to Agile. It is a major investment and a significant cultural shift, which shouldn’t be undertaken lightly. Do it properly or don’t do it at all.
Tailor the fit to each project