Implementation of Agile (SCRUM) in company requires setup of few meetings to achieve benefits of this methodology. It could be very different across various companies and this is my perspective after 7 years experience with Agile.
Daily stand-up
goal: build team awareness about the progress of each story in the sprint, detect impediments and identify potential actions to remove them; reassess priorities to be sure that we are on right road with focus on ticket flow
who: team
moderator: SM
length: 15 minutes, every day
- it must be the heart-beat of the team, everybody should contribute and understands that this makes sense
- the same time and place every day,
- quick as possible: 'pam-pam-pam'
- sprint board (backlog and story we talking about) must be visible for everybody
- only one attendee talk in one time; SM should kill side talks
- team members should pick tickets voluntary (self organization)
- SM is discussing stories from top priority to lower ones and ask team members about the current status and impediments, the remaining work must be clear for everybody
- if new issue come (critical bug or support story or implementation of story become more complex than expected) should be quickly discussed
- each discussion longer then minute must be parked by SM and continue after the stand-up
- no blaming or hiding, no rude arguments, everybody acts openly, this type of issues have to be taken to retrospective for correct discussion
- SM should not allow to discuss topics not related to the sprint or team and rather schedule another meeting if necessary
- SM should not allow to talk people who are not committed to the sprint, this is valid also for managers (they cannot hijack stand-ups with their agenda)
- team members do not report to SM but to the team and everybody should listen
- in case of serious troubles always look for a hero
After stand-up:
- each parked discussion should be planned to continue
- if new critical tickets come into the sprint another one must be removed by the PO
- if team is not able to address some impediments SM must escalate asap
- SM must update board if necessary
Backlog grooming
goal: synchronization point on continuous preparation of next 1-2 sprints; backlog housekeeping
who: SM, PO, Architect, QA Lead, Team Lead + representatives of another teams if there is dependency
moderator: PO
length: 1 hour, twice a week
- PO presents new epics and stories according to the business needs
- attendees discuss dependencies and readiness of stories according to 'definition of ready' and identify actions if necessary (plan discovery or POC)
- architect quickly presents outcome of finished discoveries with draft estimations on story points in order to do story mapping
- SM presents average velocity or calculates velocity according planned days off
After grooming:
- architect/team should continue with PO & SM to work on not yet prepared stories
Bugs review
goal: do grooming of latest identified bugs or customer's issues
who: PO, SM, QA, support
moderator: engineering lead
length: 1 hour, once a week
- discuss all new bugs for last week, assign priority and plan sprint where to fix
- if some issue needs to be fixed in the current sprint another issues should be removed form the sprint according the current priorities
SoS
goal: synchronization between the teams in order to early identify inter dependencies and impediments
who: SM, PO, Leads, QA
moderator: engineering lead
length: 15 minutes, twice a week
- SMs quickly present status of the sprint
- QA presents status of quality
- all discuss current release plan and anticipate possible issue
After SoS:
- Leader is taking or delegate actions if possible
Review
goal: present done-done and identify unfinished work to whole team/company,
who: all who may concern (dev, qa, sells, management)
moderator: engineering lead
length: 90 minutes (max), once a sprint
- demo only really done-done work according to 'definition of done'
- story acceptance by PO must be done before meeting, during the sprint
- moderator should park all discussion about demo for another meeting to avoid bike-shed effect
- demo must be quick and well prepared
- architects present status of code quality & technical debts
- QA leader presents status of release, test automation and regression tests
- devops present status of CI/CD and software factory
- PO & Sells present road-map and next priorities / opportunities
Retrospective
goal: share all good & bad things happened during the sprint in order to clear the air and find the way to improve
who: team
moderator: SM
length: 60+ minutes, once a sprint
- it is about sharing of mood, way of thinking and perspective to build team spirit
- it is not blaming session
- sometimes could be very intensive and moderator must drive it well
- people should contribute voluntary - pop corn style
- topics are discussed one by one, not in parallel
- SM have to build atmosphere where mistakes are allowed
- SM should listen with focus on concerns and pains
After retrospective:
- SM takes care about identified actions, discuss with management and another teams if necessary
Planning
goal: plan next sprint in details, agree on goals and commit to them
who: team
moderator: SM
length: 90 minutes (max), once a sprint
- SM & PO or architect should present pre-prepared sprint from grooming to the team
- draft story points should be adjusted according the team (planning poker)
- team is doing detailed planning of stories to sub-tasks based on estimated hours
- SM compare total estimated hours from the team and calculated team availability; in case of discrepancy removes or adds stories according to PO's priorities
- SM makes sure that team consider sprint feasible and doable, in case of questionable stories SM is trying to find solution with PO
- stories which are not ready should not be accepted into the sprint
- avoid rabbit-holing
If team members complain about meetings moderators must take an action to make it better.
Each moderator should act as strong servant leader on all meeting he is responsible for.
We never do meetings just for meetings, everybody have to be sure why he is attending particular meeting and what is expected from him.
Daily stand-up
goal: build team awareness about the progress of each story in the sprint, detect impediments and identify potential actions to remove them; reassess priorities to be sure that we are on right road with focus on ticket flow
who: team
moderator: SM
length: 15 minutes, every day
- it must be the heart-beat of the team, everybody should contribute and understands that this makes sense
- the same time and place every day,
- quick as possible: 'pam-pam-pam'
- sprint board (backlog and story we talking about) must be visible for everybody
- only one attendee talk in one time; SM should kill side talks
- team members should pick tickets voluntary (self organization)
- SM is discussing stories from top priority to lower ones and ask team members about the current status and impediments, the remaining work must be clear for everybody
- if new issue come (critical bug or support story or implementation of story become more complex than expected) should be quickly discussed
- each discussion longer then minute must be parked by SM and continue after the stand-up
- no blaming or hiding, no rude arguments, everybody acts openly, this type of issues have to be taken to retrospective for correct discussion
- SM should not allow to discuss topics not related to the sprint or team and rather schedule another meeting if necessary
- SM should not allow to talk people who are not committed to the sprint, this is valid also for managers (they cannot hijack stand-ups with their agenda)
- team members do not report to SM but to the team and everybody should listen
- in case of serious troubles always look for a hero
After stand-up:
- each parked discussion should be planned to continue
- if new critical tickets come into the sprint another one must be removed by the PO
- if team is not able to address some impediments SM must escalate asap
- SM must update board if necessary
Backlog grooming
goal: synchronization point on continuous preparation of next 1-2 sprints; backlog housekeeping
who: SM, PO, Architect, QA Lead, Team Lead + representatives of another teams if there is dependency
moderator: PO
length: 1 hour, twice a week
- PO presents new epics and stories according to the business needs
- attendees discuss dependencies and readiness of stories according to 'definition of ready' and identify actions if necessary (plan discovery or POC)
- architect quickly presents outcome of finished discoveries with draft estimations on story points in order to do story mapping
- SM presents average velocity or calculates velocity according planned days off
After grooming:
- architect/team should continue with PO & SM to work on not yet prepared stories
Bugs review
goal: do grooming of latest identified bugs or customer's issues
who: PO, SM, QA, support
moderator: engineering lead
length: 1 hour, once a week
- discuss all new bugs for last week, assign priority and plan sprint where to fix
- if some issue needs to be fixed in the current sprint another issues should be removed form the sprint according the current priorities
SoS
goal: synchronization between the teams in order to early identify inter dependencies and impediments
who: SM, PO, Leads, QA
moderator: engineering lead
length: 15 minutes, twice a week
- SMs quickly present status of the sprint
- QA presents status of quality
- all discuss current release plan and anticipate possible issue
After SoS:
- Leader is taking or delegate actions if possible
Review
goal: present done-done and identify unfinished work to whole team/company,
who: all who may concern (dev, qa, sells, management)
moderator: engineering lead
length: 90 minutes (max), once a sprint
- demo only really done-done work according to 'definition of done'
- story acceptance by PO must be done before meeting, during the sprint
- moderator should park all discussion about demo for another meeting to avoid bike-shed effect
- demo must be quick and well prepared
- architects present status of code quality & technical debts
- QA leader presents status of release, test automation and regression tests
- devops present status of CI/CD and software factory
- PO & Sells present road-map and next priorities / opportunities
Retrospective
goal: share all good & bad things happened during the sprint in order to clear the air and find the way to improve
who: team
moderator: SM
length: 60+ minutes, once a sprint
- it is about sharing of mood, way of thinking and perspective to build team spirit
- it is not blaming session
- sometimes could be very intensive and moderator must drive it well
- people should contribute voluntary - pop corn style
- topics are discussed one by one, not in parallel
- SM have to build atmosphere where mistakes are allowed
- SM should listen with focus on concerns and pains
After retrospective:
- SM takes care about identified actions, discuss with management and another teams if necessary
Planning
goal: plan next sprint in details, agree on goals and commit to them
who: team
moderator: SM
length: 90 minutes (max), once a sprint
- SM & PO or architect should present pre-prepared sprint from grooming to the team
- draft story points should be adjusted according the team (planning poker)
- team is doing detailed planning of stories to sub-tasks based on estimated hours
- SM compare total estimated hours from the team and calculated team availability; in case of discrepancy removes or adds stories according to PO's priorities
- SM makes sure that team consider sprint feasible and doable, in case of questionable stories SM is trying to find solution with PO
- stories which are not ready should not be accepted into the sprint
- avoid rabbit-holing
If team members complain about meetings moderators must take an action to make it better.
Each moderator should act as strong servant leader on all meeting he is responsible for.
We never do meetings just for meetings, everybody have to be sure why he is attending particular meeting and what is expected from him.
Comments
Post a Comment