Challenges and Workarounds in Agile Journey

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

  1. 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.
  2. 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.
  3. 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
  4. 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.

Continue reading Challenges and Workarounds in Agile Journey

Story Grooming is everything in Scrum

One of the essential and fundamental elements why Scrum is becoming very important is that when the team sits together to discuss and groom the stories, is because of the grooming and tasking of efforts.

When the product owner or manager brings the intent and create a high level user stories, the team does detailed study of the story in understanding the value that feature or functionality brings to the user and starts writing the tasks to be done to meet or build the end user functionality.

A Scrum Master has to enable the team to write the story and detailed tasks required. This is important because each day when the team comes to work they should not squander around OR search OR go back to drawing board as to what needs to be done. Ideally the team member open the agile tool > go to the user story > read the tasks > start working on each task by task. This way its a total heads down approach to crank thru the work required of the sprint and provide the required user functionality by the end of the sprint.

To conclude, it is extremely important that the entire team understands this way of story grooming is must and should, otherwise the daily stand up calls or any other adhoc meetings happen during the sprint will not yield any value and simply Agile wont work.

Qualities of a Good Scrum Master

Qualities of a Good Scrum Master

Servant Leader - An empathetic listener and healer. This self-aware steward is committed to the growth of people

Coach - Can Coach the other team members on how to use Scrum in the most effective manner

Framework Champion - Is an expert on how Scrum works and how it should be applied

Problem Solver - Protects the team from organizational disruptions or internal distractions or helps remove them

Facilitator - Neutral participant who helps group of people understand their common objectives and assists them to achieve these objectives

Qualities of a Bad Scrum Master

Boss - Has the ability to hire and fire others

Task Master - Myopically focused on assigning and tracking of progress against tasks

Product Manager - Responsible for managing schedule,  budget and scope of the product

Apathetic - Lacks interest in or concern about emotional, social, or spiritual well being of others

Performance Reviewer - Responsible for documenting and evaluating job performance