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?

Transcript

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

   View Slide

2. Quotes
   We do not do planning or control,
   so Agile is THE method for us!
   We ARE agile already!
   Myth:
   ●
   Waterfall = structured development
   ●
   Agile methods = creative (chaotic) development
   

   View Slide

3. Quotes
   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
   long)
   ●
   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)
    10
    

    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!
    www.agile.lv
    

    View Slide