Three Agile and Scrum questions from a reader

Three Agile and Scrum questions from a reader

Delivering work using Agile practices can be tough because work environments vary and different organisations throw different kinds of challenges on us. I often receive questions from readers about agile delivery practices. What I have been observing for a while is that the questions mostly relate to dealing with people. As Jerry Weinberg said through his Second Law of Consulting, “No matter how it looks at first, it’s always a people problem.”

This post answers some of the common questions that I recently received from one of my contacts. I have made some minor edits to make the questions generic. 

Coaching teams and organisations

Question 1. How should I as a Scrum master go about coaching the organisation about Agile. I come from a consulting background and coaching is usually limited to the Scrum team that I work for. Are there any techniques that can help me coach organisations or stakeholders?    

Answer: As a Scrum master, oftentimes you will only work with a couple of teams. Coaching one or two teams is easier, manageable and more convenient. However, there’s no optimum number of teams that a Scrum master can work with. Although it might appear useful that a Scrum master should only work with one team, a lot depends on the nature of the work the teams are doing, their maturity in terms of the agility, the complexity of the work, the structure, size and the culture of the organisation etc. 

One thing is sure that as a Scrum master, an organisation wouldn’t want you to be spread too thin. In his book Secrets of Consulting, Jerry Weinberg offered us his Law of Raspberry Jam, “The wider you spread it, the thinner it gets.” And, as you may know, good jam has lumps. I think a thinner jam loses taste too. In our terms, that’d be losing focus or interest.

Now coming back to your question of coaching the organisation. It pays to confirm what someone means by coaching. People often confuse training and coaching. Let’s assume that they want you to coach the organisation on using Agile practices. How would you do that? Of course you will understand their context, the training and skill gaps, and possibly the problems they want to solve through coaching. Accordingly you will find the things that will offer you few quick wins and time to find a long term solution.

Techniques of coaching depend on who you’ll deal or work with. I often mix things to make them accessible and practical. For example, I’ve organised brown bag sessions, arranged team surveys to find out what they want to learn, scheduled coaching sessions with other Scrum events so that teams don’t use the sprint time for training, coached teams by organising team contests etc. My experience is that given sufficient notice, stakeholders enjoy taking part in contests or challenges.

 

Getting pushed back on Agile Delivery

Question: Many times I get to deal with Clients who have low agile maturity. Either at the team level, or at the stakeholder level. I get pushed back on Agile process delivery as this would disrupt their business. In such a scenario, I initially did an Agile/Scrum 101 training. Talked about my successful experiences from the past with successful Agile delivery. However, I still felt that the clients or teams were not convinced. How should I have approached this as SM differently to get the stakeholders or team to buy into Agile ways of working?

Answer: That’s a good question and many Scrum masters, Agile coaches and delivery managers experience similar challenges.

First thing that we should understand is that Agile itself is not the goal. Even though some organisations might say that they want to be Agile, their main objective is possibly to solve some other problem through applying Agile methods or the mindset.

What often seems to happen is that when given a responsibility, many Agilists blindly start applying frameworks, tools or methods. This results in pushback from teams as well as stakeholders. (You might want to watch this video about tools and frameworks). Agile is about change and we know that people don’t like change because change is hard. (But remember that change is not always resisted. Having new born babies brings a huge change in people’s life, but almost everyone enjoys that even though it turns their lives upside down, at least for a while.)

Your clients must have hired you for a specific reason or reasons. They wanted you to solve some problem for them. Understanding their problems, their context and what bothers them builds your own confidence in the problem solving process and also instills confidence in the client. Running Agile 101 is the easy part. Knowing whether that is required, is the hard part.

Old School Product Owner?

Question: I had a tough PO who needed all requirements into the project delivery roadmap. What would be the best way to convince a PO that we cannot have all the features in the product roadmap and can only accommodate a MVP approach ensuring we can only focus on features that can be developed in a given period of time.  

