Practitioners Corner - June'2021

We conducted Agile Practitioner’s Corner on June'2021. Below is the summary of the challenges the practitioners had and how we got it discussed them. 

What is a Practitioner's corner?

Practitioner’s Corner is an event where both Agile Practitioners and aspiring agilists meet to share experiences and learn from each other. In this online meetup, 

• Participants post real-life issues to be discussed. 
• Participants vote for the topics they want to discuss
• Groups will be formed with Agile Practitioners and novice agile enthusiasts
• Groups pick up cases in the order of priority and explore the problem and possible solutions 
• The whole group discusses the problem and solutions together

What were the topics of discussion?

We have chosen five topics based on the votes. Based on the number of participants, we have split into five teams. Each team will choose an issue, and the person who posted the problem will be part of the team. Below are the top five issues voted.

1. Problem 1: How to handle distributive teams, especially when the culture is different and doesn’t match expectations?
2. Problem 2: Product owner time availability is less; thus, it will reduce the decision-making process and impact as he will step in at the last moment.
3. Problem 3: Metrics discussion on cycle time, lead time Control charts, and Distribution. Any other metric can be used?
4. Problem 4: Multiple discussions -
1. How to overcome the myth of a scrum master acting as a Business Analyst or Product Owner Scrum Master?
2. How to motivate the team during the retrospective?
3. The Product Owner needs my help in understanding the IT working on how things will work during the development cycle.
4. What next in the career path of SM in terms of growth?
5. Does acting as a kind of team lead for most Scrum team members and working as Scrum Master create an issue?
6. Can the Scrum team work on activities other than the current project? If so, how to keep them focused?
7. How to shift from Scrum Master to Agile coach?
5. Problem 5: How to explain the manager who measures every KPI per waterfall. story points throughput - 
1. The number of story points achieved per person in a sprint.
2. The number of lines of code is written in a stipulated amount of time.
3. He believes that the more the impact, the better the work mindset.
4. As per him, Lean suggests that testing is a waste of time. How to convince him that testing is also needed? No logical explanations have worked so far. 

Problem 1

After the team went into break-out rooms, they inquired about the problem statements in detail, and below are the observations. 

• The teams are distributed in different locations across Germany, India, and the USA.
• Each person needs to deliver seven story points.
• Estimation is done by the team. The estimation logic is one story equals eight hours. 
• Both timeboxing and work boxing is carried out in parallel.
• Even two developers together are unable to complete the story points. 
• The pressure is there constantly, and developers are unable to finish their story points. 
• Issues are discussed in retrospect, and action items are derived, but there is no action on action items ever. 

Post inquiry, a few things that emerged out of the discussion were, 

• Story points are connected with hours; each one has to complete the same story points. (story points are relative, they should not be linked with hours) The team should be able to either do it using story points or by using hours. Using the relative estimation technique and tying it to hours is not actually common sense. 
• Instead of output metrics, focus on the outcome metrics which the team wants to deliver. That way, there won’t be any expectations mismatch. 
• Ensure the developers work as a team. Start doing some team-building activities to increase vulnerability between them. 
• Rather than focusing on metrics, coach them to keep the focus on the sprint goal.
• Help the work on removing the impediments so that they can achieve sprint goals.
• Identify the technical and functional knowledge gaps of the team. Help them fill those gaps by constantly upskilling them. 

Problem 2

Using inquiry, the team uncovered the below for this problem statement. 

• As the Product Owner contributes to other initiatives, he delegates work to the Business Analyst and significantly less time spent on the team.
• Sometimes, the Scrum Master takes up the ownership and acts as a proxy Product Owner. 
• As the Product Owner is only available almost at the end of the work, the team has to rework again and publish it.
• The Scrum Master has spoken to the Product Owner and the management about this Product Owner’s unavailability problem. However, it made no difference at all. 
• The Scrum Master regularly connects with the actual Product Owner to talk about the progress.
• The project timeline is between nine to twelve months, and they are running three weeks sprint. 
• Once every fifteen days, the Product Owner is available for the backlog refinement activity. It’s still not 100% but at least 70% of the time. 
• The team meets to review their work only after a couple of sprints, which is six weeks. They also meet face-to-face only once every fifteen days. 
• The team is showcasing work after two sprints which is 6 weeks.
• The team meets are working remotely and meet once in 15 days rest of all audio calls.

Post inquiry, below are the few things that emerged as takeaways for the problem holder. 

• Showcase the completed work and get feedback from the Product Owner whenever he is available for the Product Backlog refinement activity. 
• For increasing feedback loops, try working with the developers and the Product Owner to bring the timebox to two weeks instead of three weeks sprint. 
• Collect data regarding the unavailability of the Product Owner and how it affects too much rework. Also, a constant increase in the cost of production.
• One other option is to identify a decision-maker who can review the work and be available for the team when in need. However, data needs to be presented to management to get it done. 

Problem 3

Exploration of this problem gave more insights into the team structure. 

• There are three vendors for this project, and all three of them were top service companies. Together, they formed a scrum team which includes the Product Owner. 
• Line Manager/Reporting Manager is from the customer end. The manager handles a couple of scrum teams. 
• Bugs keep coming up because of unclear requirements. The team has none to clarify the requirements, which results in more bugs. 

Few suggestions to work here,

