A SCRUM Primer

Danny:                    Hello, and welcome to the ThreeWill Podcast. This is Danny Ryan, VP of Business Development, Co-Founder for ThreeWill, and I’ve got Tommy here with me. Tommy is the President and other Co-Founder of ThreeWill. Thanks for joining me, Tommy.

Tommy:                  Glad to be here, Danny.

Danny:                    Awesome. Tommy and I are getting together weekly to talk about topics that are near and dear to us. We started last week where we’re talking about sort of where ThreeWill came from, the idea of focusing in on people, process, and technology. Of those, we sort of wanted to do a primer for this year just to get us kicked off in the process area and do a primer for scrum and talk a little bit about scrum. I think to get us started with this, maybe can you just give me a high level of what is scrum. I guess the word “scrum” comes from what?

Tommy:                  The word “scrum” comes from the term used in rugby and I’m not a rugby player, but from my understanding, a scrum is coming together. You see that where they’re all interlocking, coming together, and trying to move forward with the team. That can look messy, it can look kind of rough, but the objective is to move forward as a team. That’s where that term comes from, originates from, is the rugby term for scrum. That’s what scrum is.

Danny:                    Tell me, I guess I remember for awhile you and I were looking at sort of we wanted to decide on a process that we were going to use at ThreeWill. We went back and forth. This was when fairly early on in the company’s history, we didn’t want to make up our own thing. We wanted it to be something that were books written about, that it was a well-known process. I think we had done, in our early days, had done some stuff with rational stuff and some of the early processes that were involved that were a little bit more formal. Then, over time, we ended up finding out about scrum, finding out about some of the agile processes. Why did we decide to go with scrum?

Tommy:                  Well, you know, when we looked at the different methodologies, we were familiar with RUP, the Rational Unified Process, and it was an iterative process, had some really good things about it. Fairly formal, well-documented. Larger organizations were adopting it. As we started exploring what we wanted in a process that was approachable to our clients, that we didn’t want to spend a lot of time explaining the process, we started getting into delivering to our customers and giving them a five-minute overview, or thirty minutes at the most, to educate them on the process. We found that scrum was the simplest, most straightforward, common-sense approach to getting software development projects done.

Iterative, I think, was key to us. We felt that projects that didn’t do well were ones that were more big-bang type projects where you kind of show them software at the end of the project and if they didn’t like it’s usually you don’t if you don’t see it at the end. There’s a lot left in interpretation if you have very rigorous detailed requirements, and tell people see software working, they don’t know if they like it or not. They like the concept every month or every two weeks or every week to show functional, working software, and that was a very big tenant of scrum.

Then the things that we did that were successful on whatever methodology we used before, we found those common within scrum, so a daily meeting, a daily stand-up that was short and concise. That daily sprint that you have in scrum where you talk about what is accomplished, what is planned, and what’s in the way, and doing that in fifteen minutes or less, that’s a great way to keep the team in sync with each other and not to veer off in a direction that’s not valuable.

Danny:                    That’s a daily meeting that you have, that’s called the daily stand-up, that everybody just answers those three questions?

Tommy:                  Yes.

Danny:                    Okay.

Tommy:                  We do that religiously on our projects. It’s something that we never skip. So critical and important is that daily inspection of the team.

Danny:                    Does the client listen in on that or are they involved in it?

Tommy:                  Clients are always welcome in that and especially if they are team members where they’re doing parts of the project. If they are another developer on the project, if they are helping with driving requirements and mitigating risks related to the project, as much as they can on that daily stand-up, the better the project’s going to be. You might have someone that’s on the customer side that maybe is not doing development, but knows about how to get things done within that organization, how to go get accounts, how to get people’s attention to remove impediments. It’s great to have that type of person on your daily stand-up.

If we keep it to fifteen minutes or less, which we’re good about that, that allows very busy people to participate. If it’s an hour meeting or an hour-and-a-half meeting, that becomes, “Well, I just don’t have time for that.” Yes, we have our customers on meetings. Do we have some that we have zero customer participation? That is the case. I would say those are tougher projects because there’s not as much of an overall, “We are the team,” mentality versus, “Us versus them.”