Answer: It appears to me that your PO was not trained in product ownership and was only carrying the PO label. You might want to show them this video from my talk at the Agile POs and BAs meetup. In this talk I explained what product ownership is and how the prioritisation works. I’ve heard that many people found it useful. 

Although things have slightly changed since Henrik Kniberg wrote about MVP, sometimes I still use the sketch that he created to explain the idea.

You may also want to make sure that the POs you work with get training in product ownership and understand that their job is not to manage people, but to work with them for frequent delivery of valuable outcomes. You can do that by building a trusted relationship with them. Think about getting into a social contract with them.

Side note: there is no single ‘best way’ for almost anything, but there are always many good ways. ‘Best’ expresses ‘the only way’, while there can be more than one way of achieving our goals.

So, these were my responses to the questions. What else would you add to these answers? Would you answer these questions in a different way or would you give a completely different answer? Let me know.

Follow here
Biases, mindset and tools

Biases, mindset and tools

Few recent conversations made me think about the approaches and tools that we choose for delivering valuable work. Many people rely solely on tools that they’ve always been using. They never change their ways of working. Or, they may change the labels, but not the actual approach.

This is the snippet from the first conversation:

One of my ex-colleagues mentioned that his primary stakeholder, who happens to be the executive of the department, told him not to bother her about the process and frameworks he was using. She hated any mention of Agile, Kanban or Jira. She needed detailed plans, roadmaps and estimates and believed that other approaches didn’t work.

Why was that? 

The other conversation happened during a recent event. A participating senior manager of a large organisation was concerned that stakeholders don’t understand iterative approaches. He wanted to collect and use more data points to prove that work was happening. My personal observation was that his team and he himself lacked an iterative delivery mindset.  Was his approach to rely on data right?

What seems to be the problem? 

“Elementary, dear Watson!” (Actually, Sherlock Holmes never said those words in any of the stories. At least I didn’t come across those words. I have read Sherlock Holmes more than once, I enjoy that so much.)

These conversations remind me of a few cognitive biases. Primarily of the curse of knowledge bias and Dunning-Kruger Effect.

It might be true in both cases that one party thinks that the other one knew more than they actually did. My colleague possibly was talking in a jargon laden language that the business executive didn’t understand and decided that it was all nonsense. All the while the ex-colleague assumed that she being an executive knew more about what he was talking about. That’s the curse of knowledge. 

It is also possible that the same executive believed that she knew more about all delivery approaches. And the ones she actually knew more about, were the better ones, because she knew more about them (sounds dumb, but that happens). That assumption by her makes the other ones bad automatically, at least for her.  

That’s the Dunning-Kruger Effect.

The third point I want to make is not about bias, but about data. 

Data is ruining everything.

Well, not really. We rely on data for decision making. However, over-reliance on anything is bad, isn’t it? I must remind you of the Challenger catastrophe if you disagree with my assertion. You can read about that here. If you read the report, pay special attention to Richard Feynman’s observations and findings. Every word there is insightful.

In a nutshell, what happened then was that NASA wanted to make decisions purely on data, while an engineer had a gut feeling that there was something not right with the O-ring (type of a valve that stopped gases from leaking from the spaceship). That engineer didn’t have data to prove, only a strong gut feeling. 

We all know about the disaster where few astronauts sadly lost their lives.

The CTO in our scenario is focusing on data. It has been proven many times either through research, or in real life, that statistics often fails to influence us compared to social proof. 

Not convinced? 

Think how many times you have made decisions based on a friend’s advice. We approach our family or friends and read online reviews when we buy cars, houses, electronic equipment and other stuff. We look for social proof there.

So, I’m not surprised that by offering data to executives, this person is hardly making a difference.

What else is happening?

What do you think is happening in these scenarios? I’m looking for more insights before we jump into potential solutions.

Let me know either by commenting or emailing. 

Follow here
How do you improve collaboration when everyone is remote

