The Team that you serve, “Beginner’s Luck”, made the transition to an Agile method approximately two months ago by selecting Scrum. Following an Agile Boot Camp that detailed the specifics of the method, the Team established a number of roles and began executing two-week sprints. Throughout your eight sprints together, a number of issues have arisen that are making you think that the Team’s luck may have run out.
First, the Team is struggling to get to a potentially releasable product increment each sprint. While everyone is busy during the sprint, it just seems like there isn’t enough time within a two-week to get everything “Done”. Some members of the Team have mentioned that extending the sprint to three-weeks might help complete all of the testing so that you could actually release, but you are unsure as to what to do.
Part of the problem may be the Team’s Product Backlog. The Team struggles in every Sprint Planning meeting to understand each of the Product Backlog Items. Some of them are incredibly large causing the Team to spend an inordinate amount of time during Planning understanding and breaking them down. You have spoken to the Team’s Product Owner, Sonny, about helping the Team out by reviewing the Backlog prior to Sprint Planning, but he stated, “I just don’t have any more time to devote to developing this system. I’m stretched as it is, besides, I don’t know enough about this area of the business.”
One of the business analysts on the Team has been attempting to help Sonny in fulfilling his role, but has not been very successful. The Team doesn’t seem to be respecting June’s opinion often commenting, “June – the Product Owner owns the Product Backlog” or “That’s great June, but you don’t understand how the system works”.
June has really made an effort to work in a cross-functional way since the Team made the move to Scrum. She has been offering to not only assist Sonny, but also help out with testing and even expressed interest in learning how to write SQL. Most of these efforts have been rebuffed as a number of the Team members claim that June simply doesn’t have the skills necessary to assist or state, “Having you help will just slow me down”.
As you settle in your car for your commute home and survey the Las Vegas skyline glistening against the fading sun, you ponder what, if anything, can be done to help the “Beginner’s Luck” Team.
How do you define success for your team? Take a moment to think about this…
Remote work has transformed how organizations operate, with virtual teams becoming the new normal across…
Effective leadership has never been more critical. Whether managing a team in a high-pressure corporate…
Remote work has transformed how organizations operate, with virtual teams becoming the new normal across…
The Business Analysis Body of Knowledge (BABOK® Guide v3) is a comprehensive guide to the…
A certified Business Analyst (BA) has successfully passed an International Institute of Business Analysis (IIBA.org)…
View Comments
It's great that the BA wants to help the product owner. This is a good solution, if the PO gets on board and takes the time to get the requirements/stories groomed.
The team needs to learn better how to work together to help - if one fails, they all fail. Some team building could help here. Also, reducing the expected amount of output to get to a successful sprint would help everyone feel better.
No mention is made of the retrospective - this could lead the team to finding some of their own solutions.
My understanding of agile is that the agile team makes the decisions and manages the work; however, it seems like this situation may be beyond the new agile team's abilities and someone with authority may have to step in. I'm assuming there is time to make adjustments in this scenario since no big deadline is mentioned.
1. The product owner needs to make the time to learn his business or be replaced by someone who does know it.
2. Product owner (current or replacement) needs to spend time with the team breaking down the backlog into more manageable pieces of work that fit a two week sprint;
Or, the team should consider making the sprints longer especially if they have not released anything due to not completing testing during the 8 previous sprints.
3. The entire agile team needs retrained on agile methods, roles and responsibilities and how they are to engage on the project.
I think the team needs to learn to work together and stop thinking about me and my work. It is the Teams work and we all succeed or fail together. The BA should be able to assist the PO so that backlog grooming and sprint planning can go much smoother. Maybe the Product Owner needs to be replaced with a Product Owner that understands the portion of the business that the team is working on. Retrospectives would also help the team see what isn't working and what is in their power to fix.
The biggest issue with the Beginners Luck team (and unfortunately a fairly common one) is that the team may be following several agile practices, they have not fully adopted the agile mindset. A true spirit of collaboration seems to be missing from the team. One way I have found to address that, suggested by Laura, is to discuss it during a team retrospective. This will not be an easy conversation to have, but it's one that the team will need to have at some point in order to move effectively as a team.
Let's assume they successfully have that conversation and become more open to having people contribute out of their area of specialization and improve their skills. There are a variety of things that they can do to address the issue of not getting everything Done. These are all things I have found to work with teams I have been on.
First, if a team is finding that they aren't able to get to their definition of done in a sprint, they may want to consider bringing fewer items into their sprints. This will help them work through their processes and figure out where they may have some inefficiencies. I have found this approach better than extending the sprint a week because it maintains the team's ability to respond quicker to changes in priority.
Second, doing some backlog refinement (also known as Discovery) prior to a sprint can be very helpful to generate a list of ready stories that the team can consider at sprint planning and allow them to jump into testing and developing at the beginning of the sprint. The key with doing backlog refinement prior to the sprint is that you get the different perspectives in the team (development, testing, business, and perhaps even user experience) involved at least at some point in the backlog refinement. This can help mitigate the lack of knowledge about the system (real or perceived) on behalf of Sonny and June.
Third, Chris Matts described a great technique teams can use to make their efforts to spread skills more intentional. It's a concept called Staff Liquidity. Of course to make this work, the team needs to be serious about spreading knowledge around the team, so a mindset shift is needed first.
The team needs to redefine what "done" means and adopt a more iterative approach. For example, instead of trying to get the full page that shows the slot machine actually working in a full sprint, they should break it down into smaller pieces (randomization algorithm v1, page layout with controls that don't do anything (or do a very minimal feature set), build the CSS to skin the pages, etc.)
Then they'll have something to show the PO who can provide additional feedback after seeing something.
The stories have to be atomic. You're trying to build a "potentially releasable" product at the end of each sprint. There may not be any customers who are willing to adopt what you're releasing, but that's ok. As you do each sprint, more and more functionality will be delivered until there's enough for someone to want to use the product.
There are actually several problems and therefore several solutions.
1. The backlog issue needs needs to be better broken out by breaking the requirements/stories into smaller bits. To do this you need a product expert. If the BA can do that then have the PO give them that power. Maybe the BA does the work and the PO does the approval since the PO has limited time. Also you may need a different PO.
2. The break down of the backlog into smaller chunks may allow sprints to complete.
3. When planning the team should make sure the sizing of what their taking on can complete through testing in the sprint time. If nothing can complete in the sprint time, change the sprint duration.
4. Team building to teach people to respect each others skills and contributions to the process. I believe this is why Agile will fail in many organizations. The whole concept of collaboration is not embedded in the culture of the organization/team.
Congratulations, Roi-Lynn! You have been chosen as the winner of a $50 Visa Gift Card! Be on the lookout for an email from us to claim your prize.
I see that the Beginner's Luck team has a couple of opportunities:
1. They aren't able to get potentially releasable product at the end of each sprint.
2. The team struggling to understand each Product Backlog Item (PBI).
3. June is trying to help out the team by taking on responsibilities that aren't hers.
The reason why items aren't shippable at the end of an iteration can be numerous. Stories might not be complete, stories may be too large or there may be external dependencies. I would suggest that the stories be broken down into smaller stories. Since the team is rather new to Agile, tasking might be a little difficult, but the BA should be able to apply story splitting techniques to get the stories at a more granular level.
The team struggling to understand each PBI could be caused by the complexity of the PBI. If that is the case, again, making the stories more granular would help the team understand the stories and hopefully would help the BA fill in any gaps that would've been missed with larger stories. A story map for the team would be helpful to show the team so they have a holistic view of features & how stories relate to one another.
June wants to help the team, but is getting rebuffed. It's admirable that June wants to help the team by taking on responsibilities that aren't in her job description. Rather than flat out rejecting June's help, the team should help June by setting time aside to properly teach her the skill she's trying to learn. The team is fully accountable for the product, so responsibilities and ownership should not be siloed; there should be collaboration between roles.
There are several opportunities for this team. My first thought is to bring in a professional agile coach to help address these issues. There are really two opportunities here; help the team to get to a point in which they create a potentially shippable product each sprint and develop trust and collaboration within the team. To that end, recommend the following:
1. Discuss these items in a retrospective and take action to make things better. There is no mention of retrospectives, so it’s unclear if the team is inspecting and adapting to make things better.
2. To develop better trust and collaboration, the team can hold exercises to build better working relationships and implement pairing and mobbing. This will also help with cross-skilling.
3. Help the team to understand that cross-skilling is an investment that may cause a slight slowdown now in exchange for increased speed later.
4. There appears to be an issue with testing. It’s possible that developers are either handing off code to testers after the code is complete or they are waiting to the end to test. Work together to test as code is being developed and implement software engineering practices such as TDD and ATDD to help with this.
5. There is no mention of story refinement. The team should get together to review the backlog and refine near-term stories to build a healthy backlog. This activity should be done before sprint planning, not during. The PO needs to be involved in these activities and if neither they nor the BA has knowledge about that area of the business, they can bring in business representatives during refinement to help understand the stories and their value. The BA can also help by working with the PO and business representatives to increase their knowledge and start breaking down stories.
6. Limit WIP. The team appears to be taking on too much. Increasing the sprint length is not the answer. Break down stories into smaller, more manageable chunks, limit work in progress, and plan for less to be completed in the sprint.
The “Beginner’s Luck” Team is facing several issues including potentially taking on too much work in each sprint, the lack of regular product backlog refinement, the lack of an available Product Owner, and an general unwillingness to work as a Team. In order to succeed, the Team must address each of these issues.
In order to address the amount of work that the Team is taking on in each Sprint, the “Beginner’s Luck” Team should not extend its sprint duration. Instead, it should establish a “Definition of Done” or an explicit agreement regarding the level of quality that it will provide with each Sprint. Teams that are following Scrum should strive for a “potentially releasable product increment” but are encouraged to extend that definition as they evolve. For example, a team might initially state that its Definition of Done is that the code is complete. After a second sprint, they may extend this definition to include basic unit-testing. Establishing the Definition of Done will help the Team define what’s potentially shippable so that it can adjust the commitment that it makes at each Sprint Planning.
The Team may also benefit from planning technique called “Yesterday’s Weather”. Using this technique, “Beginner’s Luck” would only be able to commit to the number of points worth of work that it got to “Done” in the prior Sprint. For example, if the Team commits to 50 points worth of work but only gets 35 points to “Done” in its current sprint, it would only be allowed to commit to 35 points for its next Sprint.
“Beginner’s Luck” would also benefit from conducting regular Product Backlog refinement. While not a ceremony in Scrum, this activity is crucial to its successful execution. In refining the Product Backlog, the Development Team will be able to help the Product Owner break-down the Product Backlog items into “chunks” that are able to be completed within each Sprint. It will also allow the Development Team to communicate with the Product Owner about unknown aspects of each Product Backlog improving the Team’s shared understanding of the product that it is building. A business analyst skilled member of the Team can assist the Product Owner with this refinement as necessary.
Of course, having an available, knowledgeable and authoritative product owner is also crucial to a team’s success with Scrum. It’s clear that Sonny, the Product Owner for “Beginner’s Luck” is struggling with both availability and knowledge of the business domain. This issue is an impediment to the Team’s continued evolution and should be raised, in a transparent manner, to the appropriate people within the organization so that a Product Owner that has these attributes can be found and put in place.
Finally, and perhaps most importantly, the “Beginner’s Luck” Team needs to move from being a group – people who are asked to pursue a common goal to truly being a team – people who are willing to put their own specialty secondary to achieving that common goal. June is demonstrating the type of attitude necessary to make this transition. Suggestions to help make others on the Team understand why this mindset shift is necessary include team building, but more importantly consistent and constant reminders from the Team’s ScrumMaster that the users of the product do not value the individual specialties that comprise the Team but instead value the combination of those specialties that lead to a working product that people want to use.
While none of the responses to this blog addressed all of these elements, the one that best encompasses the spirit of my take on the case of “Beginner’s Luck: The Last Shot at BigShot?” is the one by Roi Lynn Munsey.
If you are interested in learning more about Agile or Scrum, please explore Watermark Learning’s offerings here: https://www.watermarklearning.com/courses/agile-training/
-Mike Stuedemann, PMP, PMI-ACP, CST