Danny:                    You mentioned, and something that may be a new term to folks, which is sprints. What’s a sprint?

Tommy:                  A sprint, it’s considered an iteration. People probably have heard the term iteration. That’s a term used in the Rational Unified Process in terms of developing methodology where people talk about having a waterfall process versus an iterative process. An iterative process, you have iterations, and sprint is just another term for iteration.

During that period of time, we look it at as a complete lifecycle of realizing software. You start with requirements. We have user stories that feed into that sprint which is a way to describe what we’re going to work on and, that user story, we have to elaborate on that. We’ll go through more detailed elaboration around what needs to be done to satisfy that requirement and/or do the design required to be able to know what we’re going to build. We will build it and we will test it and we’ll deploy it. We go through the full lifecycle that you would see in a project and get that completed in two weeks.

Danny:                    Two weeks is a typical time frame for this?

Tommy:                  That’s our default. Depending on the organization, that might end up being three weeks if they have some processes that are involved in order to complete a sprint. For example, testing. That requires a longer cycle. Then we might have a three-week sprint. Then if we are doing things that are very small projects, short duration, we need to have that feedback cycle of, “Are we on track?”, and see that more often, maybe a four-week project. We would end up breaking that up into one-week sprints. Two weeks is our default. We find that it’s enough time to get something of value done that the client is happy to see and gives us the feedback that we need to continue to be on track.

Danny:                    What’s, I guess, the first sprint that you have? I think it’s called, is it like Sprint 0, where you first start putting together the product backlog. Talk me through that.

Tommy:                  The Sprint 0 is really a sprint to baseline and vet out enough detail to understand the order of your product backlog, get enough of a running head start on more detailed requirements that are going to feed into the early sprints, and to make sure that whatever we’ve estimated, we validate that we’ve gone a little layer deeper into the detail to make sure we’re budgeted appropriately and the timeline’s appropriate.

Sprint 0 can be a day where we’re just going through and just tying off some loose ends to get a project started. Sometimes it can be two weeks, depending on the complexity of the project. In some cases, people look at that as elaboration or envisioning. Those types of terms might be used that are similar to what you do in a Sprint 0. We’ll also get the team kind of started, something of the logistical pieces like getting accounts in place, developer environment setup, and those are some things that don’t necessarily produce a completed feature as much as block-and-tackle the logistics that we want to do in the beginning of the project.

Danny:                    In another podcast, talked with Bruce about creating sales estimates, and I like to think that the Sprint 0 starts in the sales process. Very early on, like to start to put together those user stories, like to start to put together sort of sizing of the backlog, and putting together those estimates so that we start out with an appropriate budget for the project which is really difficult to do. You don’t have all the information, yet you need to put together a budget that is appropriate for what you’re trying to do.

Tommy:                  Right, and that’s probably what we feel is very powerful in adopting this methodology is we traditionally would, in the sales process, try to sell an envisioning project, so we could get in the door and have engagement that would allow us to size and estimate an effort. In scrum, we find that we can put appropriate time boxes around certain requirements and give a directional budget that, in most cases, is an adequate budget that allows us to engage and the customer has a sense of, “How much do I need to invest to get to the finish line?” Versus a lot of times they have to invest to even have the conversation.

We have some engagements where things are just not enough meat on the bones to estimate something where it’s important for the customer to move forward and get to a point where they know what they need to estimate and we’ll do an engagement around helping through that process and vetting out, “What are your requirements?” We find, in a lot of cases, customers know enough to be able to set a budget and if we can do that within a couple of days, it’s very empowering. We give them a lot of detail and information to say, “Yes, I want to spend money to go do these things in this timeline.”

