Agile Ceremonies - Dysfunctions, Why, How and What

Based on my experience as an Agile Coach I am taking the first stride forward to share the "reset basics" for "Agile Ceremonies" along with common dysfunctions. While doing same, I am also taking a different route to align those practices with "Golden Circle - Why - How - What" to ensure that team is not only following practices but also living, breathing the "practices", "principles" and "values".

Iteration/Sprint Planning

Dysfunction

• Iteration Planning is not happening
• Iteration Planning is merged with Iteration Showcase/Demo
• PO is not joining the Iteration Planning
• Team is doing story point estimation during Iteration Planning
• Team focuses more on task breakdown and effort estimation than understanding the Acceptance Criteria
• Acceptance Criteria is known to only few people - not documented in Story
• No idea about velocity driven approach/yesterday's weather or commitment driven approach

Iteration Planning - WHY

• Iteration Planning is done to commit the Iteration goal as per PO Prioritization and team capacity
• It provides the clarity to the whole team of what is to be delivered by the end of the iteration
• Team can discuss with PO if prioritized stories need further clarification
• It helps the team to get concurrence from the PO on the Acceptance Criteria for the prioritized and committed stories

Iteration Planning - HOW

• The team holds the iteration planning session on the first day of the iteration with PO
• The PO provides the prioritized backlog items to the team - PO can prioritize it earlier as well while backlog refinement
• The IM reviews velocity, yesterday’s weather - i.e. accomplished velocity in last Iteration
• The team selects user stories based on priority from the product backlog
• The team discusses the user story details, agrees on acceptance criteria with PO and identifies tasks.
• The team commits to user stories based on velocity (yesterdays weather)
• The team self-organizes and prepares the wall of work and the burn-down chart

Iteration Planning - WHAT

• Team comes up with clearly defined Iteration Objective and Goals based on PO Prioritization and their velocity/capacity (yesterdays weather/commitment driven approach)
• All Iteration Backlog items (Stories) are clearly understood by the development team
• Team is absolutely clear on the Acceptance Criteria for selected and prioritized stories - gets these verified by PO
• Team may wish to break the stories into tasks for better tracking - second half - matured teams may avoid it
• Team has all the details on all User Stories to get started with Iteration execution

Daily Stand up/Scrum Call

Dysfunction

• Misconception - Attending Daily Stand up means Team is Agile
• Becoming a Status Call
• Team start resolving the blockers
• Not taking in front of the board
• Tool dependent - whiteboard appears to them duplicate work
• Stand up does not add any value - rather give status in same time chat
• Not all team members joining
• Eager to give own status and then start working on other things - not listening to others
• Blame game for blockers/ dependent tasks
• Pointing fingers on others commitment - No respect for others
• lack of commitment - Finding excuses
• No fixed time - IM chasing the team for stand up
• Team members not aware of Social Contracts - created once, never looked into that since then
• IM always updating the Burndown chart and assigning work

DAILY SCRUM CALL - WHY

• Stand-ups are a quick and efficient way for the team members doing the work to keep each other informed on what they are doing, ask for assistance, and to surface blockers early.
• Team gets to know how close /far they are from meeting Sprint objective
• Team holds each other accountable for their commitment
• Helps to keep track of "outcome" getting generated - output is effort
• Helps identification of blockers that needs further attention
• Keeps the environment transparent and safe, with no hierarchy
• Team members are aware of each others commitment and challenge and extend their help
• Team shares success stories and failures

DAILY SCRUM CALL - HOW

• Each team member talks about what was done since the last stand-up, what will be done until the next stand up, and if there are any impediments or blockers.
• Update of Burndown, Issue Wall (Bulls Eye), Risk Wall
• Everyday 15 minutes - Meet at workspace before your scrum/Kanban board (for collocated team), so that you can update the board as you talk.
• Using virtual collaboration tool/ digital dashboard for distributed team - video call is recommended to have a feel of the virtual collocation
• Should start everyday on same time (agreed by team)
• Rotate the facilitator or passing the ball
• Core team, BA and PO/POP to be part of the daily stand-up
• No focus on resolution of the blocker

DAILY SCRUM CALL - WHAT

• Transparency - Actual understanding of the Work
• Team commitment and engagement
• Quality of the work
• Faster Identification of Blockers leading to faster resolution
• Updated Artifacts

Showcase - Sprint Review

Dysfunction

• Showcase call is not happening - PO is sending approval over email without even looking into working software
• Product Owner is not joining the discussion
• Iteration Manager is always presenting the same
• Showcase is done with presentation
• Team is hiding the facts and giving superficial status - sign of watermelon project
• Team is not asking for feedback / Satisfaction from PO
• Team members are not joining or not getting invitation
• Showcase is happening over phone - no demo
• Velocity is not discussed
• Showcase and next Iteration Planning are merged
• FLM not joining or after joining trying to control - team takes a backseat

Showcase - Why

• Showcase is to review progress against the iteration goal and team commitment
• To get everyone on the same page in terms of what was completed, what’s still on progress and what trade-offs were made
• To get a validation from PO whether the working software (Potentially Shippable Product Increment) has satisfied all Definitions of Done and ready for shipment (if MVP is achieved)
• To stay transparent by demonstrating the actual accomplishment (success and failure) and then doing an inspect and adapt in a safe environment - it is ok to fail
• To get opportunity to earn from mistake and quick course correction

