At the moment, everything seems to be ‘agile’. We see ‘agile’ projects, ‘agile’ software development and more recently ‘agile’ organisations. In this quest to be more agile, the very premise of agile itself seems to have been lost. In this article, I will explore this thing called ‘agile’ and will attempt to address a few problems that have developed in relation to agile.
So what is ‘agile’?
The Agile Manifesto was first published in 2001 as a call to arms for software developers. Through this manifesto, the Agile Alliance identified the key principles for agile software development. This was somewhat of a radical change from the existing methods used commonly at the time, and spawned a wave of new techniques and actions that have changed the way software has been developed ever since.
Agile Principles from the original Manifesto
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Having spoken to hundreds of IT project managers around the world over recent years and through various working groups developing international standards I have come to identify a few problems in relation to ‘agile’.
Problem 1: ‘Agile’ is used to describe a multitude of different things
I recently presented at an IT Project Management conference and the topic that kept coming up was ‘agile vs waterfall’. Various speakers over the two days extolled the virtues of agile and how their project, organisation, product or department had been run, managed, or delivered using some type of ‘agile’ process.
What was of interest however, was that when each speaker used the term ‘agile’ they meant different things. Some speakers used ‘agile’ to describe the interactive development approach used, whereby software was developed in a series of stages or phases. Others used ‘agile’ to describe specific tools and techniques, such as backlogs, Kanban boards and daily stand-ups. Others used ‘agile’ to describe the specific mindset that existed in the organisation which was largely one of flexibility and change. This highlights the very challenge that ‘agile’ itself may not be that well understood. Perhaps in the quest to be a cutting-edge organisation, individuals had latched onto the trendy ‘agile’ term and then everything they did was ‘agile’.
To add to the confusion there are more than twenty different standards and a number of certification schemes that offer credentials or accreditations for individuals working in agile environments. Recently we have seen growth in ‘agile project management’ with the Project Management Institute and Axelos offering certifications in Agile Project Management and Agile PRINCE 2 respectively. The Agile Business Consortium has also added to this plethora of standards offering guidance for Agile Project Management, Agile Program Management and Agile Business Analyst with certification being available through APMG-International.
Problem 2: Agile isn’t always the best approach
The next problem I have come across is that agile isn’t always the best approach to use. Whilst agile development methods work very well when used by experienced teams who are experienced in their use, using an ‘agile’ approach is not always possible or even desirable.
Using agile methods requires a specific mindset and way of thinking, which is very different from the way many organisations currently work. In some organisations, such as those that are large, hierarchical and siloed, agile is just too radical or different and will likely be either killed off or the project may face significant resistance. In organisations that are more risk averse the notion of iterative delivery, and the prioritisation of capability in the backlog, may not be acceptable practice. Instead, a clear set to actions and agreed dates may be the preferred approach.
In larger organisations, procurement policies can also work against the agile approach, particularly when the procurement team require a clearly articulated Statement of Work to send to suppliers to quote against. It can also be very difficult to deliver in an agile manner when most of the development team is either outsourced or are contractors hired to perform a specific role.
Then there are the projects that have non-software components, whereby an agile type of development method may just not work.
Problem 3: Agile is not a Project Management methodology
Agile is a software development and team management approach, not a project management methodology. Just because you use an agile software development approach, doesn’t mean that project management is not necessary or is no longer required. Some agile coaches suggest that project managers are not needed, arguing that the scrum master does the job of the project manager, in the same way some people argue that you don’t need business analysts because the project manager can do that job. In either case, it’s a dangerous move which will most likely result in either poor outcomes our outright failure of the project.
The Agile Business Consortium and APMG International both argue that agile development methods need to co-exist with project management frameworks, for example, DSTM Atern can be used with PRINCE2 or any other project management approach.
Agile development methods often don’t account for resources, manage budgets, manage risks and issues or deliver against specific milestones. Often in agile development projects, the project manager needs to carefully engage with stakeholders and manage expectations around what will be delivered when and often also has to explain how the solution will be developed in lay-terms.
So what is the answer?
In this article I have attempted to identify a number key issues that exist in relation to agile. It is not that agile approaches, tools or techniques are a problem in themselves, but rather our understanding of what agile is and how it is practiced.
From exposure to hundreds of organisations and thousands of project managers around the world, I have found it is critical to use the tools, methods and approaches that are best suited or tailored to the organisation. For some, agile will be the absolute best approach, whereas for others, the classic waterfall approach will deliver the best outcomes. In either case, project managers are still needed.