Failing With Style

How to Make Better Mistakes (using Agile Methods)

Andrew Berdan - @twitch - andy@berdan.ca

Monday, 8 April, 13

The Beginning
I was talking to the organizer of ExplodeCode, and he mentioned wanting someone to do a talk on Agile. You know Agile. Wanna do it? -- Mark Mikulec, my Technical Director I guess I need a plan.

Monday, 8 April, 13

How much planning?

Take a step back. Perfection leads to Procrastination leads to Paralysis Throw perfection out the window (in the planning stage) Do just enough planning to get moving. However, you also want to guide future planning.

Monday, 8 April, 13

How do we do this?
Begin with the big picture items: Epic
(Origin: a collection of stories that is itself a story? An Epic)

Break down Epics into stories until you have enough work to get started. Start.

Monday, 8 April, 13

Preparation
Up-front Product Vision Team Understands Requirements High Level Architecture & Design Working Development Environment SCM Repository Continuous Integration Server Other Best Practices, Etc.

Monday, 8 April, 13

Production
What if I screw up? What if I fail? Dont. Redene failure as an opportunity to improve Reduce the cost of failure with iteration

Monday, 8 April, 13

failure [feyl-yer] noun

1. an act or instance of failingor proving unsuccessful; lack of success 2. nonperformance of something due, required, or expected 3. a subnormal quantity or quality; an insufciency

Monday, 8 April, 13

Redening Failure
Analogy: progress is like running a marathon you don't reach your goal with each individual step. Is each step a failure? Clarify: failure is "not making progress, or a reversal in progress" Addendum: a mistake is an individual event of failure

Monday, 8 April, 13

What is a Mistake?
an error halt in progress? a setback? negative progress?

Monday, 8 April, 13

What is a BETTER mistake?

Progress in unintended directions? Learning experience Valuable in SOME way Recorded, shared, explored NOT repeated Human. It's ok to make mistakes.
Monday, 8 April, 13

Things to Remember
Accepting responsibility makes learning possible. Dont equate making mistakes with being a mistake. You cant change past mistakes, but you can choose how to respond to them. Growth starts when you can see room for improvement. Work to understand why it happened and what the factors were.
Monday, 8 April, 13

Things to Remember
What information could have avoided the mistake? What sequence of small mistakes contributed to the bigger mistake? Are there alternatives you should have considered but did not? What kinds of changes are required to avoid making this mistake again? What kinds of change are difcult for you?

Monday, 8 April, 13

Things to Remember
How do you think your behaviour should/would change in you were in a similar situation again? Work to understand the mistake until you can make fun of it (or at least not want to kill others that make fun). Dont over-compensate: the next situation wont be the same as the last.

Monday, 8 April, 13

What are Agile Methods?

Agile methods are intended to expose issues, and foster quick reactive responses. Agile is the umbrella term. Specic frameworks include:
eXtreme Programming Scrum Kanban, Lean, Feature-Driven Development, and more...

Monday, 8 April, 13

The Agile Manifesto

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan while there is value in the items on the right, we value the items on the left more.
Monday, 8 April, 13

12 Underlying Principles
1. 2. Customer satisfaction by rapid delivery of useful software Welcome changing requirements, even late in development Working software is delivered frequently (weeks/days rather than months) 4. 5. 6. Working software is the principal measure of progress Sustainable development, able to maintain a constant pace Close, daily co-operation between business people and developers

3.

Monday, 8 April, 13

12 Underlying Principles
7. Face-to-face conversation is the best form of communication (co-location) Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design 10. 11. 12. Simplicity Self-organizing teams Regular adaptation to changing circumstances

8.

9.

Monday, 8 April, 13

Remember: our plan?

Always gives forward progress Minimizes mistake events, or at least identies them EARLY Can be estimated, so we can set reasonable expectations, to make the client happy

Monday, 8 April, 13

Agile Suggestions
Timeboxed units of work (Sprint)
all time must be estimated in IDEAL time to t in the time box

Post-mortem after each time boxed period of work ("Sprint Analysis") Re-plan before each time box ("Sprint Planning"). Always write a goal for EACH time box.

Monday, 8 April, 13

Common Agile Mistakes

Allowing stakeholders ("Product Owners") to make team decisions Allowing team to make stakeholder (product) decisions Failing to reect after a period of work Not having EVERYONE on board: team members, product owner, clients, EVERYONE

Monday, 8 April, 13

Common Agile Mistakes

Low transparency to client Interrupting work after team commitment to delivery Repeating work (usually after previous interruption) Not communicating

Monday, 8 April, 13

Further Reading
http://agilemanifesto.org/ http://www.scrumalliance.org/ http://groups.yahoo.com/group/scrumdevelopment/ Google

Monday, 8 April, 13

Further Reading
Agile Software Development with Scrum
Ken Schwaber and Mike Beedle, Prentice Hall, 2001

Agile Retrospectives: Making Good Teams Great

Esther Derby & Diana Larsen, Pragmatic Bookshelf, 2006

Extreme Programming Explained,

Kent Beck, Addison Wesley, 1999

Test Driven Development By Example

Kent Beck, Addison Wesley, 2002

Agile Estimating and Planning

Mike Cohn, Prentice Hall, 2005

Fit for Developing Software: Framework for Integrated Tests

Rick Mugridge and Ward Cunningham, Prentice Hall

Agile Project Management

Jim Highsmith, Addison Wesley, 2004

Planning Extreme Programming

Kent Beck and Martin Fowler, Addison Wesley, 2000

Refactoring: Improving the Design of Existing Code

Kent Beck, Addison Wesley, 1999

Andrew Berdan - @twitch - andy@berdan.ca

Monday, 8 April, 13