Scaling Agile: Organizational Issues, Tools and Techniques
Scaling agile is a hot topic. You can see just by searching it on google or bing. A lot of material regarding tools, processes, and techniques are being published every day. But I also see that “organizational management” (from an agile perspective) is not. And I believe it should be if we are really serious about scaling.
The Problem
As your product grows in complexity and coverage, your organization grows, and more people start to collaborate on your project or product, you need new tools to cope with the growing environmental complexity.
Nowadays, Scrum has finally gone mainstream, and now we can see a lot of people using scaled Scrum frameworks (like LeSS, Nexus, Scrum of Scrum, Scaled Scrum, or even SAFe). But even though you are using or not such frameworks, you still face various challenges these frameworks simply don’t address properly.
Organizational Analysis
Organization Analysis is the “practice” of understanding your organisation in a much broader level. Much of the problems agile teams faces are inherently connected to the company organisational structure they are in.
If your company is strongly project-based, you will face very different problems than a team in a purely functional-based structured. In my experience that are some questions you can use to enhance your awareness in this regard.
- How is your company (or business unit) organized? Project-based? Functional-based? Matrix-based?
- Is there a structured "Product" area? Or is not that structured, being spread throughout the company?
- All the product areas share the same standard, policies, and procedures? Or they have full autonomy to change what they want to?
- Is the "Product" area really product-focused? Or instead is a project management organization incorporating some (or few — sometimes) product management practices?
- Is the product team really a product team? Or most of them are former business analysts in charge of business requirements, feature decomposition and prioritization?
- How is the company culture? It's a hero-based culture or a real team-build culture?
- How agile and lean is the product culture? It's all about looking agile or are they are all in about being and living the agile values and principles?
This questions will help you elicit your company culture and organizational strengths and weaknesses (the real ones, not the stated ones), also indicating which battles are worth to fight for and which ones you are simply doomed to lose, due to organization and culture (mis)fit.
There is also a very important question, regarding the power dynamics within company units and departments. What do I mean by that? Some companies are heavily sales-oriented, other are engineering-oriented, tech-oriented, or even design-oriented. And the sooner you check what is your company orientation, the easier it will be for you to understand why the things are the way they are, and the easier it will be to you to jump in our next topic: stakeholder management.
Stakeholder Management
The first time I was introduced to stakeholder management was at my PMP prep study, back in 2001. And those learnings have been critical to my success (first as a Project Manager — 2000 / 2007, and then as Agile Coach — since 2008).
First of all, what is a stakeholder in the agile context? Well, in my perspective, a stakeholder is everyone that the PO (primarily) and the rest of the team must align anything with. So the “align” here is instrumental in mapping everybody that somehow play a role (any role) in your product/project initiative. And that is the very first step: to map and to understand your audience.
You can use a 2x2 matrix to classify your stakeholders. In one axis you can plot how aligned with your project/product your stakeholders are. In another axis you plot how much influence each stakeholder exerts in the decision making process of your product/project.
The most dangerous stakeholders are the ones that exert a lot of influence but are very much against your initiative. On the other hand, the most beneficial stakeholders are the ones aligned and very influential. These 2 extremes need careful attention, since the first one can easily derail your project, and the other can easily help you succeed.
In the first case, you need to actively manage the stakeholder in an attempt to minimize the influence (isolating the stakeholder and active negotiating with her). In the second case, you need to actively help the stakeholder to be the "higher" voice in the org-chart in favor of your product.
What about the others? Well, the others stakeholder you still need to manage, mainly the ones with some power to influence your product, but since their power are also limited, you can dose your energy when managing them. The ones with no power to influence, are the ones that need less attention of you. A good practice is to help the ones properly aligned so they can become your product evangelist or even your allegiance-network.
In any case, my point is basically that you need to know your stakeholders so you can properly manage them. And the best you manage them, the easier your path to success will become.
Some classical strategies for each group might include:
- Hell Group: Isolation.
- Noisy: Isolation and negotiation.
- Misunderstandings: Training, context, dissolving information asymmetries, and focus awareness.
Most of the time, managing stakeholders is closely related to managing their expectations, fears and (mis)conceptions about your product/project. So managing people expectations play a critical role in this endeavor.
Managing People Expectations
Managing people expectation sometimes can be very difficult. First of all, you need real empathy to wear other people shoes. You also need to develop a lot of soft-skills, mostly related to active listening, empathy, and "careful-speaking".
You need to listen to what people are saying, thinking and feeling, using different tools and techniques. You need to be welcoming, open-minded and sensible to people worries and traumas. Then you need empathy to be able to reflect on how you could dissolve unreal worries, help to solve the real problems, and somehow fix what can be fixed. Sometimes the worries and confusion can't be fixed, but you can try to get more order in place (or at least, diminish the chaos and confusion).
And then you have the real problems to work on. For those ones, you need to pay extra attention to how you frame both the problem and the solution, as well as how you talk it through with the stakeholders. Regardless of the message, you can always use gentle wording, be kind and take into account people feelings in the process.
And, to finish this topic, I must warn you: as your organization, project/product, and context scales, sooner or later you will find yourself moving (sometimes) powerful people out of their comfort zones. And in this specific case, these stakeholders may use every single power they have to sabotage your product or project. Sometimes they are not "against" you, but just don't believe your product/project benefit them.
So keep in mind that stakeholder management, despite being almost an invisible work, is indeed a very demanding and energy-consuming one. If you want a deeper dive in this subject, there is a lot of literature on this on google, and there is a very good course on this subject at Coursera.
So, by now, you already aware of your audience; understands what your stakeholders want (or don't want), and have already developed a plan to manage them. So you need to communicate with them.
Managing Communications Channels and Communication Processes
Communication is a very undervalued topic. But in my experience, a good communication is critical for your project/product to succeed. And when I talk about communication I do it in the broader sense of the term.
Most of the PO (or PO-like) job is related to communication. Communication must flow inside the team, and as the efforts scales, it must also fluidly flows outside the team.
Keep in mind that different people need different information and in different timelines. And most of the time, it is just not feasible to put "everybody together in the Scrum-Review" (or any agile ceremony for this purpose). Some people need high-level info, others need very detailed and low-level product info. Some just need to be informed about product advancements. Some will need to be consulted in some technical/legal aspects before you move forward.
Again, this is easily accomplished when you have about 2 ou 3 teams of 5–7 people each, but when your product grows to 10–20 teams of 5–8 people each, involving other teams (marketing, legal, finance, operations, sales, and so forth), this becomes a real challenge.
There are some tools one can use the help in this matter. I've successfully used the RACI matrix and specific mailing-lists/wikis for this.
The RACI Matrix is a very well known project tool that maps all the key aspects of your project/product to the respective stakeholders, helping everybody to see the level of commitment/involvement of the stakeholder on the respective deliverable. As the name says, we have 4 levels of involvement:
- R: Responsible for the deliverable
- A: Accountable for the deliverable
- C: Must be consulted about the decisions being made
- I: Must be involved in the decisions being made.
In a project context, the RACI matrix looks like the below:
One can freely adapt this template to one's own reality.
Other tools may be used as well. As I told before, I have used also Wikis, Email-lists and electronic Chat/messages boards for this purpose.
Just to illustrate, at one of the companies I worked, we need to communicate every UI/UX design and API "breaking" changes to different groups within the organization (which were spread out in different locations and countries). So we put in place a very simple email list in which the engineering teams were responsible for announcing any UX/UI design or API changes at the moment they recognize the need for change (breaking the old behavior — that's why we used 'breaking-change' title). At another company, our product owners kept everything organized in the product wiki, which was available for the whole company.
I've seen people using Slack, Skype, Facebook Messenger, and WhatsApp groups for this kind of promptly communication as well. My sole recommendation is to keep it as simples as possible.
Another important point is to tailor-made the information being transmitted to the best usage by the audience. Some audiences will need elaborated graphs, another will prefer just plain language e-mails. So, remember to also keep this in mind.
Getting everyone aligned
The next step that needs attention is the alignment step. If people inside and outside the product team are not properly aligned, your chances of success drop substantially.
Fortunately for this, you have different methodologies and frameworks at your disposal to use. Just to name a few:
- OKRs
- #Now, #Next, #Later
- MOSCoW
- PMO-like
- 4DX (4 Disciplines of Execution)
Most of this methodologies/disciplines will help you way beyond the alignment stage, through the execution stage. And I strongly recommend the use of any one of this. They serve different purposes and can be very effective. It almost impossible you don't have any fit at least with one of them.
#now, #next, #later and MOSCow are not alignment frameworks per-si but may be easily adaptable to this purpose.
Personally, I believe OKRs is the one that best fits the agile mindset. It's simple, flexible, and strongly focus on the outcomes to be achieved.
Conclusion
One of my points in this post, is that although you have a lot "scaled frameworks for agile" (Nexus, LeSS, SAFe, Scrum@Scale, Scrum-Of-Scrum, and the like), most of the time there are a lot of issues surrounding the tech/product team that also needs to be managed and properly addressed in order of your agile practice scales properly and smoothly.
Here I covered some of these aspects, mostly related to the organization (or company-wide) side of the scaling.
Another point concerns the tools and techniques that can help in succeeding at these challenges. Some (actually the majority of) tools and techniques (at the least the ones I mentioned) are rooted in other frameworks (agile or not — most of the time, not agile at all), but nonetheless may be extremely useful to product teams. This tools enables the team to properly manage the scaling complexity of scaled efforts. About this point, I would strongly recommend keeping your bias and prejudice at bay, and looking at the tools and techniques as they are: simply tools and techniques for your team to use.
Last but not least, keep in mind that scaling means that a lot of things that used to work in a small team environment, will break. And while you keep scaling, this "breaking" will be your new status quo (things that works with 10 people, will break with 40; the ones which work for 40 people-teams, most probably will break with 100 people, and so forth).
Good luck!
