What is Agile Project Management?
Agile Project Management helps you to understand when (and when not!) to use Agile methodology in your project setup.
As most people working in the business context nowadays know, Agile methodology has its roots in software development. The underlying mindset is most prominently represented by the Agile Manifesto, which was created in 2001 by thought leaders in software development, that aims to enact a new way of Agile working and developing applications for the business use.
The main problem they were trying to solve was the delay between business users indicating a need and the delivery of software that promised to cater to that need. Before Agile ways of working, development took too long and was not flexible enough to ultimately meet the expectations of end users in the business.
The solution of Agile methodology—and frameworks that take this methodology into account (e.g. SCRUM, LeSS, SAFe)—enacts a system of people, processes, and structures, which allows for maximum user centricity and great ways of adapting to new information and needs. It only makes sense that after we have witnessed the success of Agile methodologies in technology firms in recent years, other industries and departments are trying to adopt Agile working to reap its benefits as well.
But does Agile working make sense? Keep in mind that the methodology was brought together for software development, which is a creative process (in the sense that something new is being created). We will try to outline here what an ideal agile working environment looks like and in what scenarios it proves to be more efficient to stick to more traditional project management methods (e.g. a linear PMLC model).
Uncertainty and complexity of agile methodology in project management
First, let us take a look at what uncertainty and complexity mean in the context of project management. This is based on the VUCA strategic leadership theories and the Cynefin framework.
Uncertainty can best be described by the amount of knowledge you have about what the final outcome of the project will look like. This is influenced by a multitude of factors, such as the degree of innovation, the amount of features of the final product, the environment in which the product will be used, but also by the alignment on the needs the users of the outcome and the skills you and your team will bring into the project (more on these two down below).
Complexity is an innate characteristic of an outcome and describes the amount of knowledge you have on the interdependencies between single elements of your outcome. Complexity rises with more (non-linear) interdependencies between single elements. High complexity makes it hard for us to understand how a system (i.e. outcome) will react if we change something.
Agile frameworks are designed for complex and uncertain environments.
Both uncertainty and complexity therefore play a large role, when thinking about adopting an Agile way of working. The more uncertainty there is, the more important it will be for you change the initial plan of the final outcome, as you will face more surprises (e.g. stakeholders changing their minds, new information about competitors on the market). The more complexity there is, the more need for you to try something out and see how the system will react.
Agile frameworks are designed for complex and uncertain environments.
Vice versa think about the process of building an outcome which is rather simple and strictly defined, e.g. a legal requirement: You will constantly ask stakeholders about their needs. And you will not face many surprises during the production process. Thus, in stable and simple environments the experimental style of Agile methods might be a waste of time.
Stakeholder Involvement
Uncertainty is also a function of stakeholder involvement: the more stakeholders the more uncertainty. This is because stakeholders of a project will have to agree on a joint goal and the more perspectives on what the right goal is, the more alignment and also realignment will be necessary. However, having many stakeholders and therefore many perspectives also has a very positive impact on the final output, as you will be able to make sure to take everyone’s needs and expectations towards your project into account.
The Agile mindset is strongly centered on user and stakeholder centricity, meaning that frameworks, which make use of Agile methodology incorporate many processes to align complex requirements with many stakeholders. This also includes making sure that you get regular feedback from your stakeholders on the current status of your outcome of the project. This makes these frameworks a good choice for complex projects with a lot of stakeholder involvement.
On the other hand, this makes Agile methodology not the first choice for projects with rather low stakeholder involvement and simple requirements. Even if you potentially have a lot of end users of your final outcome, but you are not able to reach out to them and ask them for regular feedback, the usage of Agile methodology might not be optimal, as the whole process is designed around getting this feedback.
Team Setup
We are all familiar with the Software development challenge from the past decades regarding the integration of “Business” and “Developers”.
The Agile manifesto is rather explicit about the fact that software developers and business users have to work together in one team to be successful. Many frameworks adhere to this principle and advise that companies create “cross-functional” teams – a term which has been widely adopted in the realms of business. But what does it mean in the context of Agile project management?
Similar to the idea that multiple stakeholders will improve the final result by bringing in their different perspectives, a mixture of competencies in a team is believed to be more beneficial when dealing with new situations and changes. In truly Agile teams, people with all the competencies necessary for the project work together on a daily basis, allowing for pluralism of perspectives during planning and speed in implementation. Silos are not allowed in Agile projects, as they impose a major threat to the speed of implementation.
When it comes to project setups, diverse teams work best in Agile working environments. It allows them to make the most use out of their different competencies. Therefore, the more diverse your project team is, the more sense it makes to setup Agile methods.
On the other hand, if you have a small set of competencies needed for the success of the project you will not need the processes, meetings, and tools suggested by Agile frameworks. Even in the scenario when you have a lot of project members, if they are very similar in their points of view and professional experience, the work is more easily organized in different work streams and there is potential for fewer discussion points and therefore may not require Agile frameworks.
Project Controlling and KPIs
The Agile frameworks provides significant autonomy to the team since the outcome is not exactly defined right from the beginning by the business. What does this mean for the financial responsibility of the development project? How complete is the autonomy of the development team?
Here it is worthwhile to take another look at the original conditions of the Agile methodology: a highly competitive environment where success and failure are closely related. Both have an immediate impact on the players – whether it is through growth and bankruptcy or simply through hire and fire.
Today we are introducing Agile in many places in the corporate environment. The teams are relatively well protected.
Remember the magic triangle of budget, quality, and scope. While the scope is set in a non-Agile project, it is obviously not possible in an Agile project. Thus, the budget for the single, incremental deliverables must be set all the more clearly in order to avoid leaving the development team out of responsibility. It is less a justification for tracking “Agile KPI” but rather a blank necessity.
Conclusion
The decision whether to conduct a project in an Agile fashion mainly revolves around the anticipated uncertainty and complexity of the project. In most cases the stakeholder involvement and team setup is a consequence of that, but act as a good proxy to estimate the uncertainty or complexity.
Agile project management is sometimes advocated as the new and better solution for conduction projects. Even though it offers a lot of benefits and is well equipped to work within environments which are prone to a lot of change (which many environments nowadays might be), working with Agile methods comes at a cost. Adhering to these processes is resource intensive and that effort will only be offset if you can make use of the increased focus on team and stakeholder alignment by improving the quality of your final outcome.
We strongly advise working together with people, who know both something about Agile methods and methodology if you plan to work Agile. Agile imposes a change to the way people work together and how projects are managed, which makes for a small change project in and of itself. Large companies spend several years on Agile transformation projects, which ultimately transforms a good part of how their business works on very fundamental level.