going agile

28
GOING AGILE @ Westwing Oliver Mann – June 2012

Upload: oliver-mann

Post on 15-Jan-2015

327 views

Category:

Technology


1 download

DESCRIPTION

Basics an

TRANSCRIPT

Page 1: Going  Agile

GOING AGILE@ Westwing

Oliver Mann – June 2012

Page 2: Going  Agile

The Holistic View

Understanding of

BasicsProjects

&Agile

Fundamentals

Page 3: Going  Agile

A typical Project

What Customer thought of

What was specified What was delivered

What was documented Costs of Project

What customer needed

Page 4: Going  Agile

Why ?

Page 5: Going  Agile

System´s are not simplealthough there are no big numbers

Water = H2O behaviour predictable?

Page 6: Going  Agile

Systems Theory

Structure of systems is Simple or ComplicatedThe predictability of behaviour of systems depends

Page 7: Going  Agile

People are not simpletheir behaviour & interaction

People interacting in an organization

Page 8: Going  Agile

Why Projects fail

Poor Communication

Qualification Team-Members

Unclear Requirements and Goals

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

Page 9: Going  Agile

Projects fail ´cause of

PeopleKnowledge& Discipline

Page 10: Going  Agile

Rise of Project Knowledge

Page 11: Going  Agile

Traditional Methodology – Focus on ScopeMain decisions at Project-StartContract and Scope at Project StartNo learnings during implementationFocus on Scope. Every change will risk scope and timeline

Page 12: Going  Agile

Agile Methodology – Focus on Goals Initial Scope can change

Decisions made when necessary & clearCommittment & Reviews for every IterationChanges possible, Optimizing everything

Page 13: Going  Agile

Cost of change

Source: http://agilemodeling.com/essays/costOfChange.htm

Traditional Methodology Agile Methodology

Page 14: Going  Agile

You see

Agilityhas advantages

Page 15: Going  Agile

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.

CollaborationThe 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 teamsAgility capitalizes on self-directed teams and recognizes that small teams can self-direct most effectively.

Lean principlesPrinciples of Lean Manufacturing are embodied in Agility, especially concepts like "Just Enough" and "Just in Time."

Progressive requirements elaborationWe 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 deliveryThe 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 adaptationAgile 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.

What is Agility ?

Page 16: Going  Agile

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 planningAgile 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 requirementsThe 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 controlAgile 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 likeCustomer 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.

What Agility is not !an excuse for undisciplined practices

Page 17: Going  Agile

The right productCustomer/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.

QualityAgility 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 budgetTime-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 warningAn Agile project is a series of short mini-projects, problems become apparent very early

Adapting to changeChange 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.

The Value of Agility

Page 18: Going  Agile
Page 19: Going  Agile

A reduced Agile Framework

Page 20: Going  Agile

Responding to Change

… and the problems with it

Page 21: Going  Agile

Be aware of Communication & Interpretation

View 1 View 2

„Describe what you see!“

Holistic View(Management)

Page 22: Going  Agile

Every Change needs time

wether it´s Tools, Process, Team-Members

Page 23: Going  Agile

Team Building Process

Page 24: Going  Agile

No inspect & adapt = No Change

Page 25: Going  Agile

Square of Constraints

Source: http://www.managment30.com

Page 26: Going  Agile

Escher Cube of Constraints

Page 27: Going  Agile

Confused ?

Page 28: Going  Agile

Solutionsnext week !

Questions every time