Then the Sprint 0 is to say, “Okay, we got to a good initial budget. Let’s validate that that budget’s appropriate before taking a deeper dive into some riskier areas of the project.” What we find is that typically we’re not expanding the budget. You would think that, “Well, that’s maybe a typical outcome of a Sprint 0,” but usually what the outcome is is we clarify the needs and we can use that budget to slot-in the things that are most important. The things that are not as important we can push out to something in the future and make room for things that maybe weren’t revealed in the first estimation.

What we know our customers are in the situation of, they don’t like dipping into the well often. If we go and estimate something, we will go into that Sprint 0 to say, “Yes, we said it’s 100k, now when we get into the details, well, we didn’t know about this. This is extra work.” We talk about other things in the backlog that are maybe lower priority or things that we can do in a cheaper way that are low-cost alternatives. We always like to give them multiple choices to choose from to satisfy that requirement and some are more expensive, some are cheaper. Depending on how important that requirement is, we might go with a more expensive option with the items that are higher priority, and then the things that are not as important, we find ways to be frugal with their budget.

Danny:                    That’s one of the things from an outsider looking at projects I’ve liked with scrum. It allows for the customer to have the flexibility to change their mind because it’s not always so much that it’s their business situation can change, priorities can change inside the organization, so it allows for them to have that flexibility, which I think is really important. Over time, they can optimize their budget. They can decide what is priority versus what isn’t. Along those lines, I think we often look for what’s in scrum called a “product owner”. Tell me a little bit more about what a product owner is.

Tommy:                  A product owner is that person that, in a sense, owns the requirements, represents the requirements for their organization, and is going to be our primary point of contact to prioritize things, to let out the scope. They might delegate some of that to say, “Here’s the subject matter expert on that particular story in the product backlog, you’ve never spent time with them,” but if it comes to push versus shove and what’s going to fall in and out, our product owner is our key point of contact to make those decisions.

In most cases, we’d like that to be more of a business stakeholder that is the person driving the need and will realize the value versus someone that’s just a technical stand-in that’s more like a project manager. Ideally for us, we’re working with the true person that needs this, that’s evangelizing this, and representing this as something that’s of value to do in the organization.

That product owner is one that, if you get a good product owner, usually it’s a very busy person, the person that’s making a difference in their organization. Again, with scrum being a very lightweight methodology, we can get them involved in very short bursts of time where there’s high value in those conversations and they’re not having to go through very detailed, laborious steps that they just give up early on to be involved in the project.

Danny:                    They might not be a part of the daily stand-up, but they may be part of the sprint review, which is what happens when you start out the sprint and the sprint-

Tommy:                  Sprint planning to start out the sprint and then sprint review to complete the sprint.

Danny:                    That’s right. I got them mixed up. Sprint planning to start out, sprint review to wrap it up, so that those two meetings are probably very important to have the product owner in on those meetings.

Tommy:                  Yeah, we get nervous when the product owner is not in those meetings. Those are, if you would say mandatory, those would be the mandatory meetings we’d want to see a product owner involved. For one, in the planning, we’re determining what’s going to get pulled into the sprint. We need to understand that priority. Sometimes it’s a technical reason why go to them first, but most cases, we’re trying to bring in something that has higher business value or something that needs to be built upon in terms of additional features on top of that core feature.

We need them in that planning. We do a lot of that planning sometimes without the product owner to kind of get through the nitty gritty of what are all the sprint tasks that are needed to satisfy that story in the product backlog. We typically don’t take them through that detailed step of, “Well, we need tests for one hour. We need to have development of this method and encoding to get that feature to work.”

Danny:                    The more validating stuff that probably we’ve already got down on paper for them.

Tommy:                  We’ll bring in more of, “Is this the right product backlog to bring into scope?” We won’t necessarily talk about the sausage. [crosstalk 00:18:50]

Danny:                    Keep the customer away from the sausage making. I think that’s a very important thing. Talking about roles. What’s the scrum master?

Tommy:                  A scrum master is the person that facilitates the process for the team. They’re making sure that the daily stand-ups are occurring. They’re usually facilitating the sprint planning and sprint review. A lot of times they’re running down the impediments. They’re protecting the team from things that are going to slow them down, for the items that are going after them.