How do you improve collaboration when everyone is remote

Building trust, enhancing collaboration and establishing relationships is hard enough when teams work together in a physical office. Things become more challenging when teams are distributed. This issue doesn’t sound too challenging when one team is co-located and works with other teams that are at different locations or different time zones. Actually, ever since offshoring and outsourcing became mainstream, we have learned to live with the distributed nature of work. 

When do we collaborate?

We collaborate with others to achieve something of common interest. For example, entrepreneurs may collaborate to build and launch a new product. In corporate settings, different teams collaborate to build products and to deliver valuable outcomes for their customers.

Collaboration is successful when the level of trust is high among the people who work together.

However, the question remains.
How do we build and enhance collaboration and trusted relationships among team members?

There are hundreds of methods that help us do so. But we’re not going to list all of them here. Google is good for that sort of stuff. In this post, I’ll tell you what has worked for me and then you can tell me what has worked for you. Hence, don’t forget to add comments below.

Current challenge: 

When it comes to collaboration, the current pandemic has made the situation even more challenging. How? Now not just the teams, but every single person of a team is located remotely. That brings a different dynamic to the equation when we talk about collaboration and teamwork.

I’m going to share two techniques that I’ve found useful.

The first one is personal mapping.

Enhancing collaboration using personal mapping:

When team members know more about each other than just the work stuff, the bonding improves. It mostly happens that when we sit in the vicinity of others, communication begins. The generic, “hey, how was your weekend?” often becomes the icebreaker and increases the flow of communication. And it appears to me that this improved relationship also helps us deliver better outcomes. This might just be human nature. When our ancestors worked together, they survived and grew. 

Personal mapping technique is a simple mind mapping exercise where you tell your story through visualisation. Here’s my personal map.

Personal mapping

 

How to get your team’s started with personal mapping:

A good place to start is to use the technique as an icebreaker before workshops. Or, do it when New team members join. 

I often start with asking team members what they knew about me. One they respond, I share my personal map with them. I normally include details of education, work, hobbies, family, goals and values etc. The idea is to keep the session interesting. This often helps in making team members feel safe, relaxed and engaged.

After sharing my personal map, I encourage team members to pair with someone who they don’t know much about.

Team members talking of their colleague’s personal map:

When team members know that they will be introducing their colleague to others, they listen intently and they try to understand them better. 

How to do it remotely

Easy. If you’ve created your map on your computer and if you’re using a solution liked Google Meet, Microsoft teams or Zoom, you can share your screen. If you’ve created your map on paper, you can show it on camera.

Drawbacks of personal mapping:

My observation is that introverts can find this exercise a bit awkward. Some team members also do not want to share information about themselves for personal reasons. Each person is different and it’s better to familiarise the team with this exercise beforehand and find out whether it might make someone feel uncomfortable. You can work with them to adjust the exercise for them and make them feel safe for participation.

Using collaboration game Quinks for team bonding

I came across this interactive game when one of my friends invited me to join a free session with the game’s inventor, Viren.

The game is available online as well as a physical set and that makes it easier to either do it remotely or in person.

Quinks game

How to play:

Quinks is based on experiential learning techniques in which two players ask each other questions related to specific contexts by drawing cards. One person is assigned the role of Questioner, and the other the role of Answerer. The Questioner draws a Quinks card (a question card) and combines it with a Context card to create and ask a powerful question. These cards consist of powerful questions that Viren collected through his research and experience. 

Since the game limits conversations (responses of the contextual questions) to just 3 minutes, it compels team members to pay attention, learn to express themselves in a concise way, ask good questions, empathize and engage in deeper conversations.

Outcome:

I had fun playing the game even with total strangers in public sessions. It was interesting and surprising to realise that given a context and a relevant question, how you can bond with those who you’ve never met before. This was a great way to introduce people and build relationships.

Value map for further discussions: 

