It’s the same in life as in business – if you don’t pay attention, you become immobile. And while stability used to be the measure of all things (cough), the dinosaurs, life and the markets have taught us in the meantime that too little ability to move can be a disadvantage in evolutionary terms. The solution? Agility.
The holy grail
Praise be to that which makes agile. And so today there are countless well-intentioned pieces of advice on what you should do agilely: implement projects, build up organizations, lead people, coach employees and, of course, think, communicate, plan and generally – live. But what is agile actually all about?
Roughly speaking, agile means being able to react flexibly to changes. So if we stick to project management, we have to
- go into the project without a prefabricated, rigid plan
- remain open and agile to change even during the project
Point 1. is the cornerstone of the agile approach – don’t waste time with planning, because at the beginning everything is nothing anyway. Requirements change, knowledge increases during the course of the project, so better start – methodically structured – and see what comes out. Point 2 is no less important, because once a decision has been made and an agreement has been reached, it must remain adaptable during the course of the project. This means agile in the true sense of the word: remaining flexible.
A project based on the waterfall method, on the other hand, is based on the assumption that frontloading will save us expensive troubleshooting in the end (Rule of Ten). Therefore, at the very beginning of the project, a lot of time is taken to mold wishes and requirements into a process concept. This then becomes the basis for the project scope, and (with minor changes – keyword change management) is implemented 1:1 in the technical concept and later in the system.
„Stop!“ shout the project innovators, „Reality shows that numerous projects fail to achieve their goals. And this is not least because objectives have changed and the project has not been able to react to this.“ You’re certainly not wrong about that, because often projects are actually too far removed from the customer, and too insensitive to new insights, to be able to react appropriately to changes. In the end, the customer then often gets something, but it is not (anymore) what he needs.
So agile methods were first devised in the mid-90s to counter this grievance. In 2001, an agile manifesto was finally created.
Excuse me?
There are various ideas for implementing this agile idea, some of which I would like to introduce very briefly here.
Scrum
Today, when someone shouts agile, at least one other shouts „Scrum“. Scrum was first published in 1995. The development work in Scrum is done in so-called sprints, i.e. short (1-4 weeks) development cycles at the end of which there must be a user-ready (functional, tested) result.
In the narrower sense, there is no project manager, and according to the agile way of thinking, there is also no business blueprint. The closest thing to a business blueprint is the product backlog. As is typical for agile, this is not filled with functional requirements specifications, but with user stories. User stories are colloquially formulated, short descriptions of the project requirements (e.g. Kai Simons „As an authorized dealer, I would like to be able to list all used cars in order to offer them to my customers“). The development team then determines which tasks are necessary to map this story into software in a sprint. Based on the story, the acceptance of the functionality takes place later.
Scrum has created a clear and simple set of rules around these basic elements by which projects can be completed, consisting of:
- Roles:
- Product Owner (requester, responsible for success),
- Scrum Master (governance),
- Development Team (generalists, self-organized, 3-9 people).
- Artifacts:
- Product Backlog (product requirements catalog),
- Sprint Backlog (implementation planning per sprint),
- Product Increment (completed backlog entries)
Activities- Sprint Planning … max. 2h per sprint week, planning of the next sprint
- Daily Scrum … daily communication of progress and possible problems
- Sprint Review / Retrospective … Debriefing of the Sprint
- Product Backlog Refinement … Updating and revising the Product Backlog
On the scale between classic and agile, Scrum implements the agile thoughts very consistently. The sprints are the atoms in the Scrum process, once planned, they can only be implemented or canceled, but not adjusted.
Extreme Programming (XP)
Extreme Programming is a bit more relaxed. XP emerged around the same time as Scrum, and both share the basic agile idea. The project result is created incrementally, in close coordination with the customer. XP uses some terms different from Scrum here, but is nevertheless very close to its better-known brother. Organizationally, however, it has a somewhat flatter structure:
- There is a product owner here as well
- partly this is also the project manager
- and the customer
- and in extreme cases also the user
- Developer
This eliminates the role of the guardian over the methodology governance (as it is in Scrum the Scrum Master). Meetings are also not fixed in name, structure and frequency. A daily standup meeting is recommended. In addition, the user stories (which also exist here) should be able to be implemented in one iteration if possible, otherwise the split is recommended. Beyond that, however, methodological specifications are largely restrained, and values, principles, and practices are propagated instead.
The core values can be named here as examples:
- Communication
- Respect
- Courage
- Simplicity
- Feedback
XP focuses a bit more on benefit analysis, each feature is tested for your specific added value according to YAGNI. For this purpose models of stiffness / flexibility are introduced, the more features, the stiffer my product is. Since stiffness increases the effort in creation and maintenance, it should always be avoided where it would not mean a significant drop in customer value.
Overall, XP is not quite as stringently agile as Scrum, as it gives project creators a bit more freedom in the specific design.
Kanban
Also Kanban is a representative of the agile project methodology, which is very loosely connected with the signal card technology from manufacturing. Kanban sets itself as central goal to limit the number of parallel work. This creates shorter lead times and lets us identify problems in the project more quickly.
Some practices exist for this, written down by David Anderson:
- Visualize the flow of work
- Limit the amount of work in progress
- Measure and control the flow
- Make the rules for the process explicit
- Promote leadership at all levels
- Models for collaborative improvement opportunities
It also sounds more like a general recommendation for action, and that’s exactly how it lives. Again, there are many similarities with Scrum (lean approach, transparency, many small increments, iterative release plan) but the differences with Scrum are even greater than with XP:
- like XP there is no duration for the iteration prescribed
- expert teams may be formed, mixing is not mandatory
- Requirements may be developed also over several iterations
- Kanban iterations are basically open (room for input at any time, in contrast to Sprints)
- no role descriptions
- no prioritization mandatory
Kanban sees it with the methodical defaults regarding agility still most loosely. Thus, it is also the most universally applicable, because agility solves some known project problems, but brings new challenges.
Why not just go agile for everything?
Every methodology used has its specific use case. The core competency of a strict agile approach is the unconditional focus on the work and customer acceptance.
Whoever is pushed into the shadows in this process is the sponsor in the classic project sense. If I want to get a comparatively large project (6 to 8-figure budget) off the ground, I often first sit across from someone who is sitting on the money. And this person (rightly) attaches great importance to adherence to deadlines and costs, because in the overwhelming majority of organizations, money is only used for a specific purpose. Before the budget is approved, the content, costs and time need to be planned (as validly as possible), and during the course of the project, concepts, contracts, partial acceptances and more are also required. It is impossible to present a valid schedule and cost plan to the sponsor if the characteristics of the project result are only developed during the course and can be subject to change at any time. Monitoring is certainly central in agile, but holistic planning gets really hard. Moreover, it is at least as hard to determine fulfillment based on a performance specification (when will we actually be done?).
This causes problems especially when external partners are involved. Projects of this size are almost always tackled with the help of external resources because the company cannot or does not want to meet the challenges with its own capacities in terms of know-how or load. However, if they are not to work on T&M for years without a clear target, there must be some kind of specifications that they can price and then „commit“ to. This, however, even in its weakest form (e.g. CPIF contracts – Cost Plus Incentive Fee) would contradict the agile approach, because at the beginning there is no performance specification of the overall project.
People also play a role. In the stricter Scrum approach, a development team may only consist of generalists who can represent each other for reasons of delivery reliability. Fruitful exchange with the customer is central to the agile approach. Last but not least, the demands on one’s own work planning are also very high, because there is de facto no one outside the development team to organize the actual work. However, the amount of generalist, highly communicative, self-optimized developers out there is severely limited.
Last but not least, the customer itself has a responsibility. If in classic projects with comparatively infrequent and long-term planned coordination and test periods we already have difficulties in getting technically experienced customer contact persons from the day-to-day business, this takes on a completely different dimension in the agile environment. This is because the customer is much more and more permanently on board here, as his feedback should constantly flow into the product. This is a major organizational challenge that can consume considerable resources in the project and in the line due to the constant iteration of development, testing, coordination, and replanning.
This leads me to conclude that the more agile projects are managed, the more difficult they are to manage. Process models such as SAFe and LeSS attempt to address the typical challenges of large projects through well-structured portfolio management, but the core characteristics of the agile approach remain, and so do its core applications.
For projects of this size, it seems to make more sense to combine the advantages of both worlds. For this type of project, it makes sense to gather requirements, write concepts and plan milestones in the classic way. However, the assumptions made about scope, time and cost should not be seen as a sacred duty to which everything – including the product and customer satisfaction – is subordinated. The project and the customer can benefit from agile approaches by implementing, for example, prototyping, close communication with the customer, a focus on results, and the avoidance of „rigidity“ (see also: technical debt).
Project success here does not lie in dogmatically following one approach or another, but rather in combining the approaches that best fit the use case. Only in this way can we meet the increasing demands on the project without immediately throwing out the baby with the bathwater.
In this sense, stay agile,
