Team of Your Dream

This was a Q&A meeting with Sunil Mundra, the author of Enterprise Agility in Clubhouse. The interview was written with help of Ricardo Liberato, Ian Banner, Mats Kempe, Regina Novikova, Karthik.

Sunil Mundra is a Principal Consultant-Advisory at ThoughtWorks. He has extensive international experience in consulting with organizations in enhancing agility at team, program and enterprise levels. He has worked with senior executives to shape and execute the roadmap for change.

Books: Enterprise Agility: Being Agile in a Changing World

Ricardo: When you look at what is happening in the industry with everyone trying to push frameworks such as SAFe, Disciplined Agile, LESS etc... What is the role of these frameworks, and how can we use them effectively? Or should we take a step back and rethink this whole approach?

Sunil: Let me make a disclaimer first. I have no certifications, and I'm not an expert in any of the frameworks, although I know something about each of them.

When you look at implementing agility, implementing agile transformation or change as part of a program, you've got to tailor it to the context of the organization you work for. Yes, there are common patterns, common problems that organizations face. But just like every human body is different, although a doctor may find common patterns across people, you examine a body and make a treatment plan based on what you discovered about that person's problems.
And we need to take a similar approach in every organization and every single team. We have to look at it as an independent entity. And yes, while we can leverage patterns, the context of every single team and organization is different.

So, to cut a long story short, I think these frameworks are a set of tools. And as a coach or consultant, I refuse to tie myself to any particular framework. Depending on the problem to solve, I will pick and choose things from any of the frameworks that would best fit the situation. Perse, I think going in with the mindset that the X framework is applicable across all organizations is something that I am principally against. Because even if it may apply, would it be the best fit for that organization? Would a combination of different tools and different frameworks work better? I think that's what we need to think about. My bigger worry is that when somebody is looking at a framework, they're shutting their minds to other tools they could use rather than just pushing that one framework they know best.

Ian: But, isn't it better for a consultant to know one framework well? For example, if I take an analogy of house building, the carpenters know their carpentry tools well, and the plumbers know their plumbing tools well. I'm slightly concerned that people come in without knowing a framework well enough to think about implementing it correctly. What do you think?

Sunil: I agree with you. If we look at the basic concept, getting wide acceptance and having T-shaped skills, that applies to knowledge of the framework.

I noticed that you need not be an expert in any field. The problem is you blocking everything else beyond what you know. But as long as you're open to saying that this part of my framework that I know is perhaps not relevant in this context, maybe I need to look up something else.

We need to call in another expert who knows that framework better and see how we can collaborate. I have never come across an organization where, for example, a LESS expert and a SAFe expert have collaborated to make a transformation successful. Why can't we do that?


Mats: From my experience, I find a way to get into enterprise agility from two ends simultaneously. So, working with teams where we have sort of like a fire going and work with that, and at the same time, going from C- level and get some understanding and eventually get equilibrium. Do you have any sort of experiences from these dos and don'ts?

Sunil: Well, that's precisely the way that I would approach it. I think the needle has to first move on the leadership side.

I think in many places, teams are frustrated. They are working long hours. There are quality issues. They're not getting appreciation from the customers. And yet most teams, who are challenged like this, are looking for real hope, are looking for somebody to guide them with a different way of doing things.

When teams experience autonomy, they experience self-organization; they have a spring in their step. So, we need to start at the team level by doing agile, as we say it. We need to adopt the practices and processes and make that as part of the muscle memory because the ultimate goal is to change the mindset. But that doesn't happen unless you do things and you create some success stories around that.

So I'm a fan of implementing agile at the team level. But the point is that if you only stick to the team level and try to go up, what happened with that? At some point, you will hit the systemic issues, which are so strong, that whatever green shoots that you try to develop at the team level, that inertia will kill all those green shoots. You'll regress to level zero quickly if you do not make those changes at a systemic level at an enterprise level. So that's where I think you need to start at the leadership level to start looking at the mindset in terms of why they are doing it.

Many times, we see that leaders want everyone to change, but they are refusing themselves to change. They continue to measure people on the oral KPIs off. They reward people who sit most late in the office and those kinds of things. So we have to bring that change from both top-down and bottom-up. And from the top down, it just more at the mindset and the behaviour level. From bottom to top, it is more about adopting agile practices and making them as part of muscle memory and then creating a success story at a team level, at a product level, at an initiative level, which then creates that appetite for change at least in a part of the organization.

