Scaling Done Right 10: Things That Go "Bump!" in the Night

Hello and welcome to the Scaling Done Right podcast. I am Kiu and this podcast is a companion to the book I wrote with Geryon. In every Scrum at SCRA Adoption, there are many things that create a lot of discussion, conflict or questions. So here is our list of top things that go bump in the night. The first one, one of my favorites by the way. It's one scrum master for Multiple Teams There seems to be always a considerable amount of pressure in all sorts of organizations, small and large to have Scrum Masters working for more than one team. It's not always possible, but it's highly advisable to resist this temptation. Usually this happens from the misunderstanding of what the Scrum Master role is. It's not rare to have people wondering is a Scrum Master actually does anything other than facilitate Scrum events and maybe a little bit of impediment removal? We all know that a good Scrum Master will have a lot more to do unless the teams are very mature and are running very, very, very good Scrum, and this is rarely the case. We should focus on the fact that a team that has to share a Scrum Master will not increase velocity nearly as quickly as one with a dedicated Scrum Master. If you come to think about the cost of a full team compared to the cost of half a Scrum Master, that's not a really good investment, is it? Companies have also to invest in recruiting Scrum Masters who are experienced and professional. I see a lot of cases where somebody is sent to a two day training class and is expected on the way back to work to perform like a Scrum Master. With years of experience with all these things, consider I still rather have one Scrum Master to multiple teams than one product owner shared by multiple teams. Now let's talk a little bit about another really bad idea. One Product owner for multiple teams. I heard multiple times the argument that the product owner is responsible for all the teams working on a product and sometimes they call this as a team owner. This may be an interesting semantic observation, but the reality is something very different. The product owner is by far the most difficult one in Scrum. Having a product owner handle multiple teams is just about the best way I know to slow down the team and waste its time and therefore the money allocated for that team. It's also very common that a really good team will try to protect the product owner by taking over some of the work. While well meaning and a good sign of team closeness, this will completely distort your Scrum as the roles and responsibilities will start to blur. Another one that we encounter quite a bit is let's copy the Spotify model Spotify was not only an innovator in the music industry, but also in the agile space. One of their coaches, Enrique Nyberg, has been in the vanguard of advancing agile practices, closely collaborating with the creator of scrum at scale, Dr. Jeff Sutherland. What people often don't realize Henrik Nieberg did not set out to promote the Spotify model as something for others to follow. He merely shared his insights with the world. The main reason so many people outside of the agile community, even though the Spotify model, is that an international consultancy has pushed it onto their corporate customers. By the way, there's nothing wrong with using the Spotify model. The Dutch bank ING has used it to great success. But let's not forget that it is a contextualized implementation of Scrum at Scale. Henrik Nyberg himself is a Scrum at Scale trainer, like Jerem and I. Your context may be similar to Spotify's. More likely it's not. So please do not make mistake or buying clothes that look good on someone else's but may not fit you Next on our list we talk about servant leaders, not servant followers. Robert Greenleaf, who coined the term servant leader, said that the servant leader is a servant first. While he certainly meant well, his statement should be seen in the historical context of the very hierarchical 1970s. Servant leadership should be seen more as a dichotomy, with both parts being equally important despite appearing to be the opposites. So you would ask Q why do we care about this? I tell you why, because I see very often Scrum masters go way too far into the servant side. Instead of relentlessly attacking impediments and inefficiencies, they try to help people deal with the emotional outfall of those impediments and inefficiencies. That is not wrong per se, and the emotional aspect is indeed important, but not if it comes at the price of actually leading. Scrum masters must do both lead and serve let's talk about metrics. Metrics are one of the most polarizing subjects. It is said that what's measured will improve at a cost, and also when a measure becomes a target, it ceases to be a good measure. One thing I always tell people is be very aware of how metrics are used or perceived to be used. When you misuse a metric. And leadership is very well known for doing this, it's likely to promote what we call intentional manipulation of the metric. Or if you want to be clear that's also called gaming. For instance, when you focus solely on velocity and sets targets for those velocities, very likely going to lead teams to shortcut and that in the end turns to decreased velocity because of the rework that you're going to have to do. Don't use metrics as a punishing tool or a surveillance tool. Metrics should be used by everybody as a tool for orientation and a starting point for conversation about improvement. Then there are a few obvious questions. One is how many metrics are going to track? How long should you use them? Who chooses what metrics and more important, what behavior are you trying to influence? What are you trying to improve? Also consider this as teams evolve and behaviors change, consider the shelf life of some of the metrics and replace them. Focus on what behavior you want to encourage and keep the outcomes in mind and off with metrics. Lets talk about something that's very important. Complexity. Or to be more precise, how to get rid of it. Many of my clients tell me that there is a tendency by agile coaches to make things too complicated. Probably because they diagnose a complex problem in an organization and then conclude that a complex problem cannot be solved by a simple solution such as Scrum or Scrum at scale. This is often referred as the trap of the Gordian Knot. If you're not familiar with the Gordian knot, Wikipedia is your friend. I use it all the time, so probably everybody the Gordian knot was brought to Alexander the Great which was told that he could not conquer Asia unless he untied an extremely complex knot. Practical guy, right? Instead of trying to untie and a lot of people failed before him, he just went pulled his sword and cut the knot in half. Simplicity. Often if you do not have a simple solution for a complex problem, then you surely have to devise a complex solution. However, if you are training Scrum at scale with its components and patterns, why would you try to fiddle with the knot if you could just cut through it? Getting rid of unnecessary complexity is the hallmark of what we do. Please do not stop doing that just because you are scaling or problems appear complex. And one last thing for this chapter, be very aware of bullshit labs. Yeah, you heard right. Bullshit labs. All these things that we call innovation labs, cyber hubs or garages that corporations and government agencies have been setting up this last couple years. Some of those things existed way in the AT&T, Bell Labs, Lockheed Martin's gunk works, and even today there's some true innovation labs that actually develop unchipped products However, a lot of the modern incarnations are exclusively a product of hot air for PR purposes. Instead of updating the way everyone works in an organization and harnessing every employee's ingenuity, innovation is yet again delegated to a subset of employees, the ones who get nice offices, foosball tables, yoga classes and a relaxed dress code while everyone else is toiling away in some obscure cubicle. Some of these spaces are being hosted by corporations with deep pockets that are outdated and hungry to get in touch with a younger generation. What capable and self respecting startup entrepreneur actually spends his time holding hands with some behind of the curve corporation? If you really want to create change, avoid this quote unquote innovation labs with their foosball tables and etc. And find the leaders that are actually going to get things done. If you liked this podcast and you want to learn more, you can order Scaling done right@scalingdoneright.com or wherever books are sold. I hope you have enjoyed our podcast for consulting, training or coaching in agile and lean. You can reach out to kyu@raskere.com and to geryonamflow.net thank you.