EN 
DE 
Execute complex software projects more effectively using agile methods.
Come on everyone, let's go agile today, and starting tomorrow our software projects will be purring like kittens! There are many indications that complex software projects can be carried out more effectively using agile methods. This is mainly because project teams confront their reality more quickly and decisively.
The transition to agile methodologies is initially an admission by project management and all other stakeholders involved in projects: "To be honest, we don't really have a complete overview!" This lack of overview is evident when we look from the project's present to its future. However, it's equally true when we look from the project's present to its past. While looking backward seems somewhat more realistic, it's distorted by all sorts of mechanisms of denial and idealization.
If that's the case, perhaps we should pay a little more attention to the present. I don't mean that we shouldn't plan and organize projects, but rather that we should carry out realistic planning. What does realistic mean here? Realistic means agile.
In broad terms, "agile" means the following: Our approach is based on the four values and twelve principles of the Agile Manifesto. Their implementation in the Scrum process framework is roughly outlined as follows:
We set a project goal, define the essential quality characteristics, features, and risks, decide what needs to be done, and consider which factors we will use to verify goal achievement. In short, we give the project a rough framework, a general direction, and a clear objective. Then we decide what we can accomplish within a manageable timeframe to deliver a functional and tested interim result that we can present to the client.
Each project team member now tackles approximately one task per day for a period of 2-4 weeks (sprint). The team monitors project progress daily in short meetings and meets every 2-4 weeks to determine which insights will be incorporated into further project development (retrospective) and what the next sprint (planning) will look like. After approximately 1-4 sprints, the result (release) is presented to the customer (results review). This is the basic process in an agile project.
The ingenious principle behind this is that the project workflow is systematically interwoven with a communication process that fosters learning from experience. This ensures that project execution is monitored closely and promptly, allowing lessons to be drawn for future projects. This achieves precisely what is necessary when we realistically cannot predict the project's progress: we replace unrealistic long-term detailed planning with more short-term, detailed planning based on observations of the project's actual progress. We shift our focus from pointless attempts to predict the future to helpful observation of the project's realities. The great thing is that every stakeholder benefits from this learning process, especially the client, because they get exactly what they need.
The project team benefits from the fact that this approach aligns with people's natural predispositions and needs:
- We learn fastest when the connection between cause (error) and effect (malfunction) is experienced directly.
- We learn most effectively when we regularly practice processes and receive immediate feedback. Agile methods ensure regular feedback cycles.
- We are more willing to embrace openness and consensus when the sacrifices involved are minimal. An unsatisfactory release or a botched sprint simply doesn't hurt as much as a failed project.
- Regular communication fosters trust and reduces the risk of misunderstandings.
- Regularly reviewing results from different perspectives (project management, team members, customer) counteracts tunnel vision and rose-tinted glasses effects.
- People love to experience success and receive immediate, concrete recognition of their efforts and achievements.
Building trust instead of playing hide-and-seek and brute force.
One of the most important advantages is the reduction of unnecessary stressors: the greater the perceived uncertainty, the more typical stress reactions occur. In projects, this manifests itself in the client's arrogant, authoritarian, or even aggressive behavior. The contractor counters with skillful distraction and evasive maneuvers. Opportunities for this arise particularly at the interfaces with other suppliers or the client.
Wouldn't it be wonderful if we could do away with this game of hide-and-seek and posturing? The client no longer has to pretend they know exactly what they want. The project team doesn't have to pretend they understand what the client actually wants. The project team is protected from the often illusory expectation of having to compensate at the end of the project for everything that was neglected during the project. Isn't it more comfortable to occasionally reveal a little bit of yourself instead of ending up completely exposed and red-faced?
And if trust is present, the project partner will gladly turn a blind eye after this act of self-disclosure. After all, everyone has learned something and can therefore be more successful in the future.
The only catch with agility is that it requires us to earn trust. Firstly, it's about trusting that projects will work (better) this way, and secondly, it's about trusting the people involved. The best approach is to use the agile methodology: 1. act, 2. observe, 3. learn, 4. turn a blind eye if it doesn't work right away, 5. keep practicing.
There is a good alternative to clairvoyance: Agile methods like Scrum
(Image: foto art Elisabeth Wiesner)
I look forward to your feedback – simply send me an email to info@die-menschliche-Seite.de.
Further information
Training & coaching
MicroConsult Training & Coaching on project management
MicroConsult training and coaching - overview
Food for thought:
Column by Peter Siwon about the human side of project work
Peter Siwon: Systemic project management