In the world of other methodologies, you hear the word “project manager”. We’ve made the mistake and called sometimes the people that play scrum master in our projects a “project manager,” or even hired people that are project managers. We’ve kind of learned from that. Project manager is, in a lot of cases, the command and control, divvying out the tasks, and setting a plan and sticking to this plan. In scrum, the concept of self is self-organizing teams and that there’s more energy, there’s more commitment, there’s more accomplished when the team is making their own commitments. In order for that to happen, you need to have a scrum master facilitating. Are we making sure that all the things that came into that sprint there is an owner assigned? They won’t necessarily assign it as much as making sure that it is been taken from the team.

They’re also doing things on our projects that are more formal. Things like status reports and making sure that meetings are scheduled. Some of those logistical steps that most developers want to work on fixing, problem solving, getting that next feature developed versus scheduling meetings and filling out reports. Scrum master takes on that responsibility, too.

Danny:                    Any other key roles that you would point out when doing a primer like this on scrum?

Tommy:                  You know, in terms of roles, there’s the team, there’s the scrum master, and then there’s the product owner. That’s all you need when it comes to roles. Then when you think about artifacts or meetings, we talked about the daily stand-up. Sometimes people call that the daily scrum. We’ve called it daily stand-up because scrum can be a confusing term, so we’ve kept that out and called it stand-up versus daily scrum.

We’ve talked about sprint planning, we’ve talked about sprint reviews. One thing to mention on sprint reviews, we see it as a celebration. The team coming together to say, “Look what we’ve done. Look at what we’ve accomplished.” For the product owner to see that, get excited, and give us feedback of, “Does that feel right? Is that the right direction we’re headed?,” or, “Yes, I said this, it actually looks like this and that’s not exactly what I want.” We want that feedback because that’s important for us to correct along the way.

The other things that you have, we have an extra that is basically the storyboard or the work board that you would have for a scrum team, which lists out the backlog and then shows backlog as it progresses from sitting there in the queue to it’s in process to it’s done. That’s an important aspect of scrum. Then, there’s two charts that we keep track of. One is a sprint burndown and one is, I’d say, a private backlog burndown. The sprint burndown is the same. We’ve committed to ten story points, it’s these stories that came in. Where are we in terms of the number of hours we’re consuming and how much time do we have left? Because it’s kind of a sprint, a race to finish off that sprint by the end.

Danny:                    Talk to me more about capacity and velocity. I think you’re starting to get into that a little bit with the burndown chart.

Tommy:                  Right. When you look at a sprint burndown, you go into that sprint and let’s say you have a two-person team, it’s two weeks long, forty hours per person, it’s 160 hours that’s going to come into that sprint in terms of the capacity and that capacity says, “All right, we’ve got 160 hours. What can we get accomplished? Pulling in based on priority, what is the next backlog? This backlog is five story points and we don’t know how much time that’s going to take really until we dig into the details and we start saying, okay, if we do this, we need to do this, this, this, this, and this task.”

If I add it up for the team, that’s going to be 40 hours of effort. I’ve consumed 40 hours out of that 160 hours of capacity. I continue to pull in product backlog until I’ve reached my capacity or maybe 80-90% of my capacity because there might be some tasks that I didn’t think of from day one that come up along the way or sometimes you can be aggressive and say, “This is going to take an hour,” when it actually takes two hours. That is some of the terminology that comes into a sprint burndown.

Then the product backlog burndown is saying, “We’ve got 100 story points that are a part of this project. We want to make sure we’re on pace by the end of the budget, the end of the timeline. We’ve completed all the stories that are in scope, so we’re plotting after each sprint how far are we working down that product backlog and do we have a trajectory that brings this wherever you want to land at the end of the project?”

Danny:                    One of them tells you whether for that sprint whether you’re going to be able to make, to accomplish what you need to within that sprint, and then the other one’s more around the project itself?

