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.