The game also lets players map various values of their partners based on their conversations. Once everyone completes the game, you see the value map that represents how others have perceived you through your responses. Through this process you learn about your blind spots and improve self awareness. 

 

A good reference regarding self awareness here is Johari Window. Have a look.

Personal mapping and Quinks can possibly be combined as one big workshop. I haven’t tried that yet. You may want to do that.

If you have used other collaboration techniques that gave you good results, let me know. Actually, even if your efforts didn’t succeed, we can learn from them. Why not share them here.

References:

https://quinks.co/?variant=32701557342283

https://management30.com/practice/personal-maps/

https://en.wikipedia.org/wiki/Johari_window

 

Follow here
The Curse of Knowledge bias: Why Stakeholders Don’t Understand Our Ideas

The Curse of Knowledge bias: Why Stakeholders Don’t Understand Our Ideas

I often play “tap and guess” with my son. In the game one player taps a song and the other one has to guess which song or poem it was. You can tap either a table or a box or the other player’s back or head.

If you’ve played this game, then you might have experienced that it is extremely hard to guess the song that your partner is tapping. My son always questions why I couldn’t guess the song which was so easy and obvious to guess. What he doesn’t realise is that while he is tapping, he is also singing the song in his mind. Actually, you cannot help singing or at least hearing the tune in your mind if you are the tapper. Try it, it’s really fun.

The game tap and guess

Let me be honest, I’ve had some good guesses at the songs that my son tapped. Why? Because he seems to be tapping only a few specific songs and rhymes including “Old McDonald had a farm,” (I know you’ve continued with an “E-I-E-I-O!”), “happy birthday to you..” and a couple more. However, he never ever guessed a song correctly that I tapped. Exactly like others who played this game with us.

It is very difficult to be a listener and a tapper. As a tapper you believe that what you’re tapping is obvious and it’s frustrating that your partner is unable to guess such an obvious thing. As a listener all you hear is random tapping on the table.

So why do tappers believe that what they were tapping was easy to guess? Because they already know the song. They have knowledge and they cannot imagine what it was like to not have it.

And this is where we learn about Curse of Knowledge bias.

What is Curse of Knowledge:

The curse of knowledge is a cognitive bias that occurs when an individual, communicating with other individuals, unknowingly assumes that the others have the background to understand. This bias is also called by some authors the curse of expertise, although that term is also used to refer to various other phenomena.

For example, in a classroom setting, teachers have difficulty teaching novices because they cannot put themselves in the position of the student. A brilliant professor might no longer remember the difficulties that a young student encounters when learning a new subject. This curse of knowledge also explains the danger behind thinking about student learning based on what appears best to faculty members, as opposed to what has been verified with students. – Wikipedia

(Chip and Dan Heath have explained Curse of Knowledge in their book Made to Stick through the same game but in a different context. In fact, it was this book that Made this concept popular. Their book is worth reading if you want your ideas to be more sticky.)

How does the Curse of Knowledge bias apply to our workplaces?

You might recognise the expressions below.

“It’s not that complicated, but they don’t get it. Everything I am trying to do is in their favour and will be beneficial to them, but still they are resisting it. What is wrong with these people?”

As a consultant I have heard it from people I have worked with and I often hear it from many others. Some of these people are senior management folks, others are managers, team members, people from business teams etc. Each of them have attempted to do something which was faced with resistance.

We know that change is hard. Yet sometimes we try to either push a change or hope that people will simply accept the ideas, our ideas, that will benefit them because there is merit in them.

One thing that we now know is that some of our ideas don’t get accepted because possibly we are the tappers and our audience are the listeners. What seems obvious to us, might just be random jargon to others.

What can we do about it and are there any solutions?

Dan and Chip Heath suggested two ways to beat the Curse of Knowledge in their book. One is not to learn anything. Two is take your ideas and transform them. I’d suggest that you read their book to learn more about their suggestions.

