 All right, let's get started. Can everybody in the back hear me okay? All right, they're doing the mics right this time. Excellent. So welcome to Consultancy Scrum, making agile work for clients and consultancies. So real quick introductions. My name is Todd Nienkirk. I'm a digital strategist and partner at Four Kitchens. Feel free to reach out to me anytime if you have follow-up questions. I also have my business cards and stuff out here too if you wanna describe one and run out the door and we can talk later. Feel free to also follow me on Twitter. I'm Todd Ross. Beware, it's mostly bad puns. Hi, I'm Susie Bates, Director of Projects at Four Kitchens. Wow. And that chair's really loud. I'm Paul Benjamin, Project Manager and Scrum Master at Four Kitchens. So this is our project management team. Everybody is here today. So you can ask absolutely everybody at Four Kitchens who does project management how we do it. So this is a very rare and excellent opportunity. So before we get started, before I talk about what the problem is, I'd like to know more about you. So how many of you would consider yourselves to be a client? You are somebody who hires other people to help you do work. All right. And how many of you are vendors? You are hired by clients to do work. Okay. Now of the vendors, how many of you do Scrum or Agile or some flavor of that? Okay. Pretty much everybody, right? Who does not actually? That's more interesting. Smattering. What do you do if you can yell it out? Anybody. All at once, simultaneously. Waterfall, anything, just whatever. Get it done? Okay. Combination, waterfall, something like that. Gotcha. Okay. So today we do assume a fair amount of knowledge about Scrum. So we're going to be using Scrum terminology. We're going to be talking about POs and sprints and things like that. So if you are totally new to Scrum, I'm sorry, but just sort of let it wash over you and we can talk about it later. So to dive into all the terminology stuff, here's the problem that we're here to discuss. This is the problem with using Scrum as a vendor when working with clients. Scrum was originally designed for products with internal teams and stakeholders, meaning you are an organization like Microsoft, Google, IBM, you're building a product that you own and that you sell. And all of your resources and your team and everybody, you're all under one roof, you share one culture, one organization. So if something goes wrong, it's between divisions or it's all vertically stacked within one team. Consultancies, however, vendors, we work on projects and we're dealing with external teams and stakeholders. What I mean by the difference between products and projects is we are hired by our clients to help them with something. That might be a content oriented site or a transactional website or an application or a piece of software or something, but ultimately they own it, not us. We're hired hands to work on a project for them that they then own and control. So there's a subtle but very important difference there. And also we're working with their external teams and stakeholders. So whereas if we were all Microsoft or Google or IBM or whatever, Apple, our stakeholders might be our bosses or it might be our peers in a department next to us like marketing or communications or something like that. But in this case, it's the person who's paying us. It's the group of people who are actually signing the checks at the end of the day. So there's a very different kind of relationship and some different tensions that come into play. That's the fundamental problem that we are trying to solve with consultancy scrum. So to review, here are some of the characteristics of what we're going to call today scrum classic. This is traditional scrum that everybody knows if you've worked in a big soccer company or really any kind of soccer company. You're working on products. There's something that you own and control in their years and whether you sell them or not, that's your problem. You own them, you control them. Everything is internally facing. You're dealing with your coworkers constantly. Everybody you talk to is a coworker. Your stakeholders control all of the resources. So they have the budget, the personnel, the tools that you're using and the scope. The stakeholders control all of that and you're all part of one culture. And one of the tendencies of scrum is that it's done when it's done. When it's good enough to go live, let's go live. And the stakeholders all agree with that. In consultancy scrum, however, again we're working on projects. We're hired hands and ultimately our clients own whatever it is we're building. And that might be a product to them but it's a project to us. It's externally facing because we're working with their teams. Sometimes we're augmenting their teams, we're working with them or they're the product owner. But mainly they are the stakeholders. Both of our organizations, clients and consultancies share control of the resources. So clients control the budget because they're the ones that have the money they're gonna pay you, that's how you get paid. You, the consultancy, the vendor, you control the personnel. Who works on it and for how long that's up to you because you all work together within your consultancy. And both parties, the clients and the consultancies are expected to control the scope theoretically. And one of the biggest things that differentiates consultancy scrum from scrum classic is it's not necessarily done when it's done according to the stakeholders, it's done when the client is happy. So when the client says, yep, this is done, this is good, we're good, that's when the project is actually done. So to talk about some of the very specific ways in which you've modified scrum, here's Susie Bates, our director of projects. Good morning. So as Todd mentioned, we're gonna talk about the differences between we sort of have a top 10 list of things that we've found that we've modified standard scrum. So we're not gonna talk about, you know, scrum fall or any sort of weird amalgamation of scrum. It's really sort of following the classic 10s of scrum. But how do we make it work for working with clients and working with a team that has an external stakeholders? So let's start with the bat law. So the backlog is a list of stories that the product donor writes, prioritizes, and then they do the planning of the iterations and the releases. We like to, or in a classic scrum classic situation, a ready sized backlog, meaning a backlog that has the entire list of feature stories, whether they're in epics or user stories themselves, are defined. So you know 10 sprints down the road what the stories are. It's not really necessary in scrum classic, except for the release planning part of it. So you can do iteration by iteration planning. We found in consultancy scrum, product owner still writes the stories, prioritizes the backlogs, plans iterations, and releases, that's the same. What's different is we need a ready sized backlog from the beginning. We found if we say, oh, we'll just do it sprint by sprint, then it's easier to go off track and it's easier to miss the goals, whether it's the budget or the timeline or the feature set that need to be accomplished. Similarly, defining the MVP from the beginning is really important and it's great to put a milestone on that MVP. They're a little party when you get to that point because it gives the client an idea of what's required and what's nice to have, which of course is always, it's hard to draw that line, but saying minimum viable product helps the client understand what they're gonna get that's really feasibly workable and then where do we add the bells and whistles later. So daily scrum. In scrum classic, the product owner, scrum master and team all attend, they give their daily updates, remove blockers, sometimes even review stories in a scrum. In consultancy scrum, same thing, same people attend, we have the product owner, scrum master, team, we share our updates, but we really like to include the client. This is sometimes challenging because often the client has come to us and said, we have a problem that we don't have time to fix, so we're hiring you because you have the time and then you say, great, can you be in a 15 minute of scrum every day and they say, that's a lot, I'm busy and I can't be there. So sometimes you have to accept that they can't attend. Occasionally we add a weekly client check-in meeting in order to replace the daily scrum with the client. It's great to have them come to the scrum, but sometimes you have to be a little bit flexible to include them according to their schedule. So demos, at the end of each scrum, the team demonstrates their work at the end of each sprint, sorry. The product owner is there to accept or reject the stories and they represent the stakeholder, stakeholders. So in consultancy scrum, we like to do pre-demos before the demo. We like for the sprint demo to be sort of a formal acceptance of work that everybody's already familiar with. So we do pre-demos, whether they're ad hoc, you just ping someone and get them online and show them some new feature, or we sometimes schedule them if we have a particularly scheduled limited client, then we'll put a standing meeting on their calendar and then show them what we've got. But they're really important in getting their feedback before you get to the end of the sprint. And then the main difference with demos is both the client and the product owner, who could or couldn't be the client, accept or reject stories in the demo. So you're probably familiar with the fast, good and cheap. You might also be familiar with this triangle, which is, is it on time? Is it on budget? Or are the features the most important? So in Scrum Classic, you say, pick two. Which one is it? So you encourage the product owner and the stakeholders in Scrum Classic to say, we need to be on time and on budget, but if we don't get all the features, we're okay. And then you fine-tune the backlog to allow for that. If your timeline is flexible, then you might add an extra sprint to get those last features in. But there's always one that's been needed. In Consultancy Scrum, no matter how much the client wants to tell you that budget is flexible, budget is not flexible. So you get to pick two, budget's one of them. The reason this is, is that you're in a contractual agreement with someone. And the main thing that's on the contract is how much is it gonna cost. So by saying, oh, don't worry, we've got more money, you say, great, let's change it. Let's make a statement of work for the additional money. Or we'll drive to the initial budget and then when you go get more money, we'll do phase two. So the promise of don't worry the money doesn't matter is fine if it's in a contract, but the contract always has a number. So that's where you really work on the timeline or the feature to be the bendy part. And then additionally, you always wanna share the budget with the team and the client on an ongoing basis. So we have a report we send out at the end of every sprint that says, this is how much money you told us you wanted to spend, this is how much we spent so far, this is our prediction for the future and does that equals zero plus or minus. So it's good for the team and the client to know how we're tracking to the budget as we progress. All right, let's talk about velocity. How fast are we going? Are we gonna make it? If we have 10 sprints and we're only doing five points of sprint then we're only gonna get 50 points total. So one interesting part about, so I like the velocity question when the difference comes up between scrum classic and consultancy scrum. In scrum classic, it's really in your best interest to keep your team static. So you want to keep, and you know, people do this differently, but you wanna try and keep this team static so that they get their practices together, their velocity can increase sprint over sprint and your predictability of velocity is really high. So this is challenging in consultancy scrum. We roll people in and out of projects, they have different skill sets to accomplish different portions of the project. So staffing is very fluid and variable. One rule we do follow is anyone who's rolled onto a project is rolled on at the sprint kickoff. We've never rolled anyone on in the middle of a sprint and they stay until the demo. So we know that even if it's Wednesday to Wednesday that that person is allocated to this project. So this makes for some fun velocity calculations. So you might say, this sprint we have four people, we have 20 points done. We're gonna add someone the next sprint. So that means we can do 25 points. So our velocity, as you can imagine, this is not as accurate as keeping a stable team. So you have to be open to the velocity is not as predictable as in regular scrum classic. But it's really important to retain a core team member or members so that you're not swapping people wholesale out and you're not leaving, we like to call them a consistent resource and they may be the lead developer or they may just be a developer who's gonna be on the team but the lead swaps in and out as long as someone has the tribal knowledge to go from the beginning to the end. This allows us to have consistency of knowledge, coding practices, our definition of done doesn't vary all over the place depending on people. And then also it gives the client some feeling of consistency that even if you bring someone in, sorry, in the middle and they roll off after a couple of sprints, they at least know that Bob's gonna be there at the kickoff and they're gonna be there at the rollout. So over time, this is actually something that's rarely talked about in scrum. So when we talk about scrum classic, at the beginning of the sprint, you sit down and you have your team estimate, review all the stories and make a commitment. They understand the scope and they say we'll do whatever it takes to get this done. Even if it means working overtime, which actually is not irregular. What is the cost of a project of overtime? Well, it's goodwill. It's your team taking their personal time to meet a commitment. This is a good thing and it's generally thought of as a positive thing. In consultancy scrum, when you have a fixed fee project, the overtime cost is also goodwill. You don't have any additional monetary costs for this overtime work. But when you're working on a time of materials, hourly billable project, you may not realize that working overtime actually impacts your budget predictability. So you knew you were gonna burn this much time, but you have a big spike for this sprint. That means that sprint number 12 is actually gone. Do you have less sprints at that point? Because you have a fixed budget. So because of this, only when we have clients who are really budget driven, sometimes we'll let stories roll over and we won't make a big deal out of it. But I mean, the team really does want to commit. So we do talk about like, let's get it done in the time we have. And that seems to work for them as well. They understand those give and take. So client management. You don't have any clients in scrum classic. So you don't really have to worry about client management. You have stakeholders and there are humans involved. So there's people management, but you don't really have to worry about that external client. In consultancy scrum, we really like to have one person who is outside of the team that the client and team knows that they can go to. This person we call the account manager. They know about what's going on in the project. They understand the client's needs and they're a sounding board for good things and bad things. There when things go off the rails, it's someone outside of the team that the client can go to to talk to. Also this account manager calls them on a regular basis to make sure that they're okay because a project is not just code. It's often wrapped up in a client's emotional needs. I've had a project that was highly tied to someone to review before. And so it's really good to know these personal items and the account manager is that personal contact that allows for that. At the same time, I went to our account manager yesterday about a project because it was a great place for me to go when we were having a problem with the client to sound out some ideas. How can we address this new problem that we have before going to the client? So contracts and statements of work in Scrum Classic, usually they're not necessary. So you're not really dealing with contractually obligated deliveries of work within an internal organization for Scrum Classic. In consultancy Scrum, you should have a contract as we all know. It's best you have a statement of work so that people know what they're gonna get an idea of when they're going to get it and the features they're going to receive. Now, remember we talked about pick three. It's best to not be really prescriptive about the bendy thing. So if they say, oh no, timeline doesn't matter, then it's probably best not to put a hard deadline in your contract. So when we say things are appropriately vague, it means have your contract meet the way that you do things. So if your feature set is in the backlog, then maybe you'll have an overview, a list of ethics in your contract. But if you list out stories in your contract, then you have to do a change order when you reprioritize the backlog. You really don't wanna do a change order when you do anything to the backlog. However, sometimes the client's goals change. They have an epiphany moment where their business plan changes. Or really, or they come along and they say, we wanna get a whole new set of features to add on the end of this phase. Then you need a new statement of work. You need to adjust the contract. Any monetary changes need a new statement of work. But those things again should be appropriately vague so that the process can manage itself without having to have all this overhead of change orders. So next, preparing for launch. In scrum classic, if you're doing it right, you're QA'ing and testing in each sprint. So at the end of the sprint, when stories are accepted, you can push it straight into the staging server, production server, and launch. In consultancies scrum, the code and the team may be ready. When you're done with that last sprint, you're done. We've done it right with QA and we have continuous integration so it goes to the staging server. The question is the client's not always ready. Sometimes they need some time to get some last minute content in the system. Sometimes they need a really a last look-see to make sure that everything's the way they want it so they'll do some testing. It gives us the opportunity to fix some bugs. But then the thing that happens when it's not on a hosted system, when they're hosting it themselves, there's often a process that could be up to a week to get it onto their production servers working with their IT. So if you don't allow for this, then you're basically saying we finished our sprint and then the next sprint, you're gonna go on and start building features, but who's gonna make sure that IT has what they need? So that's why we like to have this hardening sprint, which is an acceptance of the time that the client needs. Yes? Yeah? No, no, no, we've been in contact all along, but sometimes, and everybody's process is different. So we've had clients with internal IT who are ready to go the minute we are, but there are some who just have those steps that need to happen or they only release on Wednesday or things like that, that sometimes will add to the process. Well, we should know it in the first sprint because we are engaging with you on a staging server prior to this. This is really just going live steps. So finally, let's talk about the product owner. As we said, the product owner is responsible for the product. They guide the roadmap, the backlog, iterations, releases. Sometimes they're even worried about profit and loss of their product. They're doing marketing analysis, they're looking at competitive analysis. Product owners in Scrum Classic are usually professionals whose job it is to manage a product. So in Consultancy Scrum, we need a product owner too, but it's not a product. So in order to use ubiquitous language, we've called it project owner. It's more accurate and it gives everyone an idea of exactly what the scope of the work is. I'm gonna hand it over to Paul and he's gonna talk to us about who should be the product owner. Thank you, Susie. So when we talk about who should be the PO, is it somebody on the client side or is it somebody at the consultancy? You can assign the role to somebody on the client side every time if you're able to do so and that is absolutely the preference. If you can get somebody on the client side to come in and take that kind of ownership of the project and they can be involved, that is ideal for Consultancy Scrum. But sometimes they're not available, like Susie talked about, sometimes they have time constraints and they're not available to do that, in which case somebody at the consultancy can take on the role of the PO. What's most important is that whoever that PO is, everybody has agreed that they have the power to make these big decisions. So even if it's somebody on the consultancy side, the client has officially signed off and said, yes, that person at your company is representing our best interests and we're going to trust them and we're going to know that they're going to be in their approving stories and that's cool, we're down with that. But most of the time when you're doing this in Consultancy Scrum and you've got the client coming in, performing the job as the PO, it's a new role to them. In some cases we've worked with places where there's a person who is super knowledgeable and is used to Scrum and they've done this kind of thing a lot, in that case it can be quite easy. But sometimes it's somebody who has never even heard of Scrum or they've heard of Scrum but they've never done it. So in those cases it's your job to teach them the skills that they need to be an effective PO. So they need to learn all about Scrum user stories and as an X I want this feature to do Y so that I can get this result. They also need to understand the prioritization of those stories and how to figure out what is that MVP and how do I figure out which features I'm going to need first so that I can continue building. You also need to teach them how to accept stories and why that's important. So for example I've had clients who they get kind of nervous, oh we're in the demo and I'm accepting this story and I don't know, once I accept this we're moving on and I can't ever come back to it and you can explain to them, it's okay, we can always write a new user story that captures this additional functionality if you come up with something but it's important that we accept this, does it meet this definition of done that we've come up with, let's move on. At the same time you don't want a client who just says oh well you guys said it's done, it must be done, I trust you, you're the experts, right? You need to make sure that they're testing these stories and that they're making sure that whatever features you've built are what you have all agreed it should be. And then there's this idea of the thin vertical slice in Scrum and how is this thing done that's not really done? So I'm coming to the client and I'm saying here's a bike frame and it's got some wheels on it and there's handlebars in a seat, here you go. And they have to be able to look at that and go but there's no brakes, right? What am I gonna do with this thing? And help them understand, this is just the protobike, this is the bike so far. Then you also have to teach them when it's a good time to include their other stakeholders within their company. You don't necessarily want their boss or their boss's boss's boss to come in and look at this protobike and throw their hands up in the air and say there's no brakes, there's no gears for me to switch, there's no little ringy bell, that's not a bike, I'm furious. At the same time you don't want the stakeholders in their company to come in so late that they look at this protobike and go, I thought we were building a car. However, sometimes that client can't serve the role of the PO, sometimes they're too busy, there could be many, many reasons. In that case, they still need to be involved, they still need to have that deep understanding of what it is that you're building, what your goals are, what's the MVP, how are we going to get there? They need to be involved in those critical decisions. So raise your hands, you don't need to raise your hands, you've probably never experienced this but sometimes on a project, things don't quite go as expected and you have to make some changes. There's a change in priority somewhere or there's an issue with the budget because we burned some overtime and now we're gonna have to lose a sprint at the end, let's make some big changes, let's make some big decisions, somebody from the client side needs to be involved. There's that term in Scrum Classic that the PO is the single, ringable neck and while we don't really like that terminology so much, it is true that you need somebody on the client side who can say, yes, I've been involved this whole time and I accept responsibility for these decisions. They also need to attend those demos and accept those stories and also make sure that they're testing those features to make sure that they fit their needs, right? So what's interesting here is we say they're going to accept the stories. We've already empowered somebody on the consultancy side to be the one who accepts user stories and the client has already said, yes, that's cool, you represent us, we trust you, you can accept those stories. You still need that person on the client side at the demo to say, I'm still down with that, I still agree, you're still empowered, it's okay. They also need to be available for that frequent communication, right? So maybe they can't be in the Scrum every day, maybe there are limitations on their time, you still need to be able to get ahold of them, you still need to make sure that they're involved in the process. And then we've got this idea of this weekly backlog review where we get together with the client and we sit down and we go through that backlog, make sure everything is still in its proper priority. And one of the most important things to do, and this can be especially important with the client who is new to the Scrum process, is to make sure that you're looking at those stories that are at the bottom of the backlog. Because it's easy for a client to say, well, I've already prioritized all of these stories, so let's just look at these ones at the top that are coming up for the next sprint, those are the most important ones, right? In a way, those stories at the bottom of the backlog are actually the most important because those are the ones that are in jeopardy of dropping off the list. If you're running behind on your user stories and you're not going to get to everything in the backlog, which is frankly the case most of the time, right? You build a big backlog and there's a lot of features that you know eventually you're gonna have to flex and say, oh, maybe we'll do that later, right? Those are the stories that are gonna drop off the backlog first, so it's important to make sure that you're paying attention to those in those weekly calls and really taking a look and checking out that those are going to be in good shape. A few rules of having a consultant PO. You should never have the consultant side PO serving as a designer or developer on the project, right? So hey, I'm Paul and I'm building this feature. Here you go, Paul. Thanks, Paul. Great work. Thanks, Paul, I'll see you later, right? That's not really your best scenario. So it's important to have the designer and developers focused on their work. It also keeps them from having to task switch from being down here in the weeds on their feature and then trying to get this high level view of the whole project. You can have a designer or developer who's working on another project be the PO on this project. That can sometimes work. Also, the Scrum Master can also sometimes be the PO. This is a big no-no in Scrum Classic. In Scrum Classic they say the PO and the Scrum Master should never be the same person. But there have been cases where we have determined that this was the best way to proceed and it has been successful for us on those projects. So a little note on the structure of the team for those of you who are visual learners. You can see here the client is in blue and the consultancy is in green. And you look at that product owner, that product owner can actually take either role. And it's important again to remember that account manager role that is somebody outside of the team. It can be great to have the client bounce some ideas off of them and then they can come to the project manager or the Scrum Master and say, hey, the client, I'm getting the sense that they're feeling this or they set out right. They're feeling this. Let's talk about this. What are some solutions that we can go back to them with? But the simple fact is that Scrum doesn't always work. And this is why there are a lot of places that, well, we're doing Scrum but. It's Scrum but, let me change this or that or the other. And we like to think of Scrum as the sort of delicious gooey center of the project building, feature building process. So when you're doing Scrum and you're building things, that's when Scrum works really well. But in the design phase at the beginning, it becomes sort of questionable, right? Because design tasks tend to be things that are tasks, right? You're gathering user personas or you're making style tiles or you're building the style guide. These are tasks that you do one and then another and then another. That kind of sounds like waterfall. And we've tried that. We've said, okay, during the design phase, we're just going to be waterfall. But frankly, we haven't done waterfall in so long. We're not as used to waterfall. We're kind of used to Scrum. At the same time, sometimes you'll have design doing their work. And at the same time that design is doing their work, you're already doing some feature building. Maybe there's a feature that isn't necessarily involved in the design process. We're building this editor and this is how it's going to work. And we don't really need to worry about the style tiles or any of that stuff yet. So those people are working on a Scrum schedule, right? Because they're building a feature. And at the same time, you've got design people who are kind of doing tasks. So what we have found to be most successful is to do these design tasks and integrate them into our Scrum process. So we track the tasks in JIRA. They're written as tasks, not necessarily user stories. And they're time boxed to that two week period during which we're doing that development, right? So at the very least, it's setting up regular deadlines for those design tasks. Then also when you get to the end of the process, Scrum starts to maybe feel like it's not the best practice. And I mean, there are plenty of places where, hey, we're going to address all of your bugs here while we're supporting your product. And we did this work and you're going to get it in two weeks when we do the demo. We'll roll it all up at once. But a lot of times clients are, oh my God, my hair's on fire, I've got this big problem with the thing that you gave me and I need this fixed right away because otherwise the world's going to explode. I'd rather not tell that person they need to wait two weeks for it. So at that point, we go into something that's more like a Kanban system where we do the work, we demo it for them immediately, they accept it, it rolls straight up to production. And to continue the conversation, here's Todd. So we've been working on our modifications to Scrum for I guess about the past six or seven years. This is definitely a work in progress. And I see lots of opportunities talking with all of you and other project managers and Scrum masters and web shops to understand everybody else's pain points. So for example, the idea to not use Scrum in the design phase was the result of a handful of conversations I had with designers. I was on a panel about Scrum maybe about a year ago and half of the people on the panels were, on the panel were designers. And these designers just hated Scrum. They were there to be on the panel to say that Scrum is terrible. And I was there to somehow defend it. And what we discovered is that we actually agreed on what it's not good at. They were just taking like a sort of an oversimplified approach and I was trying to apply Scrum to cases where it wasn't really working. So one of the ways that the designers explained, one of the many complaints with Scrum was that dividing a design task into a series of user stories was like, like looking at a landscape through a paper towel tube. You know, you see like a circle and then you kind of move it a little bit and you see another circle and you kind of do that a lot of times and you get a kind of like a Swiss cheese sort of effect of the design and there are lots of gaps in between, right? You get the general picture. You understand like mainly what's happening but it's really hard to take a step back and really gather the whole experience. Plus Scrum, when it's executed in this, you know, sprint by sprint story by story way, it's really difficult to go back and redo work that you've done before. You're totally welcome to do that and Scrum encourages that but let's face it on a client project with a limited budget and a deadline. Those stories to go back and redo the first design task that you ever did because now you've come up with new design elements and interfaces and things like that that you want to then reapply to stuff you did early on, they just don't get prioritized and they probably never get done. There's just limited time and money. So having that holistic approach where designers feel free to say, hey, I came up with a better idea, I want to go back and redo some of that work earlier and instead driving it by milestones, it just makes a better designer experience for a project. And that whole idea and our implementation of it was the result of a conversation about Scrum. So we've created a very simple website right now that will eventually expand it to something a little more cohesive and complete but it's called consultancyscrum.org and there you can, we'll eventually when the video or whatever is put up for this, we'll put that video up there, but you can, there's a podcast that we did with Drupalize Me, there are previous versions of this presentation there and eventually we want to build a bit of a community around it and the site is up on GitHub so anybody can contribute to it. So if there are links you want to add or content you want to add or whatever, feel free to do it. You can, there's a little link that says, fork me on GitHub and you can add content to it. So this is, we really intend this to be a conversation and a movement, not necessarily like we figured out the way to do it and here's how to do it and you're welcome because this is something that's constantly evolving. What we like to say about our process internally at Four Kitchens is that we are an agile shop and the fact that we're agile is itself agile. Our process is agile. So it can change all the time as well. So we wanted to leave plenty of time because this is a big fire hose of information. We want to leave plenty of time for questions, horror stories and group therapy. So if anybody has questions, there's a mic right in the center of the room. It'd be great if you could line up and do it because they're recording this as a video or podcast or something. We want to make sure that we hear your questions but if you have to just shout it out for whatever reason I'm happy to repeat it in the mic. Go ahead. So it's like finding water in a desert really to see that this is being named finally. I think I've been trying to do this as I'm a project manager and run a dev shop at Advomatic and over the last year as I come in we've changed to this process which I've used in various forms before. So this is amazing to finally put a name to it. So thanks for that. I wanted to ask, well I have so many questions but I'll just ask one. You didn't talk a little, if you could talk a little bit about the role of the scrum master in this context I guess that would be helpful. If you have time I'd be interested in hearing how you deal with front-end dev like theming stories. Do you separate out theming stories from your dev stories? So the scrum master actually plays almost exactly the same role as scrum classic. They are managing the meeting schedule of the recurring meetings. They're also representing the team in the scrum practice. So it's really not much different because we actually have project managers who play the role of scrum master so they manage the budget and the scrum but it's really not, it's not wildly different than a regular project. And that being said there are times when we have a team member play the role of scrum master instead of the project manager just depending on various circumstances. So we do it that way too sometimes. And then the design stories. We, gosh, we do it differently depending on the project. Sometimes we'll have tasks for design that happen prior to the sprint, sort of the sprint before the sprint. And then sometimes it's just a column in our JIRA board where it goes from theming and back-end work, I'm sorry, site building back-end work, then into theming. So it just really depends on the team and the project that's being accomplished. Thanks so much for organizing all of this. I think it's gonna be super helpful for everybody and I'm in the community. I had two questions. The first one is, I think it's awesome to get the backlog in place before the project starts. Our challenge with that often is that it's just hard to corral all the troops early on to write all the requirements and is that done in business development time or on client time and how is that organized? And my second question is the other thing that we struggle with sometimes is maintaining the vision of the project when you're like in sprint five and the client sees something really exciting and shiny and wants to go there and we need to bring them back to focus on the original goal. And even if we pull up original documents, it's really hard to do that because they tend to be just something that they're not referring to later on. So how do you guys maintain the vision throughout the project to keep everybody on course? Sorry. We do story writing in our business development process. So we write stories to estimate our project. They may be really high level if we don't have a lot of time to estimate for our proposal, but it's great to go from the proposal into the first sprint with the stories that we thought we were going to do estimated in story points. So then we know what we thought and we write a lot of assumptions. So when we finally pull that story from the backlog and it's three months down the road our assumptions in the business process may be wrong but at least we wrote down what we assumed. Do you mind if I jump in for just a second? Yes, we do, yeah, a discovery. Yeah, go ahead. Yeah, well I was going to add that as well. But to talk about the estimation piece because there's a subtlety I want to draw out there. Okay, how many of you, when you are working on a bid or a proposal for a project, break down a project in terms of either very granularly, I know there's some shops here who do this like, we think there will be 12 views and that each view takes half an hour and therefore it's six hours for that. Now let's move on to every panel page and every panel page takes two hours and there are four of those so that's eight hours total. There's that very granular hours mark or do you kind of ballpark hours like, okay, this whole feature set, I don't know, it's like two weeks of work so that's 80 hours. How many people talk about hours in their proposals and their bids and all of that? Okay, what's interesting though is, because many of you are probably also scrum shop, right? So you've developed your proposal and your bid in say the imperial system of measurement and then you win the work and now you're like, okay, great, let's write a backlog of stories so we're gonna use story points. So what happened all those hours, all that time that you spent on features and 40 hours and 80 hours and 200 hours or three or whatever and now we're talking in terms of one, two, three, five, eight, 13 story points and in scrum of course you're never supposed to correlate story points to time. Doesn't make sense. Why are we switching from this imperial measurement of time and hours to story points when we actually do the work? First of all, we're duplicating all of that effort and secondly those things don't align and it's just confusing the client because if we're talking about hours then we say, yeah, but we're not actually supposed to talk about hours, I'll talk about story points instead but also hours, it just confuses them. So we do all of our estimates and bids in story points. When we estimate a project now, we write stories even if they're epics, we never talk about hours, we do story points and we use and Susie can talk about this forever. Secret. There's a super secret magic spreadsheet that she's created that is really phenomenal and we would love to share it with people once when it's robust enough to really be able to share. But it takes all these story points, it takes historical data from all of our previous projects and all of that and there's a multiplier that we use based on how difficult we think that the client's gonna be in general and we mean that in a nice way but some clients just have a lot of overhead that you have to deal with and some are super fast and they make decisions quickly and you're churning away and some take weeks to decide things. So we assign some kind of a multiplier and we know what our burn is because there are gonna be four or five people on the team and they're gonna be billing. This is when we start to talk about time because we consider like full time equivalent, part time equivalent. That's how we calculate cost of the project. So we're never thinking about like features and hours. It's always features story points. We total up all the story points and then we have a conversion tool based on historical data and our own experience. Additionally, we will write a few stuff we don't know stories and it's been a little controversial. Some clients are worried that that means that we're padding the estimate but we're trying to be very transparent that it's not stuff we don't know. It's stuff you don't know and you're gonna figure out and want and need as we go along. So here's your bucket. So procurement doesn't love that but everybody else does. And that kind of goes towards your second question which was how do you keep that broad vision? And these things are gonna come up and they're gonna see this shiny thing and say, ooh, I want more of this, I want more of that. And that's where this ready sized backlog at the beginning comes into play. If you have a ready sized backlog and you know that this project is going to be a total of 100 story points and they say, oh, but I want this, this and this and you go and you estimate these new features that they've requested and you say, well, that's 30 story points. So the original plan was to do 100 points of work. Now you want 30 extra story points. Okay, so we're gonna put that in here. So now we've got 130 story points to do. What do we lose? Now we need to lose 30 story points. So when they see something bright and shiny, you say, great, here's all these other shiny things. You're gonna have to give some of those back. And that allows you to focus the conversation and on what is the true MVP, what meets their needs. We've also gone back and said, this doesn't meet your vision. Remember you said, your main business driver was X. Well, now you're actually going against that. And then sometimes they say, oh, I forgot. I got distracted. So sometimes us being the vision holder helps them keep on track because it's a long process. And sometimes they make that conscious decision but at least they have the information to make it as a conscious decision. Yes, we want to spend more money to get this or we wanna drop these other features to get this or we wanna add time, whatever the circumstances may be. I apologize to keep you waiting. There's one more thing I wanna add because you mentioned discovery and then we're talking about vision and all of that. It's really important to have an excellent discovery process and discovery should do a lot of things but at a bare minimum, you need to outline precisely what the project's goals are. They're the goals that the client has as an organization, the goals that the project has in terms of delivery and what problem it's trying to solve, the goals of the individual clients. Some people, as Susie mentioned earlier, they're gonna be fired if this doesn't go well. We need to know that as a vendor, right? Additionally, you as a vendor, as a consultant, you have goals. There are things you wanna get out of this project other than just paying the bills, right? You want something cool to have in your portfolio. You wanna experiment with new technology. You wanna help train their team. You wanna build a lifelong relationship. There are all these things you wanna do. Lay those goals out on the table. Better yet, put them on your project wiki, review them at the demos and at the retros. If you have a physical office, write them on one of those big easel post-its and put it on the wall of a team and look at it every day. Like any time you have a question, should we do A or B, look at the goals. That's one of the ways that you can keep that vision in mind. First of all, you have to have a clearly articulated vision at the beginning and constantly revisit it. And having an excellent discovery process, I think is part of the key. I remember a client who came in and on the second day of the discovery process, they said, you know, I came in yesterday and I saw the post-it notes and the big white board, the big white page that you can flip over and the white board and I was like, oh my God, here we go again. These are the worst. And your process has been great and we love it and we're getting a lot out of it. And so having something that isn't just generic discovery but where you've really put some time into developing what that process is and one of the most useful tools and iterating on that just like being agile. Why don't we wait a minute for questions? Thank you, I'm sorry for the wait there. You've been very patient. Round of applause for the gentlemen who were waiting all this time. Thank you so much. But one more thing. Yeah. I like to focus on product owner or project owner as an important role. We've kind of identified the same. I think a key difference for us is we've almost always wanted that to be on the client side to the point where we're writing it into contracts, who that person is and what their role requires of them. I'm just kind of curious from your perspective along those lines, it's almost more of a sales. We're nodding our heads because we're like, that's a good idea, we want to do that. Okay, continue. So from a sales perspective, what are some of the things you look for as red flags or major concerns or big positives when identifying new clients and who's gonna be healthy for an agile project? So if you sit down and you say to them 10 hours a week, if all you say is I need 10 hours of your time a week and they freak out, then they're not gonna be a good product owner. Because that's about the average of what we need. And I think that number really sort of separates the lead from the chaff because they say like, the reason I hired you is because I don't even have 10 hours a week. And then, but as you've seen from our outline, even if we do the product owner role, they're still the approving stakeholder, which is five hours a week. It's still not nothing. So I think the thing that we've seen a lot is that we ask people to basically take on a new profession by being a product owner. There are people who go to school for being a product owner. They go to conferences and the whole nine yards to learn how to manage a product, but we ask them to take on this new profession for this project and it's hard. It's hard work and it's difficult and understanding then vertical slices and all that is probably one of the most difficult things we see on their side. So we actually spend a lot of time and I was on one project that took 11 months and when we got to the end, we said, now you're a product owner. But we were done. So, but that was, it was still good. So she's in our support process now. And so she's a great client to deal with because she knows exactly how to slice it and define it and be good about writing user story and all that good stuff. So it's hard work to get someone to learn how to be a product owner. And also this person has to be empowered. They have to actually be able to make decisions and one way to try and figure that out, you can try just asking that and they'll say, sure, yeah, I'm in charge of this. Ask them, who do you have to ask for approval? And if they mention anybody else, then that means that like, well, they don't really have all the power, right? Now every organization, you got to run it up the ladder at some point, right? That's normal. But if that list is long, or if they're all kinds of like, well, there's my manager and then like the super manager and then the ultra manager and then the VP, if there are all these chains of approval or whatever, it's gonna be really hard to either yourself be empowered because you're gonna have to go through them or for that person to be empowered. In a situation like that, you may wanna seriously consider whether that's the right fit for your organization because it's gonna be hard to do scrum with them, period. Yes, sir. So we've adopted similar processes over the last 18 to 24 months. The biggest challenge for us has been from a sales and billing perspective. I feel like our clients feel like they shoulder all of the risk with this process. How do you guys deal with that? Do you bill in sprints? Is it still a hard bid at the end? But then, you know, it's gonna be $50,256.08 or like we're billing in 20K every two weeks and it seems to make our clients feel like they're shouldering all the load and it's a tough sell. How do you guys deal with that? They're shouldering because they're not getting what they expected. What do you mean by shouldering the risk? The risk of I'm going to pay you for some services but the, you know, the bike analogy that you used of, it's not done until it's done and this iterative process is sort of difficult for them to grab and that's my interpretation of is that it feels like the clients are shouldering the risk and is there, so the real question is how do you guys bill? Is it by sprint or is it again just one contract lump sum? So I do a lot of sales at Four Kitchens so I'll tell you what I do. There are shops handle this in different ways. I know shops that bill on a weekly basis or a sprintly basis so there's a lump sum. You want us for another sprint? That's another $20,000. We don't do that. I've heard of some shops that just do everything flat fee and then they need to figure it out themselves. You know, we've agreed to do this work for $50,000. We just got to make it work. That's one way to do it. That's not how we work. None of these are wrong. It's just not how we do it. We treat the budget as a cap and we work towards that. It's really important to have a thorough understanding of the project in advance and that's partly helped by having a really excellent discovery process and it's really helped by having that discovery process be a separate engagement early on. If it's a separate engagement early on and you come up with a project plan and you know what you're gonna do and it's part of the deliverables that you are being paid to deliver is the fully sized backlog of stories, you can then very accurately estimate the cost of that project as part of the discovery process. Then you can go to them with the money and you can have that tough conversation about like, okay, here are the things you said you wanna do and all the goals you said you wanna do achieve. Here's how much we think it's actually going to cost. And then we can start to filter through that backlog during more of like a second business development phase to figure out what we're actually gonna do with that work. Plus at that point you've created a relationship and you've created trust with them so they know that you're not trying to just, you know, built them for cash. You're actually trying to do really good work and they're much more willing to discuss the logistics of budgeting and scope and things like that with you because they know that you're not around to take advantage of them. A lot of people think that every consultancy is like a mechanic because like you speak this magical language and you're like, oh, you know, you're trifurbogating agitators busted where it's gonna take $1,000 to replace. Like, sure, okay. You know, we're not dishonest people. You know, we're trying to do good work. So we work against having a fully sized backlog. We know that if we did 10 story points in Sprint 1 and there are nine remaining, then we can do 100 story points. But if there are 200 in the backlog, that budget is gonna go over by 100%. So there's actually two pieces of the budget you have to watch. There's the butts and seats time. So if this person comes to work every day for the next 10 weeks and you bill X number of hours a week, that's one budget. And then you have, this is how many stories we have in the backlog. This is how many sprints we have to do it. This is our velocity. And so you have to constantly balance these two to make sure that you've got enough people to spend the money appropriately. Oh, somebody goes on vacation. Oh, now we've got another week that we can add another Sprint. Oh, okay. But we have twice as many stories in the backlog that we need. So there's constantly the balance of the hour burn because we're all time in materials. So when we were talking about overtime, that was our experience. And if you work the weekend, then you've basically borrowed from a future Sprint. But at the same time, you're burning down stories. So how do you keep those two buckets meaningful and equal? It's hard. It's a lot of work. Also update your client at the end of every Sprint. Here's how much, here's what we burned. Here's how much you have left. No surprises, right? Also do it right after the demo in a separate conversation so they know the value they got. And that's the MVP too. I mean, you can say like, here's what you're gonna get for the MVP. Everybody work towards that. And then let's work on that on phase one or phase two or whatever you wanna call it. Don't call them releases. They hate that. Alpha, they don't understand alpha. So we just call it milestone one. Yes, sir. Hi. So I'm in an account management role at Akidna. And we're fortunate to have a lot of really great clients, but we do have some clients that are driven by board decisions. And despite having very similar processes, we call them project champions because it makes them feel a little more empowered. But at the start of it, when you're in the honeymoon phase, they agree to all of your conditions and they're like, yes, this'll be this way. And I often find sometimes as you get into the longer projects that sometimes they have to start going to the board for more decisions and it kind of degrades. How I'm curious, what are the consequences if you find that happens in a situation? As an account manager, you tend to wanna try to smooth things over and keep things moving and keep a strong client relationship. And you don't want anything to seem punitive or spiteful in the consequence. So I'm wondering if that type of situation arises at your organization, what do you do to try to either get it on track or how does it impact your projects? So I really like math. I really like to show people like your, our velocity is directly impacted by your ability to make decisions. So first sprint, we did 20 points. Sprint 12, we did 10 because it took three times as long for you to get there. So- So you actually would- So you just say math, it's like I, if I took this velocity, we would have gotten here, but now we're here. So what do you wanna do about it? Right, math is fact. Math is not emotional. It doesn't have that connotation. Absolutely, at the end of the day though, there's often very fixed life rates and they can be $200,000 projects that mean a lot to the organization. So I was wondering- And also I think transparency is a big part of it. The fact that they are involved at every step and they have been part of that process. There are definitely those times at the end of the project where it's like, well, we have gone a little bit over here. Why did you let us do that, right? We all kind of went there together. So let's talk about ways. And then we have a frank discussion about what are our options? And I mean, we've had a client where we gave an estimate and it was a fixed bid and the project was clearly going to go way over budget because of some additional complexities that hadn't been uncovered. And we had to sit down with them and say here are some options. And one of those options was we walk away, you don't pay us, you take everything that we've done so far. And one of those options was we just keep going and we take some of those costs on for ourselves. And then there were some options in the middle and we sat down and have a conversation and we came to a decision together and we moved on. And the nice thing about that was the client was super happy about all of the, basically the way that we handled it, that now they're doing a support agreement with us and we're talking about what's our next project going to be together. And they were super happy to settle for less because we said we wanna do the right thing but we only have this much to work with. So help us figure out how to get to this. And sometimes let them know how much you're gonna eat. Yeah. I mean, this is a business relationship. Yeah, we tend to be very transparent. Yeah, yeah. Absolutely, like that totally helps. And just to frame it as, so I do account management too. So I would be very sensitive to how, we're not trying to get out of anything and we're not trying to cheat you and we're not trying to make you feel bad but here are just the facts and we just need to be real about them and let's have an adult conversation about it. What I would do in your case when you have a board or like sometimes we call that like the voice in the shadows who emerges towards the end of a project and suddenly like, wait, what's happening? Nobody talked to me about this, you know. Or whatever. Or we'll need healthcare. Yeah, yeah. So in those cases, like if it's a consistent pattern of the board coming in and wanting to shift all of that stuff, I would ask to speak to the board directly. You know, go, if it's a big enough project, fly out there, go to a board meeting. And just explain like, okay, I'm here to represent the organization that you've hired to do all of this. We've been doing this for years. We've seen things like this happen before. Here's what's going to happen if you continue to do this. We know you're not trying to run anything off the rails but it is our professional duty to tell you that what you're doing is silly and that you need to buckle down and like just figure out what you're gonna do and let's consider all that other stuff maybe a different phase of work. Cheers. Okay, thanks. Sure. All right, last question. Last question. I'm way too short for this microphone. So I'm curious about retrospectives. So you talked a little bit about demos and reviews and I know that sprint is very much an iterative process, not just on the work but on the process. So can you talk about how often you're having retrospectives, how long your sprints are and kind of how you're building that process in? That's a great question and we need to add that to the slides. We do. Because we didn't talk about that at all. We do a retro at the end of each sprint. We do a sprintly retro. We usually do a project retro. And if there's something going on that's a little bit hinky then we can do a retro at any time. I think milestone retros are actually really helpful too because they go back to that original question about vision and goals and that's where you can really sort of say like, okay, we've been doing this for three months now. Are we still on track to the original goal? Do we need to adjust the goals at this point? So your retros are really actually a good thing to add. And our sprints are two weeks. Oh, yeah, two weeks. All right, thank you so very much. You can rate the session here and download the slides. Thank you. Thank you.