Mastering Agile Practices to Build High Performing Teams

Editor's Notes

• #3: https://www.youtube.com/watch?v=SMCsXl9SGgY What does the Karate Kid teach us about building high performing teams? - Establishing trust
• #4: https://www.youtube.com/watch?v=SMCsXl9SGgY “First make sacred pact. I promise - teach karate. That my part. You promise learn. I say, you do. No questions. That you’re part.” Reality about Agile. It requires: Habits – this is what the ceremonies are all about Commitment – complete and deliver what you promise Discipline – stick with it when it gets hard (ex: no bugs within sprint, no pushing stories to next sprint) Trust – This is developed slowly over time as commitments are met. Both trust within the team and trust from the business.
• #8: Team Formation Model Forming Getting to know each other, little trust, formal and rule based Signal ->Individuals sit by themselves and work alone, tasks assigned to one person Storming Power struggles, lack of understanding, conflict Signal -> Arguments / passive-aggressiveness, reduced communication, fights, “that’s not my bug!” Erick Fleming: “Automation reduces friction on the team.” Healthy conflict needs to be addressed, not squashed or hidden. Norming Shift from individual focus to team focus Signal-> pairing / people sitting and working together, signs of shared responsibility (“can we assign that task to both of us?”, fixing each other’s bugs) Self-organization- The purpose of self-organizing teams is not for management to lose control. The purpose is to unlock creativity!! Performing Complete focus on the team goal Output comes faster. Becomes harder to stay ahead of team and provide them with work. Ironically, this is when the habits are engrained and some of the formal disciplines can be dropped.
• #9: Not just for software teams Storming- kids don’t trust: If I throw the ball to you, you will throw it back If I let you catch this ball, you’ll me get the next one I started asking them to make small commitments (“pinky swear”) Keeps coming back to trust and commitment
• #10: In last month’s meetup, Erick Fleming as asked the following question: Q: How do we convince management to allow our development team to implement TDD? A: “First you have to gain the trust of the business.” If you want to be a software craftsman, you have to earn the trust of the business. Too many technical people focus exclusively on obtaining technical skills. But that doesn’t build trust. How do you build trust? Start with good habits, like we will discuss tonight. Make small commitments to yourself, your team, and your organization. And keep them. Have the discipline to stick with your commitments when things get hard.
• #11: This picture is from Diana Larson’s keynote address from the Agile 2014 conference last month called “Best Job Ever”. Teams start out with a lack of trust. They build trust slowly by making and holding small commitments. Inevitably there is conflict as the team attempts to switch from focus on individuals to focus on the group. This is where habits and discipline become important. Only when conflict has been addressed can a team reach its true creativity. And finally become high performing.
• #12: Coder vs Developer vs Craftsman There is no technical difference between developer and craftsman. Learning more technical skills won’t make you a craftsman.
• #13: Pyramid Model
• #14: User Stories Pyramid
• #15: Measure – how many stories have a descriptive and powerful “why”? INVEST Independent Negotiable Valuable Estimable Sizeable/Small Testable
• #16: Measure – how many stories have a descriptive and powerful “why”?
• #18: Design vs Documentation
• #19: Design Acceptance Criteria Test Cases Prototypes Process Flows Graphic Design
• #20: Design Acceptance Criteria Test Cases Prototypes Process Flows Graphic Design
• #21: Before the Sprint – think about how to implement the story. Complete prototypes and acceptance criteria. Get sign off from Product Owner. During the Sprint – test out the designs by writing code and getting feedback from Product Owner and customers. Begin documenting decisions that are made. Before the end of the Sprint – soon after the sprint ends, update all relevant documents with changes made during the sprint. Do no wait for multiple sprints to lapse, or for a major release, to update documentation. It will never happen!
• #23: Daily Standup The Power of Habit by Charles Duhigg Keystone habits are habits that are so transformative, that they naturally lead to other habits.
• #24: Should the team all stand for the standup meeting? Yes!
• #26: Definition of Done
• #27: Facilitator: Coach or ScrumMaster. Scrummaster should not be PO, PM, or manager
• #29: Definition of Done
• #30: Identify all tasks needed to complete the sprint definition of “Done”.
• #32: Definition of Done
• #33: QA Edge Cases Test Cases Automation Developers tend to be optimistic. Testers tend to be pessimistic.
• #34: Test your edge cases! The team must test and deliver the acceptance criteria. QA can help to identify edge cases and conditions that the acceptance criteria did not cover.
• #36: Definition of Done
• #37: QA Edge Cases Test Cases Automation
• #38: Identify all tasks needed to complete the sprint definition of “Done”.
• #40: Erick Fleming – Automation “reduces team friction”
• #45: Fully automated “If it hurts, do it more often.” Do not be scared of deploying to production. The answer is not to document more or create better checklists. Deploy to production more often. Code not deployed is “waste” – lean principal. It’s like inventory sitting in a warehouse. Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time. You’re doing continuous delivery when: [1] Your software is deployable throughout its lifecycle Your team prioritizes keeping the software deployable over working on new features Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them You can perform push-button deployments of any version of the software to any environment on demand
• #46: This is why stories must be valuable.
• #48: Pyramid Model
• #50: This picture is from Diana Larson’s keynote address from the Agile 2014 conference last month called “Best Job Ever”. Teams start out with a lack of trust. They build trust slowly by making and holding small commitments. Inevitably there is conflict as the team attempts to switch from focus on individuals to focus on the group. This is where habits and discipline become important. Only when conflict has been addressed can a team reach its true creativity. And finally become high performing.
• #51: QA Edge Cases Test Cases Automation
• #56: Team must have mindset that everyone tests QA Professionals can help lift quality of testing. Bottlenecks Not testing during sprint Not fixing all bugs during sprint Isolating testing to one person on team