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.

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. 

Commit to CRIME

Commit to CRIME

When Mike told me and few others that we should commit to crime and also get our teams to do that, I was like, “Huh? What do you mean?”. 

 He went on to explain what CRIME acronym was. 

CRIME stands for Collaboration, Retrospective, Investigating, Mapping and Exploration. I found the acronym useful as this reminds you of the basics that we should all be following and keeping track of. In fact, mnemonics has been a proven technique for remembering ideas and concepts for a very long time. People who have studied chemistry will possibly remember how they memorised the Periodic Table.

This website is a useful resource for learning more about mnemonics.  

I have attached the sketch for you that you can share with your teams.  If you can’t download it here, then please email me and I’ll send it to you.

Mike is a friend of mine from North Carolina. He is an author, speaker and QA Director. Although he used the acronym CRIME for testers, I modified it to suit Agile delivery people and teams.

 

Crime acronym

Tips for Job Seekers

Tips for Job Seekers

As a #JobSeeker, one of my mentees asked for help and I gave him few tips to deal with the current situation. I hope they are useful to others too.

1. Do some planning:
– what can you do to manage the situation in the short term
– what does the long term look like

2. Stay afloat:
– In the short term, find ways to generate some income (selling used things online still works.)

3. Take Action:
– Re-connect with those you know and build new connections. Others might be in the same shoes as you are. So, gently ask for help and follow up after some time.
– Apply for relevant jobs.
– Can you deliver an online or virtual training? Consider those options too.
– Make a list of things you are good at. Don’t judge yourself by saying, “I’m not good at anything.” Just make a list. Can you cook, sew, build, design, teach, sing, dance,..? Someone out there might need help in that.
– Stay up to date with your skill area.
-Negotiate your rent, utility rates and mortgage.
– Can you secure a government grant to start a business? Find out.

4. Stop worrying:
Yes, easier said than done, but let’s try that. Worrying takes energy away. Distract yourself from negative things. Do things that make you feel better.

Things will improve eventually. Stay positive.

Advice for Job seekers

 

Is Remote working doing more harm than good?

Is Remote working doing more harm than good?

Is remote work doing more harm than helping?

In the past weeks some of my clients, friends and ex-colleagues have told me how they’re working longer hours, getting lesser exercise and spending less time with family.
That indicates a big problem. And that problem is burnout.

While working longer hours you may see high productivity in short term, but the consequences can be disastrous in the longer term. So, please stop it!

What can/ should you do:

– Block your diary for breaks. Have short breaks if you’re worried about disruption to work.
– Use lunch breaks for exercise and walks. Can you attend meetings while walking?
– Talk to your colleagues about good practices and prepare a working agreement. (I’ve written about how to create these. Visit my blog.)
– Stick to your delivery or release planning process. Agile releases allow you to flex the scope. What would your stakeholders prefer? A massive surge in productivity now and a massive drop later; or a continuous flow of delivery?

What else can we add here?

I work with teams and individuals in improving their delivery practices. Connect with me if you need help.