Right. Scrum is just one design pattern. If you remember the design pattern movement from like the late ‘90s, we all had these great patterns. But if you had only one design pattern and that’s all you had, you didn’t have enough to build the piece of working software. So, a little diagram to illustrate the point. Scrum is just one pattern. It’s just one gear. Scrum only solves one problem. Scrum is a tool for building high-performance teams. It doesn’t tell you what to do of those high-performance teams. It doesn’t tell you how to organize those high-performance teams. It doesn’t tell you what engineering practices to have. I built a little chart to sort of remind people what you need. Scrum says you should have some engineering practices, but doesn’t say which engineering practices you should have.
Right. If you’re doing Scrum for marketing, you’re going to have to find some marketing practices that are the moral equivalent of the engineering practices. In the software world, the engineering practices were now kind of boring, and it’s clear you need continuous integration. You need some sensible source control. You need test automation. You need unit testing, and that sort of thing. When you get outside of that world, you have to plug and play and find your own new practices.
I tell people in the engineering practices, it’s remarkably simple. Go steal what the modern XP people were doing. The original XP people, they were really just fanatics but they were in fact largely right. You need engineering practices. So once you’ve established that and you’ve started to make your team highly productive, which is I think you know is my other passion, once you started to make your team highly productive with just the engineering practices, now you start to have other problems. You have other teams who are trying to get multiple teams to work together on a portfolio.
So you need some way to visualize your portfolio. Kanban lends itself quite well to this if you think about it. Kanban is just a tool to observe the flow of work through the system. So many of us call it a Portfolio Kanban when, if you observe over multiple teams, a picture of the stories and the product backlog items moving from a queue at the portfolio level over here through a series of states into the product backlog then into, perhaps, into the team level queue, started, accepted, tested, help written for them, deployed, or whatever the other states are your team has, maybe even translated if you have strings that need translating into multiple languages.
So we want to measure the flow of work through the system. So it’s the Portfolio Kanban. We can use that to reveal, “Are we having trouble with coordinating the work among teams?” We can use that to reveal, “Are we having work that’s getting blocked on a regular basis?” We can use that to reveal, “Are our teams suffering from interruptions?” So, we can see a lot of problems that you might have in your typical organization when we start to visualize the work. If you also remember, Kanban is remarkably simple. We have to thank David for that. He gave us only two rules: Visualize your work, limit your work in progress.
Once we’ve put up the Kanban board, we can start to see where work is queuing up and piling up. And then we can start to challenge our teams, “How do you limit the work in this area? How do you minimize the amount of work in progress?” (Which strangely enough of course increases the flow). This will reveal a lot of problems and we’ll get to how you handle that in a second. The problem that usually reveals first is we have a lot of stakeholders who don’t actually agree on what the team should be working on.
I was talking to a gentleman earlier in the day and he said, “I’ve got a wonderful product owner.” And she sets her priorities. Mostly, I think her priorities are right. And once she has them established, other engineering managers come up to this product owner and ask this product owner, “Oh, that’s great, and you’re right and we need these features. But my feature is more important, right now first.”
It sent me just to the next thing. Once you can see what’s going on on your portfolio, you need some form of portfolio management mechanism. You’ll actually need to find some way to agree on how you’re going to govern the input to this portfolio. How are you going to agree? There’s a big list of potential features you can do in the world, much bigger than any team can ever achieve in some sensible period of time. So, how do we decide what features to work on next? Usually, I get organizations to create, I don’t know, “portfolio management group committee”, some label like that. And they have to get these people together every six to eight weeks and make a decision, what major chunks of work would they like to work on next?
First of all, they have to ask themselves an even more fundamental question. Is the work that the teams currently have to adopt in front of them still the right work? So as Johanna Rothman would suggest, perhaps a recommit, are we recommitting to the current work? Are we pausing the current work? Are we perhaps even killing the current work? And only when we have space to work on new items do we then decide which of the portfolio items to take out of the portfolio queue and ask teams to break down and put in their own team backlog.
You might have such an event, say every six to eight weeks. You might invite all the stakeholders, who might otherwise go and complain to the individual team level product owners. You might invite them to this event so that they can voice their opinion and raise their concerns and voice their needs. That way when you’ve done that, when they come back to the product owner afterwards and say, “Well, I need something new and I need it now and this is more important than everything else in your product backlog,” the product owner can say, “You were present at the portfolio meeting. You were present and at the time you agreed that something else was a bigger priority, and if this is a really important change, perhaps, we should ask our portfolio group to get back together again and accept your really important change”.
That way, we cut down on the amount that we’re buffeting our teams and our product owners from change while still accepting change when it’s absolutely necessary. So we’re remaining Agile but cutting down on unnecessary interruptions.
So congratulations. Now, we have a team that has a stable queue, but we haven’t really taken care of a lot of the problems that the Kanban visualization came up with. So the next thing we need, we need some form of organizational improvement group. One of my colleagues said the other day that the single biggest failure they see in the Agile and Scrum world is when we fail to involve senior managements and the change and the transition.
When senior management, think that Scrum or Agile is something that happens to their teams down at the low level, it doesn’t affect them and doesn’t affect the rest of the business. We need some form of a process that takes the senior managers and actually makes them part of the Scrum process. I happen to run mine using Scrum but I’m sure other people will find other mechanisms as well. I get them to maintain a public backlog. Their backlog is not a list of user stories. Their backlog is a list of problems that the teams found at the team level that the teams couldn’t solve on their own.
We need it to be public so that all the teams can see where their items are at any moment in time, and they don’t lose faith. A team may ask for an item and the item may not be addressed for six to eight weeks. They need to see where it sits in the product backlog so that they know why their item is not currently being addressed. Strangely enough, we need these management team members to have a sprint planning meeting. Beginning of every sprint, say every two or four-week sprint cycle, they commit to some small number of problems that we’ll solve, and do it publicly.
We need them to have some form of a Scrum master, somebody who’s going to help remind them what their focus is and how to stay on task. And we need a product owner, probably, a team member, maybe a team level Scrum master who has passion around organizational improvement, maybe a coach who can jockey the queue and help the management see what the priorities are in the organizational impediments that need to be removed. If good Scrum teams need to prioritize their product backlog on a regular basis in a product backlog refinement meeting, maybe good management teams should have a management backlog refinement meeting, and maybe they should invite any team member, any dev level team member who wishes to attend.
It’s quite simple. Perhaps, at the end of every sprint, they should demonstrate the impediments they’ve removed, whether these impediments are, I don’t know, the servers that were doing the builds weren’t fast enough. So let’s go buy a new built server, or maybe we were getting too many interruptions from outside sources. Maybe they can demonstrate that they helped cut down on the interruptions from outside sources. But we need to have a sprint review.
Shockingly enough, if Scrum teams hold sprint retrospectives, our management team should hold a sprint retrospective. So we’re trying to achieve two things with this. We’re trying to resolve the organizational problems with the organizational improvement process, but we’re also trying to get the management team used to what they’re asking their dev level teams to do. Because we can hardly expect the management to actually understand what’s going on inside of Scrum team, unless our management has also had experience themselves. Once you start to get this into place, they start to knock off a number of the problems in your world. Question so far, Shane?
Shane: So this is where we tackle the things that the Portfolio Kanban have raised and identified.
Right. And if you remember, recently, InfoQ has actually featured a really good article on Portfolio Kanban. I can’t remember who authored it, but there was an article about visualizing your blockers, using things like changing the color of your post-it notes remarking them as they started to get older to start to recognize where you are having problems. So you use things like that as a technique to visualize more of the problems.
Shane: And that then leads into the organization improvements --
And that becomes an input into the organizational group. And it probably also becomes an input at the portfolio level because it hints back to perhaps poor portfolio decisions. We committed to doing something early before we deeply understood what we were asking of the team doing it work.
Right. Then it might hint, if we’re lacking competency, they need to find some training or they need to help set up a mechanism for internal education, or something of that sort. What I’m trying to do with all of these things, I don’t have a particular process I want people to use. There’s SAFe. There’s LeSS. There is Disciplined Agile Delivery. Whichever of these flavors you like, it doesn’t really matter. What I’m looking for is a more principles-based approach, where if we understand what problems you have to solve, figure out which patterns you happen to like to solve those problems, and then you decide which ones you want to work. I have the set I like, but at the end of the day, it doesn’t really matter.
Having got the organizational improvements in place, stunningly enough, we tend to discover that it’s actually hard to coordinate work among teams so intrateam coordination up here. How do you coordinate work? Do you want to coordinate with large chunk size? Or do you want to coordinate with small chunk size? Obviously, most of us in the Agile world prefer you slice things small and have lots of small coordination points, but you need to start reflecting on what the coordination mechanisms are.
The most well-known one is actually probably the weakest and the poorest. Everybody knows Scrum of Scrums. You’re supposed to do this idea that you have this daily Scrum, and it seems everybody sends their Scrum masters to the daily Scrum of Scrums. It’s funny. Who on the team knows the least about what needs to be coordinated with the other teams? Probably the Scrum masters, who aren’t necessarily coding anymore, which is funny. So then, why do we send them to some coordination event? Why don’t we send the people who actually have to coordinate with other teams? Why don’t we actually ask people to volunteer every day who has the biggest need to coordinate with other teams in the next day? Why don’t we send them?
Why do we even expect that Scrum of Scrums is the only way to do it? If you’ve only got two or three teams, why not just stagger your daily Scrums? Offset them by say 20 minutes then just have people drift from one daily Scrum to another. No additional meetings need to be held. Sometimes, you need something a bit more formal. Sometimes I’ve actually had people who have a separate regular sprint level coordination meeting. They go draw maps on a wall and they go build spider web like networks of the coordination problems they have. And then they sit down every sprint and they update these networks to see if they’re still the right picture of the problems they’re facing.
This is a less well-understood area, so there are a fewer obvious patterns in this area.
Finally, that leads us to the problem of, as you start to reflect on how do you coordinate effectively across teams, you have the problem that a lot of organizations have organized their teams into component teams, this beautiful idea that you might have a server layer and then a business layer and then a GUI layer. There are a couple of major problems that I meet. This is a little more well-known. Craig Larman and Bas Vodde popularized the whole idea of feature teams.
But as popular as they made it, I’m still finding a lot of organizations out there with a lot of component teams. And I find it a struggle because we have this ideal that we ask our teams to deliver some small vertical slice of value called the user story, often. And then I go asked a server team, who an end-user, who user is. When they say, “Well, my user is the business logic team,” well, that’s very interesting. Is the business logic team paying your salary? No. Oh, so there’s some customer out there that’s funding the organization. Well, weren’t they the user?
So my problem is that when we have these component teams, we’ve accidentally built the silos back into the process again, which is what we were trying to break down with Agile. So we have to start reflecting on whether or not we can evolve these component teams we’ve created into something more vertically oriented like a feature team. This one is not easy. Many of these other things, you can set up an organizational improvement team in a couple of days. Getting your component teams to morph into feature teams without breaking them down and destroying them is going to take you months.
You’re going to have to cross-train people who have experienced say building server side code into these strange things called GUIs that might be written in some strange language called JavaScript, and not whatever they’re preferred server language is.
4. So there’s quite significant potential investment and change at that level?
Right. That’s going to take a long time to change. But the idea behind all of this is that these are all independent patterns. There’s no right place to ask. Somebody asked me the other day, “Should you start with the engineering practices?” I don’t know. Maybe. I’m a former XP guy. Maybe I want you to start with the XP practices. But there isn’t the right place to start. Each team has to start where it has the energy. Each organization has to start where it has the energy and the pattern. For better or for worse, I’m a Scrum guy. So people bring me in to start with Scrum. My point to them is, “Yes, that’s wonderful. It’s not enough. You need more.”
Shane: And there is a picture of it all.
There’s a picture to remind you of the all.
Shane: Mark, thank you very much. That gives us a really good summary of why Scrum on its own is not enough. Thanks for taking the time to talk to us.
Thanks very much.