The work of an Agile Coach is very versatile. Agile transformations are as well.
Each team has its own fingerprint and organizations are one of a kind. This is what makes our work so interesting. One of the challenges of an Agile coach is to stay objective and keep one eye on the horizon. As you become a part of the system you get involved in many initiatives. Some of them can be categorized as “seizing the opportunity for a great intervention” and “being adaptive”. Necessary since a transformation can’t be fully planned in advance. Some initiatives satisfy a need in the organization. They may seem like good changes to make an impact, but in fact, they distract you from the path that forms the Agile journey. The 16 tips that I collected in this article can be read as individual tips. When looked at them holistically they serve as a checklist that can be used to get and stay on the path. When I reviewed them, it triggered some critical thoughts. I had to conclude that, although I wrote the tips myself, I did not give some of them that much attention lately. I probably got distracted, while trying to make an impact. I will use the tips to stay on course and hope they will benefit you in the same way.
Tip 1: Have your Scrum roles clearly defined
Many Agile teams and organizations are struggling with executing the various roles in an appropriate way. Scrum Masters that book the meeting` rooms but fail to challenge the team. IT managers control the team rather than facilitating them. Product owners who lack the power to really own their product and say no to demanding stakeholders. The examples are countless. Try to get the roles clear — it will oil the machine, trigger improvements, and provide handhelds for personal coaching. You can use the table in the article I wrote as a starting point for dialogue, see Role agreement in scaled multiple team organizations.
Tip 2: Be aware of “add-ons” that increase complexity and mask deficiencies in the system
The Agile Principles urge to maximize the amount of work not done. Agile likes to keep things simple. Still, many teams are really creative in defining extra processes and solutions when encountering a problem. Recently I spoke with a manager who created a special bug fix team. The teams had complained that their sprint goal was challenged by incidents, while in fact, the organization was suffering a quality problem. They solved it by creating an extra team that would do all the bug-fixing. This way the other teams could continue their sprint without too many disruptions. It may seem like an effective solution, but it makes the organization more complex without solving the root cause.
Tip 3: Be clear about what behavior you expect, but also about the behavior you do not want to see any more
When you are in a change process, it is important to explain what you expect from your colleagues. It is very straightforward to explain to them what you want them to do. However, things become more clear when you also address behavior that you no longer want to see. The impact of the change will be better understood and although this may lead to some resistance, it will help you to get people into the change mode. E.g., You suggest that we make quality a collective team responsibility. You probably get positive nods when proposing to collaborate on the testing. But you will get a more sincere reaction when you explain that you no longer want developers to pick up new items when there are undone stories on the board that need testing.
Tip 4: Let the team decide what and how they want to improve
Make sure the team understands Agile and give them the lead in the continuous improvements. Avoid making the team feel that they need to improve for someone else. I think Agile coaches sometimes feel they need to prove their worthy by making progress and proving that the teams grow in maturity. e.g., by having a higher score on the Agile Maturity Model. As a result, they make improvements a coach thing. This way they put a pressure on the team and ignore their real needs.
Tip 5: Be aware that the challenges you’ll need to pay attention to shift over time
Organizations that start with Agile often have a strong focus on the teams. When the individual teams hit their stride, the focus shifts to the way the teams collaborate. Organizations increasingly start to understand that business Agility and responsiveness are key to surviving and staying ahead of the competition. In order to yield value, the work of single scrum teams should, therefore, be integrated and embedded in larger business processes. In the second wave of adoption, the single team focus shifts to a wider organizational approach and teams initialize cross-team collaboration with a focus on continuous delivery. Once teams have learned to plan and launch collectively built releases, the focus shifts from realizing technical products to business delivery. In the 3rd wave of adoption, the performance dialogue will transition from a release focus to a focus on business impact. From this, we can learn that as organizations continue on their Agile journey, their Agile challenges shift. So does the role of the Agile coach. We should develop ourselves to be able to support the people we work with. See the 3-wave model.
Tip 6: Remember things are like they are for a reason
When entering a new organization or engaging with a new team, I am often surprised by what I see. There are often flaws in the way of working and sometimes I see things that are not in line with the Agile textbook or mindset. I trust you experience the same. But do not judge, there is most likely a valid reason for things to be like they are. Learn to understand them before you make improvements.
Tip 7: Spent time on training
Do not assume everyone is fully trained. Do not overestimate the Agile knowledge team members have. Their work is developing, not Agile, so they are less focused on Agile training and knowledge than we are. I have given training to experienced Agile developers who didn’t know the Agile Manifesto. I have met colleagues that just started as a product owner or Scrum Master, without getting proper training. Be aware that although the organization might have started a transition with training everyone, but some people stepped in later and might not have had the same introduction. Good training and workshops help the teams understand what is expected from them.
Tip 8: Ensure features can be completed within, e.g., a quarter
I had a discussion with my fellow Agile coaches about this one. What we agreed on was that features (or Epics) should be small in size so they can be completed during a sprint and progress is evident and clear. We had some disagreement on whether we should put a time restraint on them. I am a fan of stating that, as a rule of thumb, they should be completed in the quarter. But I agree that the rule should not lead away from the understanding of why it is important. I have been in organizations that were “working on items” rather than “completing items”. One of the product owners explained why:” We’ll never finish these features this period, because they are too much work.” Since the only progress is measured by completed features the Agile manifesto says, to ensure that your features are of a workable size.
Tip 9: Have a discussion about what quality is and how it can be achieved
Within Agile, quality is non-negotiable. Everything we finish should be of sufficient quality. But how do we build quality? We can test a lot, but we’ll be far more effective if we design our feedback loops in the development lifecycle. In order to do so, we should understand when and how errors can be detected and agree on what we do when quality is insufficient. I hear a lot about shift-left and test automation, great. Additionally, I believe that many organizations will benefit from having mature dialogues about Built-in Quality feedback loops. If you want to learn more, watch the BIQ story: Built-in Quality a multi-level challenge.
Tip 10: Do not discuss scaling frameworks if teams are not collaborating on the same product anyway
I see organizations that have a discussion about whether they need to do SAFe, Less, or Nexus to advance their real needs. When teams are not yet collaborating on the same product, maybe you do not need a scaling framework yet. Focus on the delivery flow and optimize the collaboration between the teams. The discussion about scaling will follow eventually.
Tip 11: Draw out the customer journey and value flow.
System and component teams are omnipresent in many organizations. This leads to inter-team dependencies and makes the value of a completed user story diffuse. Sometimes it is low because the completed item does not stand on its own. No wonder that, in these cases, the discussions on value are abstract and not understood. Organize a session to define the customer journey and draw value stream maps. This will yield great insight into what value you deliver and where your bottlenecks are.
Tip 12: Discuss IT practices like CI/CD and Test automation
Test automation and continuous integration/continuous delivery are industry practices that we all should adhere to. Many organizations still struggle with automating their tests. Manual testing and deployments take up a lot of valuable time and are error-prone. They’ll distract the organization from focusing on value delivery. So, raise the topic and address the need to invest in these practices.
Tip 13: Spend time on ‘fun’ sessions, especially when working in a distributed team and when working from home
This year we all have been working from home a lot. Many teams that I work with miss the social interaction. I notice a growing need to do something informal and engaging with fellow team members. Help the team to have free time and have these sessions. Preferably they organize it themselves, but as an Agile coach, you can help by creating awareness, raising the topic to identify the need, and suggesting work forms. You can do a Two Truths and a Lie session, an online Pictionary, or meet in an online escape room. There are many options.
Tip 14: Balance your distributed teams
Have an eye for balance within your distributed teams. Are you aware of the composition of your distributed teams? Are both the onshore and the offshore teams able to operate independently? Maybe skills are not distributed evenly. E.g., when all testers or BAs are on one side. Be aware that when the power balance is uneven, cultural aspects might become a factor. I was working with a team where the PO, the Business, and the BA were all in the onshore team. The testers never attended a review session and were just testing what was thrown over the wall. They humbly accepted the situation but were not really involved with the team. Be aware and raise the topic. Distributed teams should be balanced in order to become a team.
Tip 15: Address problems to the leadership
When your organization has been doing Agile for some time now and you are asked to help the teams, that is quite rewarding. But before you get all hooked up and busy, try to consider the whole system. Why isn’t the team performing like it should? Are there patterns in which leadership plays an important part? Rather than trying to fix holes and compensate for problems locally that originate elsewhere, it might be effective to sit with the leadership team and collaboratively discover what their role is in creating the problems and what they can do to eliminate some of the root causes.
Tip 16: Have an eye for the good things around you as well
Be critical of the way things are and always have an eye for potential improvements. But have a keen eye also for the things that you have and that are good. Share these with the people around you and be aware that although things could be better, a lot of things actually are good. That holds for your team and for sure a lot of good stuff is happening in your organization as well. Be proud of that.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