Ricardo: So if we do it from the top-down and the bottom-up, I usually find that we get the big obstacle that is frozen middle. Any reflections on that? What is the role of mid-management in all of this?

Sunil: Yes. It's a vital role. So, can you understand why this middle layer was created and what value-added to the whole process? I think you can't blame those people. The way the structures are created is classic Taylorism, where Frederick Taylor said that the thinkers and the doers should be separated. And if you honestly take a critical look at what middle managers do? What is the value that they are adding to the teams?

In many cases, this is highly questioned. Are they removing impediments? Are they grooming people? Are they sharing the vision? Many of them are just involved in passing information down and collecting data for preparing reports for their supervisors. That's all they do for about 50-60% of the time. And the other 40 -50% is spent preparing some detailed plans, which anyway, get outdated quickly.

So this middle management layer is really out of touch with reality sitting in their Gibbons and just looking at papers and Excel sheets and reports and secondary data most of the time, rather than being on the ground, being on the battlefield, spending time with people. So to me, this layer needs to be repurposed. These people's job in many organizations is to allocate tasks and to chase people. That's what happens in a command & control organization.

I think there's a massive element of coaching and mentoring that needs to happen at this level. These people need to get out of their cabins, go on the field, be with their teams, beat actual customers and use the power of influence they have given that they are higher in the hierarchy than the teams on the ground.

Give the teams what they need to. They need t to perform to the best of their abilities and remove impediments as the teams are facing. And I think that even if you get to convince senior leaders, and if you implement all the good agile practices at the team level if you do not transform this middle management layer or the frozen middle, this will derail your transformation for sure seriously.

Yeah, could it be why we transform the top layer because they start asking different questions from the middle management? So they have to start moving. Would that help?
That would help. But I think there's a lot of insecurity the middle managers would feel, and I think it doesn't lead you to.

Regina: What would be the ultimate mistake that you can give us as an example?

Sunil: For many years in the US, the organization's primary purpose was to maximize shareholder wealth. Organizations are now beginning to move forward from that. We need to treat the organization as a part of an overall ecosystem.

How can we have a bigger purpose than maximizing shareholder value? So, for real transformations to happen, we need to have changes on the board of directors. The mindset has to change from there.

The second point is disruptions. Look, today's disruptions are driven a lot by technology. But how often does technology get our representation at the C-level or even at the board level?
You'll never get an equal seat at the table from technology, at least until organizations recognize that. Today technology, regardless of industry or the domain technology, is your key differentiator, and you need to leverage the power of technology. I think that is very important with organizations that do not recognize that the ideal case would be to have technology representation at the board level itself.


Karthik: Some of the clients don't understand the transformation per se. And they end up hiring agile coaches to change the teams. How can we, agile coaches, enable the leaders?
How can we help leaders to enable them to understand the ground reality and bring them on board with transformation, and have their support?

Sunil: Okay, how do you make leaders aware of their realities? You need to start with why do they want to undergo this transformation? I think that has to become crystal clear. Is it because other companies are doing it? Is it because it's a buzzword, s a fashion statement that would be clear that we are also undergoing conservation? That's a reality in many companies, by the way.

The point is, do they have a choice not to change or then suddenly get disrupted when a crisis like COVID happens?. Imagine you're smoking 40 cigarettes a day, and you feel good, right? You're used to the nicotine, and you enjoy the smoke. But when somebody comes and tells you, stop it, please, smoking is known to cause cancer. There is enough evidence for us to suggest you that. But you say: no, no, I need this. I mean, I'll be fine. You know, I do all the exercises. I do my breathing, so I'll be okay. So, you don't want to change. And then when grade four cancer hits you, that's when you want to change. But it's a bit too late.

I think executives need to be presented with evidence. It's like a doctor presenting a report to you saying that your cholesterol is very high. You better believe in it if you don't want to. And this is the thing about Agile coaches. I look at us as doctors.
Any doctor can not guarantee a change in human beings' health. Even the world's best doctor cannot because the human body has its own life. The person has their mind, and the doctor may say anything, but the person may not decide to follow. So there is only so much we can do.

Karthik: how do you measure the performance of an agile coach?

Sunil: You can only measure what you have allowed the agile coach to influence upon. I'll give you an example of that. You want teamwork. And you want the team to work as a single team. But you have a classic bell curve where everybody's fighting for survival. Nobody wants to be in that bottom 10, 15%

So, what people do in this case? They either try to make somebody look bad so that they don't fall in that 15% or play up to their bosses, forgetting about the team. Everything is as long as I keep my boss happy, I am good. I will not be in that bottom part of the curve. How can an agile coach bring in team spirit? So you need to look at what are you able to influence? Within the things that you can influence, your performance should be measured.