For the scope of this post, well not focused on their ideas. Instead we’ll look slightly deeper in the subject and explore what we can do.

Why don’t they get it?

There can be a number of reasons why people don’t understand your ideas. Some of them I have listed below:

  • You’re barking up the wrong tree: You haven’t clearly defined who your audience, stakeholders or customers are. Are you talking to the wrong people?

  • Your message is complex: Even though you have the right audience, your message is complex or complicated.

  • You are seen as an outsider: It is a normal tendency that we prefer listening to or paying attention to only those who we trust. In fact, a number of initiatives to improve health and well-being of communities failed because the initiatives involved external experts and volunteers. (Initial efforts to eradicate the Guinea worm disease from African countries failed because villagers often didn’t trust the experts).

  • Time crunch: Your suggestions can solve a big problem, but that might take a long time to be effective and they don’t have patience to wait that long.

  • Short term gains over long term benefits: The Stanford Marshmallows experiment suggested that there are benefits of delayed gratification. However, your customers might be focusing on the short term solution than a problem or benefit coming in long term.

What can we do?

  • Understand the context: it is vital that in order for others to understand us, we understand them and their context first. When we behave purely like tappers, we limit our ability to understand a context holistically. System mapping can help in learning about the context.

One of the aviation organisations I worked for, brought in an executive from a large financial institution to lead a transformation. This executive applied his learnings and solutions from the financial institution to this organisation. Since everything was different, from the culture, the country, the people, the processes, to the technology; the so-called tried and tested solutions that worked at the financial institution, didn’t work at the airline. There was tremendous waste of resources.

  • Don’t be an outsider: if you offer your ideas as an outsider, the chances are that they’ll not be accepted because you’re seen as an outsider and a trusted relationship is not established yet. Once you understand the context, find ways to build and establish a relationship of trust. Of course the scenario would be different if you’ve been invited to offer your opinion.

  • Find the ‘Early Adopters: (refer to Winston Royce’s Diffusion of Innovations theory). The early adopters are those who have understood your ideas and see the benefit of applying them. They’re often the opinion leaders who others not only trust, but also listen to their opinion. They have good influence over their people.

  • Avoid cookie-cutter approach: Take help from those who don’t impose an approach. While your organisation may not be unique, your context would be different than others, even though your industry or domain might be similar to others. Each organisation has its own dynamics. If you or the consultants you bring in don’t understand that specific dynamics, the solution they propose will fail.

In this post, I have discussed problems that we face at workplaces when our stakeholders or colleagues do not accept our ideas. Some of those ideas even benefit them. But they don’t understand the value of those ideas possibly because they don’t have the knowledge that we possess.. What should we do?

The text above has offered some suggestions too. These options have helped me in the past, both in dealing with my own curse of knowledge and also in having more empathy and patience while working with “listeners”.

Everyone comes from a different background. A little empathy goes a long way.

Are there other options or ideas that you have used as solutions that have opened doors for you or have solved problems for you in working with others? What are those options and what did you learn? Let me know.

Follow here
How to use SIPOC for mapping Agile delivery process

How to use SIPOC for mapping Agile delivery process

There are many process mapping tools available and SIPOC is one of them that delivery leaders can use for their Agile initiatives. SIPOC traditionally has been used in Lean Six Sigma process improvement projects.

“But Lean Six Sigma isn’t Agile!”, You may exclaim.

Let’s not get into the debate of what is and what isn’t. As good Agile delivery leaders we want to have more than one tool in our toolbox and this might be one of those tools. For example, finding a right starting point for a new initiative can be hard for many delivery leaders and we could use SIPOC for that purpose. You can also use it early in the project to create alignment among your team and stakeholders.

Another important thing to remember is that we can learn tremendously from other disciplines. If you haven’t yet, then I strongly recommend that you read “Range: How Generalists Triumph in a Specialized World“.  The author, “David Epstein shows that the way to excel is by sampling widely, gaining a breadth of experiences, taking detours, experimenting relentlessly, juggling many interests – in other words, by developing range”.  (Excerpt in italics taken from the book introduction on Amazon.com).