Tommy:                  Yes, yeah, the overall health of the project and the health of the sprint. What’s really neat about agile is the thing that can typically make a project fail is the lack of intensity and commitment or the excess of commitment that’s in a project. When you look at, say, a waterfall project, a lot of times you’re spending too much time in certain activities. You’re at a slower pace. Then you get to, “Oh crap, we’re [inaudible 00:26:16] here. We’ve got one month left. We’ve got a lot to do.” Then you start working overtime and cramming a lot of things in.

When you look at sprints, what we’re trying to do is shorten that overall project lifecycle into a two-week lifecycle that you’re creating a pace and we’re going to go after it with some sense of urgency that you want to be done by the end of the sprint. If we do that, we bring in the right amount that doesn’t overload the team, then we can establish a pace from the beginning and not let, “Oh, there’s four weeks left in the project,” to be the catalyst that starts making us go at a good pace. For us, it gives us a sense of accountability of, “Let’s break up this big project into smaller projects in a sense and let’s show that we can get these mini projects done on time and give confidence to our customer that we can make and keep commitments to stay on track with the project.”

Danny:                    I think this is important for us because I think you and I, we’re pretty passionate about staying balanced and this is sort of a naturally-occurring thing that even maybe there is a sprint where there was too much taken on. You can adjust in the next sprint and say, “Maybe I can’t take on that many story points. Maybe I need to …”, so it almost builds into the system a way of adjusting. You’re doing the things that need to happen sooner. I think, also, I wanted to ask you about, I’ve heard this mentioned a lot, which is fail early. What does that mean?

Tommy:                  That whole sense of bringing it into sprints and you can get real with that and let’s say you bring in ten story points, you’ve got ten sprints, and it’s a hundred stories in the overall project, and you only get five story points accomplished. That tells you. In other projects where you’re divvying all design up front and all development and all testing, you really don’t get a sense of how long does it take to get this thing built. You’re getting percentage completes along the way and that can be very misleading.

When you have sprints and I only get five out of the ten done, you’ve got to make some tough decisions. You’ve got to decide, “All right, do I need to cut some of the scope and is that appropriate and is that a mutually-agreeable with you and the client?” You’re just saying factually, “This is what it’s looking like. What should we do?” Because most of the work we do is timed material. We take it on as mentally almost as fixed bid. We kind of look at it as, “We want to get this done with the budget because that’s usually a very happy customer.” To ask for more money is usually not a good conversation. We look at that.

If we fail early, we only got five out of the ten, and if we stay on the pace at five out of ten, we’re only going to get half of this thing done. Let’s have those tough conversations. Let’s say, “All right, we’re working together with you and really, in reality, we thought it was going to be at this pace of ten stories per sprint, but in reality, it’s going to take five.” Maybe it’s the processes that are in place within the organization. Maybe it’s just the dynamics of how particular a product owner is. The pace of the team itself. The typical impediments that come up with that type of organization.

We’d rather say, “This is not going to work,” after we’ve done a fifth of the project than after we’ve done more than three-quarters of the project. We’re not putting our customer in a really bad position. In a tough position early on, but a much better position than, “I’ve spent almost all my budget and if I only get half of it, I can’t launch it at all. I can’t use it. It has no value for me.”

Danny:                    I’m sure there’s consulting companies out there where that’s their mode of operation, right? “Let’s just use up all the budget and go ask for more, then use up the budget and go ask for more.”

Tommy:                  I don’t know that that’s the motivation as much as, “Well, the customer created that problem. Poor customer. They’ve done that, now we’ll just have to spend more money.”

Danny:                    Let’s change order them to death. I think a part of it is it doesn’t allow for any flexibility as part of the process so that when someone changes their mind, which they inevitably do and they should, business changes, whatever reason, is to allow for those changes to occur where you’re not saying, “Oh, you originally said this and now you’re saying this. It’s going to cost you this much,” or, “We’re going to charge this much more for it.” I like how scrum allows for you to change your mind on things. I think that’s a very important thing to emphasize.

