Scrum Ceremonies execution for a Large group of people
After a decent thought, i decided that why shouldn’t I write about that way I contributed to the agile transformation in my current client. I wanted to talk about the challenges, opportunities, workarounds we as a team reap benefits from agiles/scrum framework.
The context here is running agile for a large group of people who are divided in several teams. We tried our best to and then kept the count of each team in control but we ended up having a little more than the what is considered to be a perfect count of an agile team. Also the members of the group come from various functional backgrounds like Development, Testing, Service Delivery, Business Analysis, Project and Product management
- Daily Standups – This was my challenge right of the bat. On one hand i had the rule for myself that i should run the standup for more than 15 mins and on the other hand i had to ensure the every team is given an opportunity to talk about 3 important things covered during standup. a) what have i done yesterday b) what will i do today c) are there any roadblocks that impede progress. Initially i failed to tie all ends, but over a period of time after trying several options/attempts i succeeded in tying all ends. Since I know that the people who attend the meetings are from various functional backgrounds we decided to go by the development first, testing, service delivery and business analysts. This way we ensured that we complete our standup in precisely 15 mins.
- Story Grooming and backlog prioritization – The Project/product that we belong to from customer service background so there are many business groups who send requests to us to have their functionality, data, feature hosted on our platform. So after all the intake/demand/delivery discussions are done the Product management group comes with the list of approved or prioritized projects list. That is the demand or in short very high-level projects or epics. As a first step our Business Analysts would create the epics and stories under each epic and create a high-level backlog. Initially we followed a schedule of doing 2 – 2 hour sessions per week of story grooming but over a period of time we didn’t create enough stories for the development team to take up work for each sprint. We were always behind the expected backlog considered the teams velocity. Then we use to have a 2 hour user story grooming each day for about a week and come up with the product backlog items. This way we created a separate bucket of time in each release to ensure we are DONE with backlog creation before we start our functional sprints.
- Sprint Review/Product Demo – Given those many business groups or customers who wanted to see their functionality, features in our product, having them all sit in one demo in like 2 hour meeting in a single day was next to impossible. We had challenges from logistical angle, meeting schedule etc., Though we had our internal mini demos/reviews whenever the sprint backlog was DONE or not DONE or partially done, to me the critical review/demo was when i scheduled consecutive 2 or 3 day session inviting all stakeholders to the demo either the end of sprint OR release. That way we strived a fine balance between customer/stakeholder satisfaction and sticking onto having a review/demo ceremony once at the end of each sprint
- Sprint Retrospective – Given the no of people in each development team it posed a challenge to me that the most important ceremony of all to reflect and adapt [Retrospective] doesn’t carry the value or momentum it provides to the team. So i split this ceremony into 2 groups. I had a Retrospective meeting once every sprint where people from development groups are invited and contribute and then I had a another group of people who are mainly the functional managers of the people of first group. Though this may not be a not so effective or standard way of running Sprints but given all constraints to me this sounded the balanced way. Bottom-line this worked and we had satisfaction from everyone involved in the Project.