As promised, I’ll now address two areas that I believe provide challenges for an organization in its early stage of Agile Transformation; even before an enterprise Agile framework is taken into consideration. Listed below are two of the most challenging areas, symptoms and possible treatments for some of those symptoms. Each one of these could become a discussion of their own, but my goal is to give the people in the early stages of Agile Transformation some items to look for and address. I hope it achieves that purpose for you.
Challenge Area 1 – Mastering Scrum Roles, Artifacts and Activities
- Product Owner (PO) suggesting or assigning tasks to team members
- PO anchoring and/or influencing team task estimates
- PO working on other activities (probably related to previous job position duties) to the detriment of backlog completeness
- Product backlog items (PBIs) are not ready for planning
- Backlog Grooming/Refinement is not taking place
- Scrum Master (SM) driving decisions instead of asking questions to lead the team to their own conclusions
- Scrum Master allows stand up to have extensive conversations outside of the three questions
- Team members speak directly to the Scrum Master as they answer their three questions during daily stand ups when they should be speaking to the whole team
- Team members disengaged at Sprint Planning and Refinement (ex: open laptops, not contributing)
- Retrospective is a “complain-fest”
- Team members accepting work from someone other than the PO
- None of the identified Retrospective improvement Items are actively worked and remediated in subsequent sprints
- Sprints have too long of a time box eliminating urgency
In many organizations as they start their Agile Transformation the product owner and scrum master roles are filled by project managers and managers. They sometimes can have minimal experience and education about their new role and fall back on previous command and control practices. The team may also already be accustom to taking direction from them and everyone easily falls into the old command and control relationship.
If you have a Guiding Agile Partner (strongly recommended) then they should be providing education and direction to individuals and to the group as a whole in a “just in time” (JIT) fashion to correct these situations. Scrum Masters/Agile Coaches can also provide this direction as they mature in their role. You can also visibly display Agile definitions, statements, etc. on posters or signs related to your more stingy pain points.
Keeping the product backlog in the proper state is the most important activity for the PO. The PBIs must be prioritized and in the “ready state” before planning or you greatly risk sprint success (see appendix below for definition of ready). If the PO is too involved in carrying out work related to their previous role (ex: support or troubleshooting) then it will affect backlog quality. A cross-training PBI to ramp up a team member and allow the PO to shed their old responsibilities is not out of the question.
It is important that the SM is a servant leader. They should concentrate on creating a successful process and removing impediments. They need to ask the right questions and foster participation from all team members. If team members are only making eye contact with the SM during the daily scrum then this indicates that they feel the daily scrum is a status report for the SM. The SM needs to remind the team that the daily scrum is not a status report and is meant to share and discover information across the team. A trick to facilitate the correct mind set here is to let a different team member facilitate the daily scrum each day. The SM cannot allow team members to enter into long discussions during stand up. I recommend having a parking lot where you list any items needing longer discussions along with a list of the team members to be involved. After your daily scrum you can choose to discuss them or schedule a separate time to address. Your daily scrum should not be more than around 15 minutes. A cute trick that I learned from a consultancy (AgileThought) and that I use to identify the end of the stand up is to announce “Daily Scrum Dot Done” (DailyScrum.done). This provides a clear end point so the team clearly knows when they can leave or pick up larger discussions.
Everyone has been involved in a lessons learned, post postmortems or retrospectives. How many of you have spent time collecting feedback only to never act on remediation? At the end of your retrospective you can have the team “dot vote” and make sure to include prioritized remediation as part of the next or subsequent sprint. The Retrospective is a waste of time if you don’t act on the identified items. The SM needs to develop techniques to gain full team participation and uncover important items that need improvement. There is a lot of information out there on different ways to conduct retrospectives and keep them fresh.
Team members cannot accept work from anyone other than the PO. Listen carefully as you conduct daily stand ups that no team member is working on a task outside of the sprint and the PO’s knowledge. Nicely call them out if it is the case.
When it comes to the length of your sprint, I would always recommend that in the beginning you don’t go beyond 2 weeks. This is purely subjective, but I feel that especially in the beginning of your Agile Transformation it will provide you with a heightened sense of urgency for delivery and provide ample time between retrospectives so you don’t move in the wrong direction too long before correction. If 2 weeks doesn’t work for you then you can adapt and change it.
Challenge Area 2 – Dependencies Within and Across Teams
- Unable to start prioritized task within current sprint because limited knowledgeable resource is busy on another task
- Unfinished Product Backlog Items (PBIs) at end of sprint
- Time spent waiting on other teams in a current active sprint
In the beginning of your Agile Transformation you have done your best to assign individuals in to cohesive, empowered and self-organizing teams encompassing representation across all of your business areas. An optimal scrum team has all the needed knowledge and skill sets available within each of their team members so that they may successfully complete their PBIs and provide value to the business every sprint. This is referred to as being “T-Shaped”. If all of your team members are “T-Shaped” then you have less likelihood of bottlenecks and wasted time. If everyone is not “T-Shaped” you can estimate the effort to become “T-Shaped” and construct a plan towards this end while minimally sacrificing the delivery of value to the business. Obviously, you always need to weigh the time burned to do so vs. the gains produced.
You can accomplish tasks and PBIs more quickly if you do not have to go outside of your individual scrum team. You aspire to this model, however, it is improbable that you will never have to do so. Before your Agile Transformation you most likely had some silo groups such as database, middleware integration, etc. You have an issue to address if you don’t have enough people to include at least one of those individuals on each team or if the code is not loosely coupled enabling multiple people to easily work on it simultaneously. Even though you are not yet ready to adopt an Agile enterprise framework, you may be forced to create a separate team that will field all the other scrum teams’ requests for this skill set area. I recommend you only do this when absolutely necessary because you can very easily abuse this action and end up right back where you started with silo skillset groups.
In some cases, you require dependencies on other teams. Since you haven’t scaled yet, you will need to have a Product Owner collaboration session on a regular basis so communications are open and prioritization across teams can initially occur until you adopt an enterprise agile framework (some may say a Scrum of Scrums, SAFe, LeSS, Nexus, Program Team, etc. – but again we are not scaling yet). My recommendation is to create your PBIs such that they never depend on another team in order to complete the PBI. If you have a PBI that depends on another team for completion then separate each set of tasks out into their own PBI with the dependency falling in the middle of the two PBIs. This is not a published practice and other Agilists may have theoretical objections, but it works for me, resulting in less unfinished PBIs and a cleaner more transparent demarcation of dependencies.
In conclusion, I hope this discussion will alert you towards earlier recognition and remediation of some of the more common challenges during the early period of your Agile Transformation.
“Discussion Dot Done” (Discussion.done)! 🙂
Appendix: PBI “definition of ready” from the book Essential Scrum by Ken Rubin.