Showcase - How

• Informal meeting that comprises of the demo of the working software to the product owner
• Requires a safe environment where team will share the fact and look for the open feedback to take informed decisions
• Iteration Manager, Core Team, Product Owner, Sponsor, Stakeholders will be present
• Team should try to make it light weight with String focus on the actual working software instead of documentation/presentation

Showcase - What

• Team demonstrates a potentially shippable product increment to PO / stakeholders
• PO will declare which items are done and which did not meet the acceptance criteria
• Measure velocity and get feedback from PO on how we are doing with the product
• It helps us to understands the mistake and opportunity to inspect and adapt to achieve the objective in future
• Project is assessed against the sprint goal determined during the sprint planning meeting
• Product Backlog gets updated with CRs or Defects

Retrospectives

• Dysfunctions
• Scrum Master/Iteration Manager tries to control the entire session
• Team members opinion is never heard
• Too generic - team members are afraid of sharing right picture
• No safe environment - team members don't share with a fear of being blamed
• Assumptions based discussion then fact based discussion
• Team members getting biased toward IM input - Dominators take the charge
• Hierarchy based model - juniors are not encouraged to speak or share their thoughts
• No action coming out of the discussion - no tracking of progress - end abruptly
• No visibility to PO on the retrospective inputs and on actions
• Scope not well defined - team thinks beyond sprint/Iteration scope
• Team does not understand the importance
• Become monotonous, lack of fun
• Repetitive inputs - becomes and template

Retrospective - WHY

• Each team member will get opportunity to share how the team is doing
• It helps us to do learn from our mistakes and do quick course correction
• Making good teams great thus implementing KAIZEN
• To create a psychological safe environment where team members can share their thoughts
• Good team building thus reinforcing Agile Values - Trust, Openness, Courage, Respect and Empathy
• Not to blame anybody but to share success and failure as a team

Retrospective - HOW

• Participants - Entire Team including product owner
• Set the Stage : Create an environment for participation by checking in and establishing working agreements.
• Gather Data : Define the scope and clear the objective, gather inputs from team relevant to the scope and objective
• Generate Insights : Discuss as a team on the inputs team members provided in a safe environment and generate insight
• Decide What to Do : Prioritize the team’s insights and choose a few improvements or experiments that will make a difference for the team.
• Close the Retrospective : Summarize how the team will follow up on plans and commitments. Thank team members for their hard work.
• Conduct a little retrospective on the retrospective, so you can improve too.

Environment :

• F2F is always better
• Use retrospective techniques - Constellation, Sailboat, Silent Brainstorming, Metaphors to break the monotony
• Use Collaboration Tools - Mural, Trello

Retrospective - WHAT

• Process Improvement ensuring "Doing the Right Thing"
• Last Ceremony in the sprint. Ideal duration for the retrospective meeting would be 1-2 Hours for iteration/sprint.
• A retrospective is a team activity, where team members meet (preferred face to face) to understand their current process, discuss how it can be improved, and generate action items that can be acted on or before the next retrospective.
• Frequent opportunity for team to inspect self and search for improvements, review and reflect
• Applicable for both Scrum and KANBAN
• Irrespective of Agile - Retrospective is a good technique to get quick feedback in psychological safe environment for quick improvement. It can be used for any training, workshop, facilitation as well

Backlog Refinement

Dysfunction

• Team members are busy - not having time for backlog refinement
• Team can do it during Iteration Planning
• Velocity will be impacted
• Can we add some story points to this?
• PO does not have time for Backlog refinement
• Team can have separate I0 to perform this activity
• PO can do this offline, why team members are required for this

Backlog Refinement - WHY

• To respond quickly to change in requirements - re-prioritization
• Have better preparation on the prioritized items for next iteration
• Iteration backlog is ready in advance before Iteration execution
• To reduce readiness time and get PO engaged to ensure Team understands the requirement correctly
• Backlog refinement sessions enable effective iteration planning by ensuring that user stories are current and complete
• This also ensured Backlog is live, up to date, informative and prioritized. It reduces the Cycle time in backlog and also ensures Team is "Doing the right work"

Backlog Refinement - HOW

• The Iteration Manager schedules the backlog refinement session during the later part of the current iteration, preferable several days before the start of the next iteration.
• The product owner and development team members attend, and the Iteration Manager facilitates the session.
• The team discusses each story and makes updates as needed.
• New stories and high priority stories are reviewed first; other stories reviewed as time allows.
• At the end of the backlog refinement session, the product backlog should reflect all updates discussed in the session.

Backlog Refinement - WHAT

• Backlog Refinement is sometimes referred to as "Backlog Grooming"
• Updated Product Backlog with more clarity and prioritization
• Prioritized Product Backlog with estimated stories for atleast next 2-3 Iteration
• Reduces Iteration Planning time and increases effectiveness
• Team gets to know about the details of the story ahead of time
• While reviewing stories, consider:
• Is the story clear? Is it still needed?
• Does the story include sufficient detail such as acceptance criteria and definition of done so that it can be estimated?
• Does the story need to be decomposed into multiple stories to fit into an iteration?
• Are additional new stories needed?
• It is not necessary for the entire team to participate in the backlog refinement sessions. Teams should consider rotating which members attend the backlog refinement session so that all team members have an opportunity to participate

Contact - Subhabrata Pal, [email protected], 9830619877