So the other part is about educating the leaders, presenting them with evidence and making them realize that the cost of change of not changing rather can be very severe on them where the survival of the enterprise can be threatened and cause a problem with them. But that's easier to say than do.

Consider this scenario: You have just been elevated to the role of Scrum Master. Previously, you may have held a role with less responsibility, or perhaps you are a newcomer to the organization. Or, you may even be new to this field entirely. Whichever the case, you understand that you need to develop proficiency and become a contributing member ASAP.

Having a plan in place to make the learning curve less steep would ensure a smooth, rapid transition into your new role. Where do we begin? What would your first week look like?

Yesterday, we facilitated a Clubhouse discussion during which Agile professionals shared their accumulated wisdom. These are a few nuggets of wisdom I gleaned during the discussion.

The content can be divided into three main parts:

1. Who are the people involved in this journey? Who are your team members? Who are your stakeholders?

The very first step in your journey as a scrum master is to gain the trust and respect of your teammates. This applies regardless of whether you are a rookie or a seasoned veteran.

There are a variety of methods you can employ to accomplish this:

• One-on-one interviews with each team member to learn about one another’s experiences, expectations and motivations. Questions should include: How can you help one another? What are the pain points of your team? What are their goals, fears and concerns? How familiar are they with Agile? What are their expectations for the leadership, the vision and direction? Asking these questions will help establish a good rapport with your team.
• Go out with the whole team if you are co-located, and participate in team-building exercises to develop trust and mutual reliance
• Participate in a workshop with the team to better understand how they see your role and manage the expectations they have of you. This is a good opportunity to ask the team how you can serve them better
• Have a one-on-one with the Product Owner. As Scrum Master, it is imperative you understand that person’s vision, and the amount of influence they wield in the team

As well, you must understand the dynamics of the team you are now embedded in. How smoothly does communication flow within the team? Who is their official leader? Is there a de facto leader that is not the same as the formal leader, and is there a leadership clash between them? Who is the driving force behind current events? Who has good attendance and who has poor attendance at meetings? How comfortable does the team feel with external stakeholders?

You can achieve this by observing your team and main stakeholders during the meetings.

A TIP:

Just keep in mind that if you simply observe for too long, the team might not see the value you bring and you thus risk losing their trust and respect. So be forthright and share with your team members and main stakeholders what you observed and your strategy for improvement derived from your observations.

2. How is the overall organizational culture? What is the background of your project and product? What is the background of your team?

Beginning a new role is always fraught with challenges since you need to have a clear context of what happened prior to joining this organization, team or project. You need to answer: were lessons learned actually implemented? Is there a confluence page or tool to track the team’s progress and document lessons learned? What is the Agile journey for your team or organization?

The best way to gather answers for the above questions is again to set up one-on-one interviews.

A TIP:

Ensure that people understand the purpose of these one-on-one sessions. If this is an informal chat, it is better to make it known in advance so people will come relaxed and not hesitate in sharing candid information. If you want to ask questions about the organization’s background and current state, be clear with interviewees in advance. You are still unfamiliar with one another, so some might feel self-conscious about their recent work and may feel more comfortable with preparing answers in advance. After rapport is established, people may feel more open and relaxed during such conversations, but this will come only after the first 2-3 one-on-ones.

3. What is the current state of the project/product?

In addition to understanding people and organizational culture, new Scrum Masters also need to understand the project thoroughly, in addition to team dynamics, practices and processes.

There is a short checklist we can follow to gather some information:

• What is the team producing?
• Who is the customer?
• How is the team implementing the plan?
• Are team members working on one product or on several products?
• What is the end-to-end process?

One-on-one meetings will be helpful again in your journey of discovering the answers to the questions above.

Other tips for you during your first week:

1. If many teams follow Agile practices in the organization, discover which team performs best and which one performs worst. After determining this, try a head-to-head comparison of what the best performing and worst-performing teams do and don’t do.
2. Even if you disagree with the current approach, step back and try to understand the reasoning behind the current processes or practices being followed.
3. Don't manipulate your team's opinion. Step back and let them figure out the solution even if you disagree with it. Discover the team's logic first.

Finally, if you are a brand new Scrum Master, join a community of peers for mutual advice, support and practice. For example, PMI. There are a lot of good resources to be found there.

I hope these findings were helpful and feel free to comment with your ideas or thoughts about this summary.