Nikita jollity is available for DevOps and agile training and consultant. Contact us for a free consultation.
Hey, this is Martin Intuit. I’m a professional scrum trainer with scrum dark and I Microsoft MVP. I own my own consulting company in Scotland and I travel around the world doing consulting and training. But at the moment, obviously not travelling around the world. If you’re watching this video at another time, we are all on lockdown at the moment or COVID-19. So I have taken two and helping some folks out over the internet, getting some questions coming in and then just getting online and answering them.
My good friend Debbie, who we often disagree about things, was online earlier and I stole the idea for office hours kind of from her. But it’s something that I had in mind anyway, but I definitely have to give her some props for that. So ultimately, this is an ask me anything session. I have a few questions that I have collected since last week. I’m interested in any questions you have. You can ask questions in the chat, which I have, and I can see all of the chats that might be available. But also, I have a way for you to ask questions if you are not happy about being publicly acknowledged as having asked that question.
So on the side of the screen here, there is a link to a forum where you can anonymously ask a question in a box and I will read out those questions and then do my best to answer them.
So there’s a couple of things that I did want to mention first. I noticed on the Scrambler Dawg website there were a couple of things that I thought were super awesome and I really enjoyed. The first was an article by Simon, one of our trainers from Canada, about learning scrum using Minecraft Education Edition. So I think this was a really good article. I would recommend you read it and maybe take a look at Minecraft Education to help facilitate some things that you might want to do.
The second one is from Christian, probably needs no introduction from his Mythbusters series, and he’s talking about the myth that you can’t do projects with scrum, which is indeed a myth. There’s nothing in scrum that says you can’t do projects or focus on projects or do anything of the kind. You can do whatever you want. So that’s a good article and he’s got quite a few comments and it really tackles some of the, and I think Christian’s been very good at tackling some of the, I don’t know what you would call it, the evangelical side of scrum. Evangelic or maybe the, I guess I would say bible-bashing, but it’s maybe not politically correct, that side of scrum where people are saying you can’t do things or scrum is this way or scrum is that way.
I think there’s a place for focusing on the rules of scrum, which is in training, and then there’s a place for focusing on the value that you’re trying to get, which is in the real world. So training is not the real world. It’s a safe to fail small space. Once you get out into the real world, you’re going to have to make compromises and that’s just reality.
I spend a lot of time going around organisations all over the world talking to them about those compromises and how they can maybe have less compromises. That is also important, getting as few compromises as possible, but the compromises are still going to exist. So I find those two articles super interesting. I think there’s a podcast behind this one and it’s pretty awesome.
So let me go back to me. There we go. So I have three questions. I don’t know how long it’s going to take us to answer them. It will take as long as it takes, but I have three questions so far. The first one is, I would summarise it as product owner versus project manager. I think the question was, what’s the difference between a product owner and a product manager or a project manager? I guess a PM versus PO.
I think that there’s an interesting piece there because they’re really not the same thing. If you look at the scrum guide, which went, it’s good to mention in the scrum guide, it talks about the product owner as a role. All of the roles in scrum are roles. They’re not job titles. They’re just a thing that somebody does. So the product owner is accountable for value delivery in scrum. If they’re accountable for value delivery, they have to be looking after the list of work that people are going to work on. They need to understand what all of those things are in that list of work. They need to present that list of work to other people in the organisation to make sure everybody has the same understanding of what those things are.
That idea and that they need to own that and really understand that is fundamental to them being able to do a good job of providing value in the organisation. I often talk about, and I think a lot of the other trainers do, that product owners should be fully fiscally accountable. They should be the one, here’s your budget, you have your budget and you’re spending it on this product. But they’re not always the case, but that is definitely a good idea.
So they care a lot about the market. They care a lot about how the product is going to be used in production. They care about what the competitors are doing. They care about what features users need. Those are all things that a typical project manager doesn’t necessarily care about. I’m not saying that all project managers are like this, just like not all product owners are awesome.
But the traditional project manager is focused on delivering on a small subset of items and their focus from beginning to end is on time with the features that were asked for and at the cost that was indicated. So on cost, on time, on features is the traditional measure of success for a project manager and that kind of narrows the focus a little bit to getting the thing done. You could maybe ignore the idea of value delivery. You could maybe not deliver as much value as you could because there’s that focus on, here’s the piece of work, let’s just get this done.
That can be super awesome. That’s the traditional training for a project manager and there are many people out there who have the role of project manager but also have the role of product owner. Even if their organisation is not doing scrum, they’re not called a product owner, they might have that hat to wear anyway. I think that’s really the distinction. A project manager is looking at a short time limited endeavour of work that’s on time, on budget, on scope, whereas a product owner is looking holistically and strategically across an entire product and understanding and ordering and expressing the vision, ordering the backlog based on that body of information.
So while there are project managers who are also product owners and product owners who are also project managers, I think you can see that there’s a very distinct difference between those two roles. I think there’s a place for product owner in an empirical process control system, but inside of an empirical process control system, there’s not necessarily a place for a project manager. I’m not saying that project managers are not useful. I am definitely not saying that, but inside that world of empirical process control that we know less at the beginning than we discover as we go, the traditional ideas around project management of having that scope up front, having that big budget up front, and having those resources available is a little bit antagonistic to that idea of emergent architecture, emergent backlog, emergent budget potentially.
It comes from a good place. It comes from those Tayloristic ideas. If you go watch one of my previous sessions, I talked about the tyranny of Taylorism and why that has had a knock-on impact for the last hundred years on the way we work and the way we do things. I think that that led towards that project manager ideal. We are, as we’re switching over as an industry, as everyone’s kind of focusing on that shift over to product owner, project managers still are useful, still have a place in that world, but it’s just the right approach for the right type of work, which is good.
So that question was, what’s the difference between a product owner and a project manager? If you have any questions, please feel free to put them in the comments. If you don’t want to ask a question publicly, which obviously putting in the comments is going to put your fingerprints all over that, then please use the link here and I will get an anonymous question to answer around scrum, DevOps, technology questions, whatever you want, technology, scrum process, practice, these people, tools, whatever. I will happily have a discussion around anything.
So that brings us to the second question. The second question maybe has a knock-on effect from the first one. I was asked a few days ago, apart from the scrum team, who else does scrum affect? Why does anybody else in the organisation even care? I think that comes back to some of those ideas that I just talked about. When you have a defined approach and you know a bunch of things upfront, you can make all of these concrete plans around how things are going to happen. When you can do that, you would organise around a different model.
Again, that comes from the Tayloristic approach that was designed to manage factory workers, where you have a hierarchy of organisation because you have a bunch of people doing the work. Those people doing the work aren’t, and the phrase I’m looking for, it’s not that they aren’t smart enough, that’s not correct. It’s they just don’t care about the work because it’s boring, monotonous work. If you think of screwing the top on toothpaste bottles, so a hundred years ago, that’s how the top got on your toothpaste bottle.
That disengagement from the work meant that you wanted to have a foreman around all the time. Since the work that we’re doing is not cognitive, we can have somebody else plan our work. So you have the manager plans everybody’s work and they just follow the plan and end of story, we’re done. Then you might need, if you’ve got a lot of people, you might have a lot of managers. If you have a lot of managers, you might need a lot of managers to manage the managers that you’re managing. That’s where those hierarchies came from, that idea of organising around factory workers.
We’re not in this work where you have a lot of employees who are disengaging from the process, but the modern look at things is having small autonomous cross-functional teams who can tackle different types of work. You might hear people talking about that every team can tackle every type of work. I think that’s a fallacy. It’s not a reality of the different sorts of work. You might have a team that is slightly marketing heavy, but they’re also going to have representatives from other parts of the organisation.
The lockdown that we’re in at the moment of silos with a marketing department, a sales department, a contracts department, a security department, whatever your departments are called, is a holdover from those Tayloristic practices, best practices that came out of the Industrial Revolution, which were right for that type of work, just don’t work so well for the type of work that we do now, which is mostly cognitive.
So if you’ve got all those smart people who are organising themselves around solving the problem, then you don’t need that manager managing the people. You need somebody who would maybe be described as a leader, setting direction for those teams to organise towards and potentially getting, you know, let’s find some problems and get them out of the way of people doing the work.
So you transition from that idea of management to leadership. Because you’re making that transition from management to leadership, almost everything in your organisation changes. How you’re going to budget your teams, your projects, your things that are going on is going to change. You’re probably no longer thinking about, here’s a budget for a project that’s going to last for two years and then it’s going to be delivered. You’re thinking about, I have a flow of value that I want to deliver in various categories over the next few years.
In that flow of delivery, things might shift and change. I might need more people over here, I might need more people over there, and I might not do this anymore. I might change direction. The market might change, competitors might do stuff. I want to be able to adapt to that flow. I’ve still got a finite amount of money. I have a budget, but my budget really translates to how many teams can I have.
Based on how many teams can I have, I will make a strategic decision how many teams are allocated to each of the value streams that I have in my organisation. Those teams are then going to do work against our product backlog. You may have one team doing work in a value stream or you might have multiple teams in a single value stream. At some point, you might have to move a team from one value stream to another value stream because we’re doing okay in this value stream, we’re meeting what our competitor market is looking at, but in this other value stream, we’re not doing so well.
So maybe we have to pull a team of skilled people off one value stream and move them on to another value stream. That can be difficult for that team. They may be short on skills, they may not understand a technology, it might be a different type of work that they’re doing. But ultimately, that’s something they can learn. You hired smart people. If you have a team of software engineers that have been doing Java for two years and give them a .NET project, they’re going to be able to do it. They might not be happy about it, but the technology is immaterial. You’ve hired smart people, so that applies across your organisation as well.
Whatever different products you’re building, whatever different situations you’re in, if you create teams that are able to deliver value for your organisation and work together effectively, they should be able to move between different valued domains, your value streams and the domains within those streams, and be able to deliver in different contexts.
That’s so the way you build your teams will be different. The way you organise your people will be different. The way you fund will be different. The way you manage them will be different. The way they are going to interact with the rest of the organisation is going to be different. That really all boils down to everything is different in your organisation.
If you look at maybe a company like Netflix, who run as a holacracy, that’s maybe one really far end of the spectrum towards self-organisation. Most organisations are not going to get anywhere near that any time soon, but that’s there is something there that they get value from. All the way to the other end of the spectrum, where most governments sit, where you have very tight controlled hierarchy and bureaucracy.
Hopefully, you’re somewhere between those two and moving in the direction towards holacracy. I’m not saying you’re going to get to holacracy or even if holacracy is your goal, but that’s kind of the general direction we want to move to, more self-organising teams and a greater degree of team ownership and individual accountability and moving that flow along.
So that question was, apart from the scrum team, who else in my organisation does scrum affect? You can ask any questions you like in the comments, no problem. This is streamed out to, I think, four different platforms, so I’m happy for you to ask the comment, ask the question as the comment. I am losing the ability to speak English, but ask in the comments of any of the platforms that you like and I will get that question.
Or if you don’t want to see that you’re publicly being asked the question, then please use this link here, nkd agility net forward slash ask, which will take you to a form with one text box and a little warning that says I’ll read out whatever you put in the text box.
So that brings me to my final question that actually came up during one of my classes. It was, I’m on sprint 22. Should I be using story points with my team? Should we still be doing planning poker? Should we be doing all of those things? I have a very, no, it’s not controversial, but I have very strong feelings about this. I’m super happy for teams that are just getting started, that need to just roll forward with an idea, that need to pack up process, that pick a practice that’s super simple and straightforward to pick story points, planning poker. Let’s use velocity. Let’s do all of those things.
I would be super happy for a team to start there, but I’m going to be really unhappy if they’re on sprint 22 and they’re still doing kind of stuff and it’s story points. While easy to use, easy to understand, that’s what happens when you click buttons inappropriately. The teams are, what was I talking about? I was talking about story points. Yes, if they’re still doing story points, then I would consider them still a very immature team.
Story points don’t have a lot of value beyond the team and the product owner. It’s difficult to use them in any other context. It’s difficult to gain an understanding of how things are going in the team in any other context. For the team themselves, there’s limited use within what the team are doing. The different events in scrum, for example, when they can use that data and figure it out is super, super limited, but it is super simple and easy to understand.
So if you’ve got a team that’s just started out, they’re just starting to do scrum, story points, velocity, awesome. That will probably work for them. However, I consider story points an amateur team technique. This team are still amateurs. Once they move towards being a more professional team, once your team is able to deliver a usable increment, working software at the end of every single sprint, and by working software, a usable increment, I mean something that you can put into production, that you could choose to, that the business could choose to, is technically there.
Once your team has got there, I would expect them to start wanting to optimise what they’re doing, how they’re doing it a little bit better, make more process and technique changes. I’d be able to do that. One of the things I would encourage them to look at is look at their flow and bring in some of the flow techniques that you would see any Kanban team doing.
So I would expect, I would want them to ditch burn downs, ditch velocity graphs, story points. I would kind of get rid of all of that and focus instead on a flow. The Kanban guide for scrum teams, I wish was developed, co-authored by Daniel Vacanti, who was on one of my sessions last week, but he had bad audio. Daniel and I are teaching a professional scrum with Kanban class in the Edinburgh British summer time, times on a virtual online class very soon, summertime in a few weeks.
So we’ll be teaching it online. That is where we’re going to talk about a lot of those techniques that we expect professional teams to do. You can download the Kanban guide for scrum teams and that’s all open source. Get all the information for free. So what I would be wanting teams to be doing is they want to be looking at controlling their work in process, having a fixed number of items that they have in total in progress at any one time.
That’s reducing the batch size of that and they want to be looking at work item aging, how long things take to get across that board, how long they sit there for, and looking at their throughput, how many items are they delivering per unit of time. So rather than looking at story points delivered per unit of time, looking at items delivered per unit of time means that in order to game the system, the team has to reduce the size of the items and that’s awesome. I want them to game the system in that way.
So we’re putting our set of metrics in place that allow us to positively spin the data, but in a way that is actually providing value for the organisation. So we can reduce the batch size of different items, including story size, make them smaller. They’re going to flow through our system better because we need to do less work for each item. So if things are flowing through our system better, we’re actually going to get more things delivered.
So rather than focusing on getting more story points, we’re just focused on getting more things delivered. So if the team are continuously taking on big-ass chunky backlog items, then their flow is going to suck. If they want to have better flow, write those things down, make it, make me bat the game, and that works really well.
So bringing those Kanban metrics into a professional team will allow that team to get better at delivering software. Scrum is not the be-all and end-all methodology that you’re going to use forever. It’s a framework that allows you to build your custom, most optimised for your people and your business and your domain process around that idea.
So you’re not meant to be just focusing on, we’re just going to do scrum. It’s scrum and what else are you going to do to help optimise that process? I’ve seen many teams that are doing what looks like pretty good scrum, but they still suck at delivering working software at the end of every sprint. It’s just difficult for them because they start a whole bunch of work. They didn’t really understand the work before they started it. They’re not doing enough refinement. They don’t understand the things. They’ve not broken it down. It can be a real mess.
So if you’re on sprint 22 and you’re still doing story points, I would be looking to the scrum master to encourage the team to get a start upping their game, getting more advanced ideas in there. I would consider a team on sprint 22 to be looking at new delivery. I would want to see a completely automated deployment pipeline end to end. That sure, you’re a lean manufacturing floor in the software world is your DevOps pipeline from the time the engineer commits code till it gets into production. What does your pipeline look like and how ultimately should it be completely automated?
Then things like, so I put upping the engineering game, looking at feature flags instead of branching, so moving to a single branching model, feature flags. That’s on the engineering side. Then on the process side, starting to bring in some of those Kanban measures, monitoring your flow, optimising your flow over time while still maintaining that planning cadence that scrum offers for your business.
So every two weeks, you can get together to shift and control strategic direction, but your process is continuously delivering our software and value into production, potentially on a continuous basis. You can be planning tactical direction on a two-week sprint while delivering and testing and validating your software and ideas in production 20 times a day. That’s going to work just fine and that’s going to be even more awesome than delivering it just once every two weeks.
If you look at the scrum guide, to bring it up again, you’ll see that it says at least once per sprint you should be done. It doesn’t say you can’t be done 20 times a sprint. That’s where you want to get to and that’s a difficult progression.
So that was the three questions that I had. So I answered, it was the difference between a product owner and a project manager, or at least I talked about it for a little while. If you had another follow-up question, please ask me. Apart from the scrum team, what else is affected in the organisation? You should go take a look. I did a presentation for Agile by Example conference that was recorded. It should be in my channel. I think it’s right at the start of the conference. I spoke at, at least, and in that, when I talk about what Microsoft had to change as they moved towards their agile evolution.
Some teams inside Microsoft spent the last eight years moving from traditional waterfall, like everybody was doing, all the way through to being nimble agile teams of about 650 people working on one product. That has progressed through the rest of Microsoft. I did a presentation on the changes inside of Microsoft, which is super funny. I mean, they’re now the poster child of some of those success stories on being able to make those changes that quickly.
I talked about if you’re on sprint 22, so that’s 44 weeks into your scrum story, should you still be using story points with your team? I said no, you should be looking at the Kanban guide for scrum teams and bringing in the flow metrics that you need to monitor your work.
Cool, so if you’re interested, next Monday, which is the 20th of, you know, with the lockdown, I’m forgetting what day it is, let alone what month it is. On the 20th of April, so on Monday, I will be teaching a professional agile leadership class in the Edinburgh time zone again, which is British Summer Time or GMT +1. I would love for anybody that wants to come along and it should be on my website, it should be on LinkedIn, and should be in various places.
I would love to see you there. Please ask any questions, use this link to ask anonymously, ask in the comments, and I will answer them at the next office hours. Okay, thank you very much.
Nikita jollity is available for DevOps and agile training and consultant. Contact us for a free consultation.
