Embed Size (px)
Citation preview
Agile: my experiences and lessons learned Presented by: David McGuinness, FINEOS
AgileTour Dublin – 10th October 2013 © FINEOS Corporation Ltd.
• Myself
• My company, FINEOS
• My Agile journey
• Three things I’ve learned along the way
• What next for us?
• Q&A
Today I would like to talk about…
• Monday to Friday • Agile enthusiast
• Weekend • Outdoor enthusiast
Who am I?
Both are challenging, and someImes painful!
(1 of 17)
www.fineos.com • “Number one provider of
so1ware solu5ons for the Global Life and Health insurance industry”
• A collaboraIve culture, on an Agile journey
• Recently moved to new head-‐office
Who is FINEOS? (2 of 17)
Who is FINEOS?
Open-‐plan (nowhere to hide) We write on walls
We do Scrums And like drawing things
(3 of 17)
• We transiIoned from a tradiIonal environment to using Scrum • Some mistakes made • DysfuncIons highlighted – process and otherwise • Challenges met, answers found • In short, it was hard!
SIll learning. SIll evolving
My Agile journey – in the beginning (4 of 17)
My Agile journey – en route
Mistakes, we made a few… • Leaders in charge, not facilitaIng • No clear product owner • Running out of Ime and moving
sprint end dates • Need for “release” sprints
Learn from your mistakes…
(5 of 17)
• IteraIve & regular releases • Constant feedback & validaIon • Improved collaboraIon & communicaIon • ConInuous improvement of product & process Therefore: • Happy team (?) • Happy customers (?)
My Agile journey - today (6 of 17)
Three things I’ve learned: No. 1 – It’s about people, not process • Agile is not just a process you follow, or a checklist • It asks hard quesIons and can be frustraIng • Especially when transiIoning from tradiIonal environments… It requires a change of mindset, and a leap of faith
(7 of 17)
• Agile helps to build trust within and between teams
• More face-‐to-‐face Ime encourages construcIve conflict & posiIve challenge
• Team are commi^ed to goals and have a vision
• Self-‐organising teams hold each other to account
• Result-‐focused and customer-‐focused
• In short, Agile helps your teams to perform
Three things I’ve learned: No. 1 – It’s about people, not process
(8 of 17)
Three things I’ve learned: No. 2 – User Stories are important
• Our User Stories were o`en: § Too technical § Too detailed § Too big § SoluIons
• i.e. they were not really user stories! Therefore, we’re trying to evolve them…
(9 of 17)
Three things I’ve learned: No. 2 – User Stories are important
“Slice each user story so as to produce soAware which: works; delivers value; can potenDally generate user feedback” How? • Invest in INVEST • Describe what; why; who? • Describe business value, not technical • Add acceptance criteria – whiteboard
them • Focus on techniques to breakdown
into chunks • Collaborate, collaborate, collaborate
(10 of 17)
Remember:
New to user stories (arDcle)
Three things I’ve learned: No. 2 – User Stories are important
“The text we write is nowhere near as important as the conversation we have”
(11 of 17)
Why not use Scrum to get be^er at Scrum? • Workshop to create a Product
Vision • Write user stories on cards
and vote on them • Group by theme • Create your backlog • Collaborate on all the above • Start sprinIng!
Three things I’ve learned: No. 3 – Use Scrum to get better
(12 of 17)
• “Project Darwin” • We are evolving:
• User Stories • Backlog Management • Metrics • AutomaIon • TesIng • Code Management
Three things I’ve learned: No. 3 – Use Scrum to get better
(13 of 17)
• Agile is about people, and not just process – being Agile makes teams and individuals more successful
• We think good User Stories are at the heart of Agile • You can use Scrum to get be^er at Scrum
Three things I’ve learned: Summary
(14 of 17)
What Next – Challenges Opportunities
• Keep evolving and improving: “Project Darwin”
• Scaling up – bigger teams, bigger projects • Other teams: “Spreading the
virus” • If you’re having fun, then maybe you’re gegng close!
(15 of 17)
Final Words
“It is not the strongest of the species that survives nor the most intelligent… it is the one most adaptable to change”
(16 of 17)
Q&A (17 of 17)
Appendix A – Recommended Reading
• “Succeeding with Agile” by Mike Cohn • “The Art of Agile Development” by James Shore • “The Five Dysfunctions of a Team” by Patrick Lencioni • “Drive: the surprising truth about what motivates us” by Daniel Pink • http://scrumguides.org • http://www.infoq.com/ • http://www.scrumalliance.org/ • http://agile.dzone.com/articles/top-10-lessons-learned-10 • http://www.scrumalliance.org/articles/169-new-to-user-stories
Appendix B – My Agile Cheatsheet Foster self-‐organisaIon -‐ SM/PO not leading
Introduce ground rules for daily meeIngs Don’t skip any Scrum meeIngs Don’t extend Sprint end dates
Synchronise all sprints for mulIple projects – same start and end day Stabilise team size(s) to measure velocity and inform planning
Allow for two hours sprint planning per week of sprint
Use story point esImaIon, planning poker => measure velocity Supplement Scrum with good engineering pracIces, e.g. XP
Product Vision / Elevator Statement + Sprint Goals – something to aim for
DefiniIon of Done – “done done” User Stories and DefiniIon of Ready
Use the language – backlogs, sprints, user stories. Make these visible Agree documentaIon with your customers – clarify audience and purpose
Keep evolving – retros of product and process Metrics – numbers are meaningless, trend is everything!
Fail fast – try things, and don’t be afraid to fail – foster this culture
Don’t just talk the talk, pracIce what you preach – immerse yourself Invest in training and coaching if you can
