ACS Presentation : How to teach your team Agile in 3 months
Download as PPTX, PDF1 like7,352 views
The document outlines a three-month plan to teach a team the Scrum methodology using a psychology-based approach, highlighting the importance of understanding how people learn new skills. It details the progression from initial chaos and incompetence through structured workshops to a more collaborative, efficient teamwork dynamic, culminating in improved processes and outcomes. Key strategies included adapting sprints, refining estimations, and fostering team autonomy and trust to successfully implement Scrum practices.
ACS Presentation : How to teach your team Agile in 3 months
- 1. How to teach your team Scrum in 3 months Mia Horrigan Director Strategy and Advisory Services Zen Ex Machina @miahorri zenexmachina.wordpress.com
- 2. How do we learn a new skill? • How the human mind works on collecting information and then applying it ? and then applying it ? • Having an understanding of how you learn is incredibly useful. • Once you know how it all works, you can apply the same principles to new skills
- 4. Needs to adapt to new way of thinking • Gradual process that requires cognitive processing to work with our abilities to perform • Brain has to process info • Relative speed to other cars • Road Signs and signals • What to focus on • Apply that thinking to your behaviour • It’s the same when learning any new skills
- 5. Saw an opportunity • Manager saw an opportunity to give Team a new skill and a unified process • The transparency and collaboration he saw emerging out of the intranet project was very appealing to him • Tend to think about Agile as a software development approach • Decided it might be adaptable to Business as usual (BAU) to improve business processes and gain efficiencies
- 6. Experiencing Pain • Business unhappy at lack of progress (backlog of work and new work coming in) • Team working hard, long hours but not delivering (starting a bit of everything) • Waterfall not allowing them to adapt to changes • No collective process to process new requests • Team not sure which work was important • Geographically dispersed • Asked ZXM to help them implement Scrum
- 7. What is the Biggest Reason Why People Don’t Get Good at a New Skill?
- 8. Lack of results • Demotivates them, they quit • Especially if they don’t have support through the process • Needed the team to trust in the process of learning and stay motivated even when initially it may seem “chaotic”
- 9. What is the best way to learn a new skill? • We can read a book • We can observe others • We use a coach to facilitate learning and behavioural change
- 10. Aim was to teach team Scrum in 3 months By using psychology based approach to implementing Scrum we were able to guide them through the learning process Conscious Incompetence Unconscious Incompetence You don’t know that you don’t know something Month 0 You know that you don’t know something and it bothers you Conscious Competence You know that you do know something but it takes effort Unconscious Competence You know how to do something and it is second nature to you Month 3
- 12. Learning to Drive a Car Unconscious Competence http://canime.busybuild.co.uk/Mario-Kart.php
- 13. Started with a Workshop - Scrum 101 • Taught them the rules
- 14. Scenario based approach to learning • Established these rules of scrum, its roles, its controls, its processes by: – Showing how Scrum works – Giving team a practical lesson (lego) – Ensured everyone was speaking the same language, terminology – Set expectations of using Scrum
- 15. Inspect and Adapt process zenexmachina.wordpress.com
- 16. Creating the Product Backlog • • • • 3 streams BUT one product backlog Thrown straight into developing user stories Estimating stories Ranking of stories
- 17. Visualised the products in flow • Developed Kanban board • Kinaesthetic learning
- 19. Learning to Drive a Car Conscious Incompetence http://lolsnaps.com/news/51946/0/
- 20. Always chasing our tails…. • PMs assigning products to the Team • Felt rushed and busy • Still not completely moved away from their old ways of working • Chaos • Uncertainty • They were now conscious of their incompetence
- 21. There is a Learning Curve
- 22. Always chasing our tails…. • Still not completely moved away from their old ways of working • Still working on project issues from before the sprint to 'please everyone and keep them happy' – "But we're part of a bigger team" – "We don't have the luxury of working on just these projects" – "We have to keep everything running"
- 23. What we did in reaction to this as their Coach • Changed 2 week sprints to 4 week sprints – 2 weeks too hectic – 4 weeks 'felt right', but would be tested and examined in retrospectives • Pressed the PMs to act as Product Owners to clearly define products and dedicate time to the backlog
- 24. Concentrated on refining our estimations • Took on too many stories • Pressed the Team to move everything not yet complete into the product backlog • Concentrated on better estimations (relative measures, Fibonacci scale
- 25. Moved the Kanban board to Jira • Solved non-collocation issues • Shared desktop to help drive the standups, planning and review sessions Lost the high visual representation
- 26. Emerging issues • Stories not being Done because they were contingent on actions from outside the team • Team not coming to ceremonies prepared • PO still not having sufficient DoD and writing them in the planning meeting • PO chairing and controlling the meetings – almost like status reports to the manager – sprint review had replaced their traditional team meeting – this meant the old behaviours just moved to the ceremony • This was an issue for strong resolution for us as coach
- 28. Learning to Drive a Car Conscious Competence http://www.proudinteractive.com/defensive-driving-courses-make-safe-drivers-on-the-road/ http://mylicence.sa.gov.au/road-rules/the-drivers-handbook/drivers-licensing
- 29. Starting to understand what needed to be done to get better • Projects that had been sitting around for ages were actually getting done! • Streams starting to talk about value in discussions with business • Passing on new requests to the product owner for ordering of product value – – they LIKED this :) first sense of empowerment and self-management
- 30. Mood of the team • Improved • Starting to understand the process and getting good momentum • Keen to keep going with the process as it was working • Recognised need to break stories down further
- 31. Coached them through breaking down stories • Stories too complex and not being completed within the Sprint • Looked at ways to break down the stories: – – – – – Workflow Business rules Non functional requirements UI complexity Core first then add value
- 32. Story hierarchy • The product backlog was built up using a hierarchy of themes, epics, stories and tasks • Traceability from the lowest to the highest level helped team members understand where their work fits into the bigger picture
- 33. Defining the Product Backlog Themes • Strategies that define overall direction for Information Management • Defined in the Information Management Strategy 2012-14 Business Intelligence Stories Community Broadcasting Section want new reports to be developed, because they value meeting their KPIs • A story requires a tangible outcome as specified in the Definition of Done Epics • Work requiring a number of pieces of effort • Must have an outcome valued by business (not just internally by IMS) • Written in the user-centred design format X wants Y because they value Z Consult with business to determine complexity of reports • Based on DoD, the story should be capable of completion in a single sprint • May not have immediate business value if part of a larger epic • Anything that needs to be done by the team in order to complete the story Tasks • Self-managed by team Send final cost estimate to business
- 34. Organised Product backlog Do in Future sprints 60% Unscheduled stories Proposed priority stories Do Next sprint 20% Do Now 20% Known priority stories This sprint Anyone can add stories Team can move stories to Proposed priorities Product owner can move stories to Known priorities Team add stories they believe should be actioned next If accepted, product owner moves to Known Priorities Medium grain user stories (weeks of work) Product owner adds stories and writes Definition of Done Team review stories & estimate effort as part of grooming Fine grain user stories (3-4 days of work) During sprint planning, Known Priorities are accepted by team based on capacity for delivery Team work to achieve Definition of Done for each story
- 35. What we did as their Coach to highlight the CC • Kept stories and DOD to things the Team could commit to deliver in a single Sprint • Team gained an understanding of capacity of the team and individuals - helped with sprint planning and commitment • SM not PO Moved chairing ceremonies • Tracked BAU time vs project time (30%)
- 36. Succession planning • We put in behaviours so that ceremonies could continue even if people weren't present • Started putting in succession planning - people had to arrange for another team member to act on their behalf for demo/retro/sprint planning
- 37. Combined Standups • Started to combine standups when there were only a few team members available – first opportunities to hear about other stream workin-progress – first opportunity to identify areas for crosscollaboration across their old silos for work-inprogress – first heads up of product backlog pipeline and transparency of work in other silos
- 39. Learning to Drive a Car Unconscious Competence http://www.whatpoll.com/best-driver
- 40. Issues at the beginning of the month • New way of working not in sync with other processes – Utilisation – Billable vs non billable work • Left over story points (eg stories 'rolled over' to the next sprint to account for effort)
- 41. What to do when a User Story is Undone? • Put it back into the Product Backlog? • Partial credit or don’t reap the Story Points for this Sprint? • Re-estimate the remainder of the complexity of the User Story • Ensures that the Team’s velocity isn’t skewed by the inflation of effort already spent
- 42. Action and Successes • As a result of the single stand-ups in month 3 we achieved radical visibility – – Opportunities to be involved across silos Emerging of pairing across silos on work • PO was getting more input into products & DOD • Finally getting into formalised backlog grooming • Team scheduling time to break down the product backlog with the PO • Scrum well known and working for them
- 43. Team behaviour by month 3 • Knew what's coming up from conversations in standups • Knew to groom the backlog with the PO in order to establish the DOD, estimations and tasks • Asked to be involved in work across old silos • PO comfortable to move to only stating the WHAT and not nominally delegate it to team members or prescribing HOW it should be done
- 44. Outcome at end of month 3 • Better understanding of commitment to take on a product/story in a Sprint • Greater visibility of BAU capacity • Collaboration and pairing across old silos occurred to complete tasks • Not silos of 3 streams -- a single team with a single, shared vision of how to get their work done
- 45. So we gave them the keys to the car
- 46. Checked back at end of the 3 months • • • • Rotating the SM role One team Keeping to their rule of 3 Seen as achieving outcomes – – – – people noticed that they get stuff done enhanced reputation amongst their business users increased trust in the team increased transparency amongst the business of how the team work
- 47. Why a behavioural learning based approach? • Demonstrates how to retrospectively assess story complexity to improve capacity planning of teams • A framework for coaching agile teams based on observing their behaviour to identify their of learning • It is the behaviour that needs to change to ensure the agile approach is successful
- 48. Why was it sucessful/? • Helpful in getting agile teams to understand where they are at in their knowledge and skill level and what they need to learn to improve performance and achieve process improvement
- 49. Happy travelling - Fin
- 50. Contact Details Mia Horrigan @miahorri zenexmachina.wordpress.com Mia Horrigan Mia.Horrigan@zenexmachina.com http://www.slideshare.net/miahorri
Editor's Notes
- #13: Kevin has grown up seen me drive a car. He’s clocked numerous hours of go-karting and Mario Carts so he think driving is easy (unconscious incompetence) So I let him drive my car into the driveway…….
- #20: He quickly learned of his lack of knowledge and incompetence in this area, so he wanted to learn about cars and how to operate them
- #29: He did a defensive driving course, got an instructor. Learned how to operate a car, what handles do what and actively learned. He had to focus a lot on the task or else he made mistakes. He’s still clocking his 100 hrs
- #40: May years into the future when he gets his driver’s license and has been driving for a while, he will find driving is easy. He won’t need to concentrate as hard, it will be second nature
- #42: Re-estimate the remainder of the complexity of the User StoryWhy the User Story was left undoneThe new things they’ve learned about the User StoryThe new tasks and/or requirements of the User StoryThe remaining complexity, not the whole story including what was Done
- #47: Rotating the SM roleOne teamKeeping to their rule of 3Seen as achieving outcomespeople noticed that they get stuff done enhanced reputation amongst their business usersincreased trust in the teamincreased transparency amongst the business of how the team work