The document discusses how adopting an agile methodology can help projects address challenges like unclear requirements and communication issues, noting that agile approaches focus on iterative development, collaboration between self-directed teams and customers, and adapting to change based on regular feedback rather than extensive up-front planning. It provides an overview of agile principles and values like incremental delivery and learning through doing, while cautioning that agility does not mean abandoning practices like documentation, planning, and requirements altogether.

1. GOING AGILE
@ Westwing
Oliver Mann – June 2012

2. The Holistic View
Understanding of
Basics
Projects
&
Agile Fundamentals

3. A typical Project
What Customer thought of What was specified What was delivered
What was documented Costs of Project
What customer
needed

4. Why ?

5. System´s are not simple
although there are no big numbers
Water = H2O behaviour predictable?

6. Systems Theory
Structure of systems is Simple or Complicated
The predictability of behaviour of systems depends

7. People are not simple
their behaviour & interaction
People interacting in an organization

8. Why Projects fail
Poor Communication
Unclear Requirements and Goals
Qualification Team-Members
Politics, unclear Stakeholder/Leads
Not enough Ressources on Start
Disturbing Management,
Missing Commitment
Wrong Methodology
More details: http://www.gpm-ipma.de/fileadmin/user_upload/Know-How/Ergebnisse_Erfolg_und_Scheitern-Studie_2008.pdf

9. Projects fail ´cause of
People
Knowledge
& Discipline

10. Rise of Project Knowledge

11. Traditional Methodology – Focus on Scope
Main decisions at Project-Start
Contract and Scope at Project Start
No learnings during implementation
Focus on Scope. Every change will risk scope and timeline

12. Agile Methodology – Focus on Goals
Initial Scope can change
Decisions made when necessary & clear
Committment & Reviews for every Iteration
Changes possible, Optimizing everything

13. Cost of change
Traditional Methodology Agile Methodology
Source: http://agilemodeling.com/essays/costOfChange.htm

14. You see
Agility
has advantages

15. What is Agility ?
Learning and adaptation
The Agile approach accepts that there are many things we cannot anticipate, so it is structured to allow us to first learn about those unknowns and then adapt to
what we learn.
Collaboration
The Agile approach places high value on all stakeholders collaborating continuously, including the programmers and their customers.
Customer focus
The customer is the central focus of an Agile project and is actively involved throughout.
Small self-directed teams
Agility capitalizes on self-directed teams and recognizes that small teams can self-direct most effectively.
Lean principles
Principles of Lean Manufacturing are embodied in Agility, especially concepts like "Just Enough" and "Just in Time."
Progressive requirements elaboration
We expect to learn about the system requirements as the project progresses, so trying to nail them down in a full-blown specification at the beginning of the
project doesn't make sense. Agile projects establish a roadmap and elaborate the details as they are needed.
Incremental delivery
The best way to ensure we are building the right system is to regularly get feedback from our customer. Agility always includes incremental delivery of the
product to the customer - at least for acceptance testing.
Iterative planning and adaptation
Agile projects place a high value on planning. They engage in planning at various levels of detail and engage in it regularly. Again, this is driven by the fact that we
cannot foresee everything that is important, so we must adapt our plans as we learn.

16. What Agility is not !
an excuse for undisciplined practices
No documentation
The documentation that an Agile project produces is significantly different from what traditional projects produce, and an Agile team will always ask why
various documents are needed. But they always document (in unique ways) their plans, requirements, designs, and whichever other artifacts provide value.
No planning
Agile projects actually engage in more planning than most traditional projects. They produce a high-level plan during project initiation, and they re-visit and
adapt that high-level plan regularly throughout the project. They produce a plan of what they will do during each iteration of development, and they meet daily
to check their progress and plan the day's work.
No requirements
The Agile team's Product Owner (customer) defines a Product Vision, and they work together to document the product's high-level requirements (called the
product backlog). Then, more detailed views of those requirements are elaborated upon and documented as they are needed throughout the project.
No schedule or budget control
Agile projects always operate within a "Time-Box." That is, they have definitive start- and end-dates and are not expected to violate those dates. And because
people's time is the largest part of a software project's budget, the time-box limits the project budget as well. The Agile mantra is, "We will deliver the greatest
possible customer value within the project constraints!"
Developers doing whatever they like
Customer has primary control over an Agile project. The customer is involved in all aspects of planning, prioritization, and status keeping throughout an Agile
project. If the project team is not producing what the customer finds to be valuable, it is up to that person to re-direct the work. The team's only role is to
estimate what can be done in limited timeframes. The team's customer determines how that effort will be directed.

17. The Value of Agility
The right product
Customer/Stakeholder are continuously involved in the project, ensuring that valuable software is being built and prioritizing the work. In addition, the customer
accepts or provides critical feedback on each increment of the product that is produced. With this level of involvement by the customer, there is no way that the
wrong product can be built.
Quality
Agility always includes a strong focus on the quality of what is built. This includes not only the customer's acceptance testing, but also many technical quality
practices. Properly functioning Agile teams produce high-quality software.
Schedule and budget
Time-boxing of an Agile project means that its schedule and budget are rarely "over-run" If things don't work out as planned, the low-priority features can be
skipped or cut short.
Early warning
An Agile project is a series of short mini-projects, problems become apparent very early
Adapting to change
Change is a fact of business. Agile projects can adapt to changes in the business environment, within the organization, or with the customer much more
effectively than any other methodology.

19. A reduced Agile Framework

20. Responding
to Change
… and the problems with it

21. Be aware of Communication & Interpretation
„Describe what you see!“
View 1 View 2
Holistic View
(Management)

22. Every Change needs time
wether it´s Tools, Process, Team-Members

23. Team Building Process

24. No inspect & adapt = No Change

25. Square of Constraints
Source: http://www.managment30.com

26. Escher Cube of Constraints

27. Confused ?

28. Solutions
next week !
Questions every time