Tommy:                  It is and I think scrum operates underneath having a high-trust environment. Scrum doesn’t work as well in a low-trust environment. Low-trust environments tend to lend themselves to more of a waterfall arrangement where every step of the way, you’re tweaking the contract in a sense. You’re making incremental commitments and you’re very careful about your commitments. Within scrum, I think, it’s a team effort and it gives a lot of flexibility to change your mind, to go in different directions, and still achieve the business goal.

If you’re working in a low-trust environment, people can nitpick and it can come from both sides. It can come from the client picking on, “Well, you didn’t do this to this specification, to this detail,” or from the consultant side to say, “Well, you didn’t do this, so you need to change work as you got a new requirement or you gave us more detail.”

We find that with agility of scrum as an agile methodology, we can adjust and spend their money in the highest-value way. We’re really working on things that are important to them as they discover what’s most important. When you’re in other contractual relationships like a waterfall, you can almost say, “Well, you told me to do this and I’m going to do all that and charge you all that and it doesn’t matter if you changed your mind. You can’t because if you change your mind, you’re going to have pay for that and pay for your new idea.” We’re always try to say, “Let’s be careful how we go into that until you really know what you want, so when you know what you want, we can build that for you versus build something that we’re guessing that you want.”

Danny:                    We could talk for hours and, therefore, I think there’s some other things we could probably hit on, but let’s hit on them in a follow-up podcast. I think what we were trying to do today, I think this is a good primer on getting started with learning more about scrum. I appreciate you taking the time to do this, Tom, it was a great conversation.

Tommy:                  Sure. Yeah. Like I said before we even started the podcast, all you have to do is wind me up. You say, “process,” and I can go and go and go.

Danny:                    Process. Go.

Tommy:                  I think part of the passion behind process is I think process is a way to take technology, map it to a business problem in a way that adapts to a personal need to the individual. It’s very relational. Scrum is a methodology that I use those relationships over the tools and the process, really. It’s very relationship-focused and very collaborative. We love collaborative applications and we care about serving our customers and that’s a big reason why we picked scrum. Not because it protects us, but because it serves our clients well and gives them better value at the end of the day.

That’s been one of those decisions that we made that I don’t think we’ve ever regretted going down the scrum path. It really hasn’t had too many drawbacks. It’s been so positive. Our clients love it. Usually, one of the things that we hear the most from a customer satisfaction survey, “What did you like the most?”, and it’s process. Which kind of throws you off when you first see that because you think, “Oh, that’s kind of dry. That’s boring.” At the end of the day, it’s what helped them address their pain. That’s what we’re all about doing is coming in and addressing pain.

Danny:                    Yeah, it’s been interesting for me because just sort of the marketing stuff, outsourcing some of that, to be on the other side. I think it’s opened my eyes a little bit about what is it like to go after something where you’re outsourcing something to get some help. I just see so many positive things coming from taking this approach, that I really think it is, it makes us very different from what other organizations I know.

There’s even been organizations where we, after the project, they think one of the best things about the project was the process we used. Then they’d want to adopt it internally. I think that’s one of those things that’s just awesome to see. “This project went so well, we want to try and use this same type of process internally for other teams.” I think that’s a great sign that, hey, we’re doing something right. We’ll do sometimes projects with them and rub off on them. Yes, we do daily stand-ups. Yes, all this sort of habits that are a part of scrum, to see the client want to adopt those habits really feels like we’re making a very positive change inside their organization.

Good stuff. Thanks, everybody. If you’ve made it this far, I’m impressed. Thanks for listening in. Absolutely drop by our website, We’ll have some follow-up topics over the next couple weeks on process. I’ve also got some good stuff coming with some people, interviews, so you can learn more about the people here at ThreeWill. Then of course technology. We’ll talk plenty of technology because we love to do that as well. We’ll have some technology topics coming up as well. Thanks so much for listening and have a great day. Thanks, Tom.

Tommy:                  All right. Thank you, Danny.

Danny:                    Bye-bye.

Danny RyanA SCRUM Primer

1 comment

Join the conversation

Join the conversation

This site uses Akismet to reduce spam. Learn how your comment data is processed.