By learning tools and techniques outside from our own craft, and sometimes outside from our profession, we learn more about ourselves.

Table of Contents: 

What is SIPOC?

Why use it?

Who should be involved in the process?

How to create it?

Benefits of using SIPOC

What is SIPOC:

Sipoc is a process mapping and definition tool. The letters stand for: Suppliers, Inputs, Process, Outputs, Customers. These are the heuristics that guide us for defining a process at the commencement of a project or an initiative. You can also use it for process improvement activities (continuous improvement must be an ongoing goal for you).

SIPOC is like a customer journey map because both define a process while keeping the customer in mind. SIPOC compels you to think through the whole journey of a product or a process, beginning from a supplier to the customer. Without thinking in terms of suppliers, their inputs to a process, the steps of your process, the outputs that your customers may get, you might miss important details.

A key difference between SIPOC and Journey mapping is that a journey map focuses entirely on a customer’s experience, while a SIPOC focuses on an end to end process. This may also appear like a drawback of SIPOC that it talks about the customer last.

Another concept that is quite close to SIPOC is Value Stream Mapping (VSM). Since VSM is a Lean concept, it is used more often by Agile teams than other concepts. However, as I previously suggested, there is nothing wrong in having another tool in your toolbox.

Why use it?

Like any other mapping tool, the strength of SIPOC lies in its visualisation and simplicity. If a process is written in a thick, multi-page document, the chances are no one would read that and the creator will not receive any feedback. Since SIPOC can be created on an online tool like Whiteboardfox, or in-person using an A3 page or using sticky notes, it is far easier to get feedback.

Another reason for starting with a SIPOC instead of jumping straight into a process mapping exercise is that it enables teams to think beyond the process. When you use it, you have very little chance of missing on high-level process steps and the scope inclusions and exclusions.

Moreover, SIPOC provides a structured and simple way to convey and brainstorm a process.

Who should be involved in the process?

Ideally, the team members that will support your initiative and work on it should be involved in the process mapping exercise. Any stakeholders that have interest in your initiative should also participate in this process. That is, you should ensure that the process does not miss inputs from key people.

How to create a SIPOC diagram?

SIPOC is an easy to use tool. It is often presented in a tabular or diagrammatic form. Your starting point is to draw five items which are Suppliers, Inputs, Process, Outputs and Customers.

Supplier: Make a list of everyone or everything that might provide an input in your process.

A supplier can be those people or groups that provide inputs into the process. For example, a supplier can be a stakeholder or a sponsor of an initiative. A supplier can also be an upstream system or a process and a customer might be a downstream process or system. Think from provider- receiver or cause-effect point of view.

Process: Begin with a starting point of a process. Your process might depend on the inputs provided by the suppliers. Once you have a starting point, describe the key steps till the end. With having clear starting and end points, it would be easier for you to complete the full chart.

Output: An output is what we produce or deliver as information, service or a product that our customer uses.

Customer: People / groups that receive and use the output of the process. A customer benefits from the process.

Benefits of using SIPOC: 

A SIPOC diagram is easier to create. It allows collaboration between various groups and helps us create a shared-understanding. Since many people provide their inputs, they also feel ownership. Of the initiative.

Some of the other benefits of SIPOC are:

– it provides a high level overview of the process

– it helps us define the stakeholders (suppliers and customers)

– it define and clarifies the scope and boundaries of a process, and most importantly

– it helps a team to understand how their process serve the customer

So, you now have another tool in your toolbox. Let me know if you find a use of this tool.

Additional Reading:

For familiarising youtrself on such topics, Wikipedia is always a good starting point. But don’t stop there. Continue exploring more if you find a topic useful.

https://en.wikipedia.org/wiki/SIPOC

SIPOC definition on ASQ

Follow here