Agile work

Mr. A. is the product manager and at the same time the customer working with an agile team. He has the leading role of his product and has one goal in mind: to bring a specific product to market and maximize its value.

He and his development team work in two-week iterations. Every day, the developers hold a short meeting to inspect whether their initial iteration is going according to plan or if they need to adapt certain things.

• Unexpected events and undesired disturbances can be revealed and made transparent immediately. Using the team's swarm intelligence, decisions can be made on how to deal with these influences.
• A new version of the product is available after two weeks at the latest. This version can be rolled out immediately if required by the product owners. They get feedback from the developers and then draws their conclusions. The advantage of an early release is obvious: risk minimization.
• Thanks to the early feedback from the market, it is possible to react directly and, if the market situation requires it, to make a course correction even during product development.
• It may even appear that a certain feature is not desired in the future, which in turn could save costs. Sponsors would most likely appreciate it.
• Before the final product roll-out, the entire team and stakeholders inspect the product in a review meeting. Everyone involved is aware that these regular, joint meetings are necessary and valuable.
• At the end of an iteration, the team conducts a retrospective in which the participants reflect on the past two weeks. Learnings are discussed openly and confidently in a pleasant atmosphere: What went well during that time? What could have been better? What will the team do differently in the next weeks to become even more effective?  

Assumption: Efforts, milestones, deadlines can be specified in advance by people with no background in the field and without involving the implementing team. Nevertheless, the expectation is that software is implemented in scope, in budget, and in time, even if the effort estimates were created without the technicians and developers.

Reality: Agility makes it explicit that progress and success will be measured regularly by reviewing working versions of the product. The scope will inevitably change as the market responds. No document or virtual process, no matter how precisely specified, can map that in advance. 

Assumption: Documentation of requirements > Communication. Documentation of requirements is the essential element. The more precisely and detailed requirements are defined, the less important communication becomes. Because requirements can be developed and processed diligently, without any questions. Intermediate questions and iterations are then no longer needed.

Reality: Initial documentation of requirements is certainly important. However, the written word is no substitute for a face-to-face dialog between customer and contractor. Communication is important to save feedback and questions of understanding. If left unresolved, those might lead to misunderstandings.

Assumption: Business and IT are different departments – two different worlds that should not be mixed!

Reality: Agility is driven by continuous collaboration of all project participants. An apt example is the added value of cross-functional teams. When stakeholders, IT, business, operations, and others are pulling in the same direction, the goal can be achieved faster and more accurately! How many mistakes could have been prevented if only more emphasis had been placed on joint communication? 

Assumption: Agility? There's not even any planning involved!

Reality: The effectiveness of plans over long periods of time is actually strongly questioned in the agile environment. Due to the uncertain environment to operate in, planning is done with a rather short-term focus. It's comparable to the weather forecast. How trustworthy do you consider the weather forecast over a period of 42 days? How reliable is even a forecast for tomorrow or the day after? It is in the nature of things that complexity can only be planned to a limited extent and quick adaptation of the plan is necessary. An agile development team that works in iterations nevertheless places the highest focus on the respective iteration plans.