P. 1
Failing With Style

Failing With Style

|Views: 6|Likes:
Published by Andrew Berdan
How to Make Better Mistakes (using Agile Methods)
How to Make Better Mistakes (using Agile Methods)

More info:

Categories:Types, Speeches
Published by: Andrew Berdan on Apr 23, 2013
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





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

However.How much planning? Take a step back. 13 . Monday. Perfection leads to Procrastination leads to Paralysis Throw perfection out the window (in the planning stage) Do just enough planning to get moving. you also want to guide future planning. 8 April.

13 . Monday.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. 8 April.

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

8 April. Redefine “failure” as an opportunity to improve Reduce the cost of failure with iteration Monday.Production What if I screw up? What if I fail? Don’t. 13 .

8 April. an act or instance of failing or proving unsuccessful. an insufficiency Monday.fail·ure [feyl-yer] noun 1. lack of success 2. a subnormal quantity or quality. nonperformance of something due. required. 13 . or expected 3.

8 April.Redefining 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. 13 . or a reversal in progress" Addendum: a mistake is an individual event of failure Monday.

13 . 8 April.What is a Mistake? an error halt in progress? a setback? negative progress? Monday.

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

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

8 April.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 difficult for you? Monday. 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). 8 April. 13 . Monday. Don’t over-compensate: the next situation won’t be the same as the last.

Agile is the umbrella term... and more. Specific frameworks include: eXtreme Programming Scrum Kanban. Lean. and foster quick reactive responses. 13 .What are Agile Methods? Agile methods are intended to expose issues. Feature-Driven Development. Monday. 8 April.

8 April. we value the items on the left more.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. 13 . Monday.

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

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

so we can set reasonable expectations. to make the client happy Monday.Remember: our plan? Always gives forward progress Minimizes mistake events. 8 April. or at least identifies them EARLY Can be estimated. 13 .

13 . Monday. Always write a goal for EACH time box. 8 April.Agile Suggestions Timeboxed units of work (“Sprint”) all time must be estimated in IDEAL time to fit in the time box Post-mortem after each time boxed period of work ("Sprint Analysis") Re-plan before each time box ("Sprint Planning").

13 . product owner.Common Agile Mistakes Allowing stakeholders ("Product Owners") to make team decisions Allowing team to make stakeholder (product) decisions Failing to reflect after a period of work Not having EVERYONE on board: team members. 8 April. EVERYONE Monday. clients.

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.

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

Kent Beck.ca Monday. Addison Wesley. Prentice Hall. Addison Wesley. 2002 Agile Estimating and Planning Mike Cohn.andy@berdan.@twitch . 2000 Refactoring: Improving the Design of Existing Code Kent Beck. 2005 Fit for Developing Software: Framework for Integrated Tests Rick Mugridge and Ward Cunningham. 2004 Planning Extreme Programming Kent Beck and Martin Fowler. 2001 Agile Retrospectives: Making Good Teams Great Esther Derby & Diana Larsen. 13 . Prentice Hall. 2006 Extreme Programming Explained. 1999 Andrew Berdan . 1999 Test Driven Development By Example Kent Beck. Pragmatic Bookshelf. Prentice Hall Agile Project Management Jim Highsmith. 8 April. Addison Wesley.Further Reading Agile Software Development with Scrum Ken Schwaber and Mike Beedle. Addison Wesley. Addison Wesley.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->