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
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
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.
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
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,
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
7. So comes “Scrum, but...”
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”)
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)
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
11. How to validate chaos vs agile?
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
13. Thanks! www.agile.lv