Agile Anti-patterns - Sean Gilligan and Angie Mathieu - Agile Maine Day
•Download as PPTX, PDF•
0 likes•151 views
Agile Anti-patterns - Sean Gilligan and Angie Mathieu - Agile Maine Day
Recommended
Recommended
More Related Content
Similar to Agile Anti-patterns - Sean Gilligan and Angie Mathieu - Agile Maine Day
Similar to Agile Anti-patterns - Sean Gilligan and Angie Mathieu - Agile Maine Day (20)
More from agilemaine
More from agilemaine (20)
Recently uploaded
Recently uploaded (20)
Agile Anti-patterns - Sean Gilligan and Angie Mathieu - Agile Maine Day
- 1. Agile Anti-patterns Agile Maine Day April 26, 2019
- 2. Internal Introduction •Sean Gilligan • Agile Coach •Angie Mathieu • Senior Scrum Master 2
- 3. Internal Format • What are Agile Anti-patterns? • Where do we observe them? • Interactive Discussion: • Identifying anti-patterns • Observing their impact • Resolving them 3
- 4. Internal What are Agile Anti-patterns? • Practices that initially look like good ideas but end up having negative consequences when applied • Practices holding back Agile teams • Practices that run counter to the Agile Manifesto 4
- 5. Internal Agile Manifesto: 4 Values • Individuals and Interactions over Processes and Tools • Working Product over Comprehensive Documentation • Customer Collaboration over Contract Negotiations • Responding to Change over Following the Plan 5
- 6. Internal Where can we find Agile Anti-patterns? 6
- 7. Internal Anti-patterns with Team Members 7 Examples Product Owner Delays Acceptance Of Work Scrum Master Doesn't Protect Team Team Working on Side-gigs Measure Creates an artificial queue. Increases cycle time. Risks Sprint Goal. Impedes the Team's productivity: Signals conflict within team. Distrust. Impedes productivity.impacts velocity, cycle time, defects, happiness.
- 8. Internal Daily Scrum Anti-patterns 8 Examples Monologues Measure Scrum Master taking updates as opposed to the actual purpose Not following agreed Timebox Signals conflict within team. Distrust. Impedes productivity.
- 9. Internal Backlog Refinement Anti-patterns 9 Examples Prioritization by Proxy Incomplete User Stories Missing or Unrealistic Acceptance Criteria Measure Potential confusion around sprint goals, vision & product roadmap Productivity loss. Acceptance Criteria is added during Sprint. Team burn out. Missing customer expectations. Working over capacity.
- 10. Internal Conclusion 10 "Success is not final, Failure is not fatal: It is the courage to continue that counts." - Winston Churchill
Editor's Notes
- An anti pattern is a frequently used, but largely ineffective solution to a problem. The term was originally used to refer to a pattern gone wrong. As Scrum practitioners, we all know that Scrum has events, artifacts, roles and rules. If the core principles, foundation ideas or the agile manifesto is ‘tweaked’ hoping they would provide benefits because teams are not seeing immediate results, this may result in an anti pattern. This in turn may become an ineffective solution to a problem
- An anti pattern is a frequently used, but largely ineffective solution to a problem. The term was originally used to refer to a pattern gone wrong. As Scrum practitioners, we all know that Scrum has events, artifacts, roles and rules. If the core principles, foundation ideas or the agile manifesto is ‘tweaked’ hoping they would provide benefits because teams are not seeing immediate results, this may result in an anti pattern. This in turn may become an ineffective solution to a problem
- PO Delays: The product owner does not accept sprint backlog items once those are finished. Instead, he or she waits until the end of the sprint. (In the spirit of continuous integration, the product owner should immediately check tasks that meet the acceptance criteria. Otherwise, the product owner will create an artificial queue which will increase the cycle-time. This habit puts also reaching the sprint goal at risk.) SM Doesn't Portect Team: The scrum master allows stakeholders to disrupt the flow of the development team during the sprint. (There are several possibilities how stakeholders can interrupt the flow of the team during a sprint. For example: The scrum master has a laissez-faire policy as far as access to the development team is concerned. The scrum master does not object that the management invites engineers to random meetings as subject matter experts. Lastly, the scrum master allows that either stakeholders or managers turn the daily scrum into a reporting session. Any of these behaviors will impede the team’s productivity. It is the scrum master’s obligation to prevent them from manifesting themselves.) Team Side-gigs: The team is working on issues that are not visible on the board. (While sloppiness is excusable, siphoning off resources, and by-passing the product owner – who is accountable of the scrum team’s return on investment – is unacceptable. This behavior also signals a massive conflict within the “team.” Given this display of distrust—why didn’t the engineers address this seemingly important issue during the sprint planning or before—the team is probably rather a group anyway.)
- How did we identify it? Status report: The daily scrum sounds like a status report and team members waiting in line to give status updates to Scrum Master, PO and Stake holders. Monologs: Team members violate the time-boxing, starting monologs. Disrespect : Other team members are talking while someone is sharing his or her progress with the team. How did we measure the impact? Assignments: PO and Scrum Master starts assigning tasks to team members. Cluelessness: Team members are not prepared for the stand-up. How did the team resolve it? Red dots: A team member experiences difficulties in accomplishing an issue over several consecutive days, and nobody is offering help, we prioritize that. Stop problem solving: SM starts putting Parking lot items which can be addressed offline outside of the daily scrum time
- How did we identify it? Prioritization by proxy: A single stakeholder or a committee of stakeholder prioritizes the product backlog. PO position is not strengthened\ No more than a title: The product backlog contains user stories that comprise of little more than a title. Missing or Unrealistic acceptance criteria: There are user stories in the product backlog without acceptance criteria How did we measure the impact? Component-based items: The product backlog items are sliced horizontally based on components instead of vertically based on end-to-end features How did the team resolve it? Create DoR: The scrum team creates a ‘definition of ready’ that product backlog items need to match before becoming selectable for a sprint. What team?: The Product Owner creates stories with "why” and "What", entire team answers the "How" question and collaborate on the "What" question.
- PO Delays: The product owner does not accept sprint backlog items once those are finished. Instead, he or she waits until the end of the sprint. (In the spirit of continuous integration, the product owner should immediately check tasks that meet the acceptance criteria. Otherwise, the product owner will create an artificial queue which will increase the cycle-time. This habit puts also reaching the sprint goal at risk.) SM Doesn't Portect Team: The scrum master allows stakeholders to disrupt the flow of the development team during the sprint. (There are several possibilities how stakeholders can interrupt the flow of the team during a sprint. For example: The scrum master has a laissez-faire policy as far as access to the development team is concerned. The scrum master does not object that the management invites engineers to random meetings as subject matter experts. Lastly, the scrum master allows that either stakeholders or managers turn the daily scrum into a reporting session. Any of these behaviors will impede the team’s productivity. It is the scrum master’s obligation to prevent them from manifesting themselves.) Team Side-gigs: The team is working on issues that are not visible on the board. (While sloppiness is excusable, siphoning off resources, and by-passing the product owner – who is accountable of the scrum team’s return on investment – is unacceptable. This behavior also signals a massive conflict within the “team.” Given this display of distrust—why didn’t the engineers address this seemingly important issue during the sprint planning or before—the team is probably rather a group anyway.)
- PO Delays: The product owner does not accept sprint backlog items once those are finished. Instead, he or she waits until the end of the sprint. (In the spirit of continuous integration, the product owner should immediately check tasks that meet the acceptance criteria. Otherwise, the product owner will create an artificial queue which will increase the cycle-time. This habit puts also reaching the sprint goal at risk.) SM Doesn't Portect Team: The scrum master allows stakeholders to disrupt the flow of the development team during the sprint. (There are several possibilities how stakeholders can interrupt the flow of the team during a sprint. For example: The scrum master has a laissez-faire policy as far as access to the development team is concerned. The scrum master does not object that the management invites engineers to random meetings as subject matter experts. Lastly, the scrum master allows that either stakeholders or managers turn the daily scrum into a reporting session. Any of these behaviors will impede the team’s productivity. It is the scrum master’s obligation to prevent them from manifesting themselves.) Team Side-gigs: The team is working on issues that are not visible on the board. (While sloppiness is excusable, siphoning off resources, and by-passing the product owner – who is accountable of the scrum team’s return on investment – is unacceptable. This behavior also signals a massive conflict within the “team.” Given this display of distrust—why didn’t the engineers address this seemingly important issue during the sprint planning or before—the team is probably rather a group anyway.)