• Help the team to come up with good metrics that can help them uncover problems earlier. There should be proper action items, and implementing those should help the team further improve their work. 
• Help the team to focus on delivering value by keeping the focus on Sprint's goal. 
• The metrics should help the team in delivering better than making management question them. Also, metrics should be used to make decisions. If a metric doesn’t help in making decisions, then it should go away. Also, allow them to keep a watch on vanity metrics. Data collection for metrics takes time, so measure only what matters the most.  
• Since there are multiple vendors involved, there should be formal working agreements between them. Help them in formulating better working agreements that can help them. 

Problem 4

As there were many questions in this problem statement and the questions are of general context, let’s focus on the takeaways as part of each question. 

• How to overcome the myth of a scrum master acting as a Business Analyst or Product Owner a Scrum Master?

1. As a Scrum Master, one’s responsibility does not lie in business. The Scrum Master helps/serves the Product Owner in doing their job efficiently. However, they cannot take over the role of a Product Owner. One of the critical things is setting a clear boundary for the role regarding dos and dont's. Scrum Master cannot pitch in during the absence of the Product Owner or a Business Analyst. 

• The Product Owner needs my help in understanding the IT working on how things will work during the development cycle.

1. Since there is a junior Business Analyst on board, help the person pick up things faster. Have clear goals in terms of ensuring domain knowledge and functional knowledge are transferred. 
2. As the Business Analyst is transitioning into the Scrum Master role, the person should focus more on Scrum Mastery. In the absence of the Product Owner, the responsibilities should be transferred to the junior Business Analyst who will currently substitute for the Product Owner. 

• How to motivate the team during the retrospective?

1. One of the easiest ways to get the team’s trust is to identify the old retrospective action items that need implementation. Help the team in implementing the action items and show progress. When people see that their proposed improvements are addressed, it helps them, volunteer, even more. 
2. Identify more different ways and means of conducting a retrospective. It helps the team have more fun ways of retrospectives than thinking of it as just another meeting. 
3. Get more feedback from the team on how they want retrospectives to be, use it as a meeting for shoutouts on the best contributors in the group, and appreciation for fellow team members.

• What next in the career path of the Scrum Master in terms of growth? How to shift from Scrum Master to Agile coach?

1. A new Scrum Master is an entry-level Scrum Master who will be a Team Facilitator. A team facilitator’s primary competencies are being a Lean-Agile practitioner along with Facilitation skills. New learning like advanced scrum master courses helps them get better at their job. 
2. Once after acquiring experience with the single team and helping them become self-organized, the Scrum Master will adopt new teams under their wing. They now need teaching, mentoring, and coaching skills to do their job of coaching multiple teams. They become Team coaches at this point and will be called Agile Coaches. With the current competencies, they can coach till the program level in any Organization. 
3. Once after acquiring the skillset and competency to coach multiple teams and projects, the team coach will now level up as an enterprise coach. Gaining mastery of what kind of coach they are, helps them coach the leadership, executives, and other Agile Coaches. The work on Organizational change strategies, enterprise-level transformations, leadership coaching, and so on. 
4. After becoming an Enterprise Coach, the individual becomes an expert in the organizational process and strategies. They have the potential to become a COO of an organization or even become a one-person Organization. 

• Does acting as a kind of team lead for most Scrum team members and working as Scrum Master create an issue?

1. Scrum Master is a servant leader who does not have authority. Their roles help them serve the other roles in Scrum in doing their job more efficiently. One of the vital qualities of a facilitator is “no authority.” The team leader has authority over the team. Yes, it will make the team not speak up on improvements or accept their mistakes. One thing the team lead can do is leave the role as a team leader and become a full-time Scrum Master. They can also become a Scrum Masters for other teams while remaining as team leads for a current team. 

• Can the Scrum team work on activities other than the current project? If so, how to keep them focused?

1. Just because the Product Owner has more than one product under them, they cannot make the developers work on more than one product at a time. If teams work on multiple things at a time, it will take their focus away. Depending on the pressing issue, one or two developers can support other products while the entire team can focus on the sprint goal. 

Problem 5

Let us look at some of the information that emerged during the inquiry. 

• Teams unable to meet the amount of work commitment as per capacity calculation. Planned work gets incomplete and is unable to be moved to future sprints.
• Few engineers do not cope with this work commitment, whereas the rest can match the expectations.
• The Product Owner’s work commitment fails stakeholders due to this.
• Developers don’t speak up when asked about sprint goal commitment. 
• There is no monitoring of retrospective action items for process improvement, and the Scrum Master does not have a mechanism to close open action items. 

Suggestions to work,

• Developers were unable to deliver as per commitment even after one and a half years of ramp-up time. Identify whether the developers understand the estimates. Teach them about estimates and what purpose does it serve. Overcommitting items for the sprint will result in missing the sprint goal, and eventually, the Product Owner will miss out on commitments before stakeholders.
• Speak to the developers one on one to identify a gap in their understanding of requirements, estimation, commitment, etc. Help them address the issues clearly to improve commitment.
• Understand developers’ expectations and help them meet those in work. Since only a few developers could meet the expectations, talk to them and understand how they can make it. 
• Revisit the capacity planning, capability of the team, and expectations from the Product Owner. Help developers with outcome metrics than forcing them to deliver story points. 

 Hope you had a good read. You can also check out the recording of the practitioner's corner, here. 

With 11+ years of experience in the field, Leanpitch has successfully upskilled 90,000+ people across 12+ countries. Explore our website, Our trainers are internationally acclaimed for their insightful and experiential training.