Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agile vs. Chaotic projects — similarities and differentiations by Aigars Staks

Agile vs. Chaotic projects — similarities and differentiations by Aigars Staks

Field experiences and many observations for the Agile adaptations in various programming set-ups. Some of them has been catastrophic, others very successful.

What makes not standard waterfall models to fail or ether to be successful? Is it determined by the size, by customer or by developer teams? How agile can be used to avoid chaos and cost overrun at any parties side?

Agile Latvia

April 26, 2014

More Decks by Agile Latvia

Other Decks in Business


  1. Chaotic vs. Agile projects
    Agile Day - 2014
    by Aigars Staks, PMP, CRISK

    View Slide

    We do not do planning or control,
    so Agile is THE method for us!
    We ARE agile already!

    Waterfall = structured development

    Agile methods = creative (chaotic) development

    View Slide

    We find pure Waterfall non-implementable, so we cut the corners in the
    spirit of Manifesto. This is now our internal Agile methodology.
    Agile is good method, but much more expensive than Waterfall. We
    can go with that, if you will pay 2x.
    Aigars, I do not feel you've managed this project. We felt you at the
    beginning, but now project survives only because we've had so good
    developers, not you.
    Aigars, all you did was wrong, but this time it worked somehow.

    View Slide

  4. Eras of SW development
    Pioneering (1945 – 1965) “...like independent sailing ships”
    - machine time leased, no predictions possible
    Crisis formation (1965 – 1985 - …) “business support”
    - cost and budget overruns(OS/360), property damage(security issues),
    incidents (lethal doses, Therac-25 incident)
    Waterfall (1985 – 2000 - …) “complex static systems”
    - tools (structured programming), methodologies (CMM), standards
    (LV65-75:1996), programming discipline (phasing, PM)
    Agile (2000 - …) “complex adaptive systems”
    - trust, believe only what you see and understand

    View Slide

  5. Agile vs. Chaos
    Do you know exactly what is system when you start IT project? (NO)
    Does customer know exactly how it will be? (NO)
    Can scope/schedule be fully fixed? (NO)
    Is price fixed? (YES)
    Someone must take the risk:
    Waterfall ----> Customer,
    Agile -----> Developer,

    View Slide

  6. Agile vs. Chaos
    Do you know exactly what is system when you start IT project? (NO)
    Does customer know exactly how it will be? (NO)
    Can scope/schedule be fully fixed? (NO)
    Is price fixed? (YES)
    Someone must take the risk:
    Waterfall ----> Customer,
    Agile -----> Developer,
    Chaos -----> None
    ...this why many IT companies discontinue Agile practice after 1-2 tries

    View Slide

  7. So comes “Scrum, but...”

    View Slide

  8. So many try Agile and then fall back

    We are Agile, but ...having a Daily Scrum every day is
    too much overhead. (so we only have one per week)

    We are Agile, but … Retrospectives are a waste of
    time. (so we don't do them)

    We are Agile, but ...we can't build a piece of
    functionality in a month. (so our Sprints are 6 month

    We are Agile, but .. sometimes our managers give us
    special tasks on other projects. (so we don't always
    have time to get to “done”)

    View Slide

  9. Twelve Principles of Agile Software
    Our highest priority is to satisfy the customer
    through early and continuous delivery
    of valuable software.
    Welcome changing requirements, even late in
    development. Agile processes harness change for
    the customer's competitive advantage.
    Deliver working software frequently, from a
    couple of weeks to a couple of months, with a
    preference to the shorter timescale.
    Business people and developers must work
    together daily throughout the project.
    Build projects around motivated individuals.
    Give them the environment and support they need,
    and trust them to get the job done. (to be done by HR)
    The most efficient and effective method of
    conveying information to and within a development
    team is face-to-face conversation.
    Working software is the primary measure of progress. (hmm..just
    does not make sence here)
    Agile processes promote sustainable development.
    The sponsors, developers, and users should be able
    to maintain a constant pace indefinitely. (no changes needed)
    Continuous attention to technical excellence
    and good design enhances agility. (bla bla.. ISO stuff)
    Simplicity--the art of maximizing the amount
    of work not done--is essential. (not our kind of project)
    The best architectures, requirements, and designs
    emerge from self-organizing teams. (risky)
    At regular intervals, the team reflects on how
    to become more effective, then tunes and adjusts
    its behavior accordingly. (bla bla.. ISO stuff)

    View Slide

  10. “We are uncovering better ways of developing
    software by doing it and helping others do it.
    Through this work we have come to value:
    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    Responding to change over following a plan
    That is, while there is value in the items on
    the right, we value the items on the left more.”
    Manifesto for Agile Software Development (2001)

    View Slide

  11. How to validate chaos vs agile?

    View Slide

  12. Summary

    Wearing the “Agile suit” alone does do the job for you

    Agile is excellent armor to address such a concept as complex
    adaptive systems, like Software Development.

    This armor is can be significantly more efficient than historical
    tooling used by many

    You cannot adapt 1 piece of the process not risking the whole

    Doing “Agile” without comprehending it, probably leads to
    disaster and chaos
    If you start doing agile – FOLLOW THE RULES, no excuses

    View Slide

  13. Thanks!

    View Slide