Acknowledging Anti Patterns

Acknowledging Anti Patterns

Common aspect among Scrum, Kanban, XP, BDD or any other Agile methodology is their main goal.  All such frameworks or models aim to establish Agile mindset in team by adhering to 4 values and 12 principles mentioned in Agile manifesto

Among them, Scrum is the most popular one. Simple yet impactful, Scrum is structured framework, with well-defined ceremonies, roles and artifacts, plus ample of opportunity to do-it-the-way-it-suits-you.

Often during scrum adoption, team tend to practice / approach the ceremonies in a way, that in place of making team closer to Agile mindset (value and principle), it takes them away. Such practices are commonly referred as anti-patterns; as they tend to do just opposite to what the very purpose of a ceremony is.

Though, there is no pre-defined standard list of anti-patterns, and every team unconsciously creates its own unique anti-pattern; below are the most common ones, specially experienced with new team / SM.

* “How to resolve it” column’s points  are corresponding to full ceremony, and not mapped to one-o-one points of anti-pattern column

Ceremony Anti-Patterns How to resolve it*
Daily standpoint
  • Team treat daily meeting as a status meeting
  • Scrum master ask questions to everyone / takes status
  • Scrum master is speaking most of time
  • People are discussing technical solution in this meeting
  • Running beyond 15 minutes
  • People do it in standard way every day (like one by on speaking in an order and only focusing on 3 standard questions)
  • There is no fix time – often teams are doing it at different time
  • Every team member is not participating
  • Daily meeting is a day plan meeting
  • SM / Agile coach need to guide team to take it as team’s day plan activity
  • Focus should be on what we can accomplish today, whether we are on track as per Sprint plan / sprint goal
  • For any specific discussion on impediment, technical solution etc.; keep extra meeting time just after daily standup (ensure meeting room & calendar are booked upfront for this as well)
  • Gamify it, bring some funny and innovative way to do it … ensure you are breaking the monotony
Sprint Planning
  • PO does not participate always
  • Team do it anytime in Sprint (whenever they feel like)
  • People are discussing around story – dependencies, readiness, doubts, etc.   [Many time team do activities of Product backlog refinement meetings in planning meeting]
  • Every team member is not participating
  • Ensure it is first ceremony of Sprint (at the beginning of Sprint) – allocated appropriate time, block calendar etc.
  • Structure the planning meeting in two parts (What and How) – allocated appropriate time
  • A well-defined DoR (Definition of Ready) helps
  • Practice Product Backlog refinement meetings (PBR) – a good practice of PBR with fixed cadence enhances efficiency in planning meeting
  • Not having fixed duration – sometimes 2 weeks, sometime 3 or 4
  • Extend current Sprint by 1 or 2 days to achieve Sprint Goal
  • Longer than 4 weeks of Sprint
  • No defined Goal for a Sprint
  • In case of multiple team, different team have different Sprint cadence
  • SM / agile coach need to guide team on importance of fixed cadence and time boxing
  • Discipline over short term or immediate goal
  • Use of any scaling framework (Scrum of scrum / LeSS / SAFe) etc. in case of multiple team involved
  • Team is reviewing the stories to with only PO
  • Other stakeholders (from customer) are not participating
  • Even incomplete stories are being demonstrated in the review meeting
  • Team is treating it like a demo meeting
  • Every team member is not participating (only people giving demo of story is participating)
  • Need to understand it is a review meeting and not a demo
  • Practice “show and tell” with PO, to ensure only completed stories are being reviewed
  • A well-defined DoD (Definition of done) helps
  • PO needs to ensure that, other stakeholders (Client) are participating in this meeting
  • Block calendar in advance and communicate agenda
  • Beyond Dev team, PO and SM; others are also participating
  • Team are discussing about deliverables in this meeting
  • Every team member is not participating
  • Purpose of retrospection is process improvement (as a team)
  • As a team, need to understand what is working well (from process / practice standpoint) and what we need to do differently

To be on right trajectory, both awareness and acknowledgement of such anti patterns is important. For teams to be aware of anti-patterns is one thing, but acknowledging it as a team at right platform and/or during ceremonies is most important.  And a brave Scrum master leads this culture.

3 thoughts on “Acknowledging Anti Patterns

Leave a Reply