Verfasst von Authors: Fritjof Schmidt, Cologne; Lukas Römer, Berlin
13.08.2020
Introduction
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 (ScrumAlliance, n.d.), which was created in 2001 by thought leaders in software development, who were aiming to enact a new way of 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 promising to cater for that need. Development just took too long and was not flexible enough to ultimately meet the expectations of end users.
The solution of Agile methodology and its frameworks (such as SCRUM, LeSS, SAFe) is trying to enact a system of people, processes and structures, which allows for a maximum of user centricity and great ways of adapting to new information and needs. It only makes sense that after we have seen especially technology companies having great success with this methodology during the last years, other industries and departments are trying to adopt this way of working to reap its benefits as well.
But does it always make sense to work Agile? 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). In this article, we will try to outline what environments best benefit from working in an Agile way and in which scenarios it proves to be more efficient to stick to more traditional project management methods, e.g. a linear PMLC model (Flynn, 2007).
Uncertainty and complexity — the what and how
First, let us look at what uncertainty and complexity mean in the context of project management. This is based on the VUCA strategic leadership theories (VUCA-World, n.d.) and the Cynefin framework (Snowden & Boone, 2007).
Uncertainty can be described best 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, as well as 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.
Therefore, both uncertainty and complexity 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 to 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 test and observe the system’s reaction.
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 with different perspectives on what the goal is, more alignment and corresponding 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 take their needs and expectations towards your project into account.
The Agile mindset is strongly centered around user and stakeholder centricity, meaning that frameworks, which make use of Agile methodology incorporate many processes to align complex requirements with a bunch of 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 agile frameworks a good choice for complex projects with a lot of stakeholder involvement.
On the other side 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, you are not able to reach out to them and ask them for regular feedback. As a result, the usage of Agile methodology might not be optimal as the whole process is designed around getting this feedback.
Team setup
We know the challenge from the past decades of software development to integrate “Business” and “Developers” despite acting in silos.
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 by advising to 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 in situations in which fundamental changes occur. 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 project progress.
When it comes to project setups, diverse teams work best in Agile environments. It allows them to maximize their different competencies. Therefore, with a highly diversified project team it makes more sense to setup agile methods.
On the other hand, if you have a small set of competencies needed for success of the project you will not need the processes, meetings and tools suggested by Agile frameworks. Even if 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 less discussion points.
Project controlling and KPI
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?
In this case, 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 – be it through growth and bankruptcy or respectively 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 even more clearly in order to not leave the development team out of responsibility. It is less a justification for tracking “Agile KPI” but 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 are 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 conducting 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 (like many environments nowadays), 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.
Also, we strongly advise to work together with people who know both Agile methods as well as traditional methods if you plan to work Agile to find the appropriate courses of actions in each situation and not simply following Agile methods. We need to keep in mind, that it imposes a change to the way people work together and how projects are managed, which makes Agile methods a change project on its own. An example would be larger companies who spend several years on Agile transformation projects, ultimately transforming a good part of how their business works on a very fundamental level.
Sources:
ScrumAlliance. (n.d.). The Agile Manifesto. Retrieved August 13, 2020, from https://www.scrumalliance.org/resources/agile-manifesto
Snowden, D. J., & Boone, M. E. (2007). A Leader’s Framework for Decision Making. Harvard Business Review. https://hbr.org/2007/11/a‑leaders-framework-for-decision-making
VUCA-World. (n.d.). LEADERSHIP SKILLS & STRATEGIES V U C A world. Retrieved August 13, 2020, from https://www.vuca-world.org
Flynn, T. A. (2007). Integration of the project management life cycle (PMLC) and the systems development life cycle (SDLC) in accelerated project efforts: adapting project management best practices to unreasonable requests. Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Newtown Square, PA: Project Management Institute.