eCommerce Q&A   /     Scrum Project Management Framework

Shownotes:

Can you tell us about your ecommerce pain points? http://sellry.com/survey

Want to learn more about scrum? https://www.scrum.org/

Check out this TED talk, recommendation courtesy of Noelle. https://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family

Transcripts:

Michael: Hello, folks, and welcome to eCommerce Q&A. This is the podcast where store owners, directors of eCommerce, and eCommerce managers can stay up-to-date on the latest tools and technologies in eCommerce. I'll be joined on the show by my colleague and partner-in-crime, Dillon Holst. Our goal is to handle one or two questions per episode. You can check us out on the web at eCommerceQA.tv. There, you'll be able to get in touch, ask us questions, and just generally participate.

Dillon: Hey, everybody, my name is Dillon Holst, and I am joined today by Noelle of Sellry Commerce. Noelle, how are you?

Noelle: I'm doing great.

Dillon: Glad to hear it. Today, we're going to be talking about project management methodologies, specifically agile and the Scrum methodology of project management. Really, what we want to do is give you guys an overview of Scrum, but more specifically, as Scrum is a methodology designed for software development, we want to give you some ideas on how you might be able to use Scrum outside of software development or even technical development itself. I can tell you from personal experience that, as somebody who's been through Scrum training -- I have a Scrum certificate -- I have found the principles to be extremely helpful, not just within the project management field, but also in your daily routine of either business management, sales, whatever it might be. There are philosophies and methodologies within Scrum that can help you in pretty much any area in terms of being more efficient, using your time properly, and all that fun stuff. Noelle, I know you have some questions that you're going to ask ...

Noelle: I do.

Dillon: ... and we can just have a conversation about agile and Scrum in general.

Noelle: Awesome. Yeah, and I totally agree with you on Scrum's principles being applicable to whatever it is we do, so I'm excited to get to it.

Dillon: Sounds good.

Noelle: The first question is ... We're just going to give a little brief on Scrum ...

Dillon: Sure.

Noelle: ... so could you just explain the difference between Scrum and other PM methodologies?

Dillon: Sure. The easiest way for me to do that is to describe the methodology that I'm most familiar with aside from agile, which would be a waterfall style of management. I'm sure a lot of people out there listening, they understand waterfall and how it works. Pretty simple. You start with a scoping process, where you figure out all of the components that need to go into your project. You create a road map and a plan for how you're going to execute, and then you go from point A to point B, point B being the completed final product that should be theoretically available to release to whoever the user base is.

Noelle: So it's like one step for everything.

Dillon: Yeah, exactly. Right. Point A to point B. One shot, and you're done. You hope that you've got everything you need upfront because otherwise, at the end of the project, you're gonna have a bad time. Scrum, on the other hand, is designed to be a more iterative -- wow, I did not say that correctly -- iterative method of development. Really, what the goal is is to ... At the end of each sprint -- and Scrum defines a sprint as around a 2-week process -- at the end of each sprint, you're gonna have a minimum viable product or an MVP that is usable in some way. As opposed to saying point A, point B, you're developing something on the go. You've got a team of people that are dedicated to, at the end of each iteration, if you will, creating an actual working product.

Noelle: Yeah, I already like Scrum more, just from what you're saying. It sounds better. Moving on, with understanding Scrum, can you explain the three components of the team and their functions?

Dillon: Sure, yeah. When you say the three components, we're really talking about roles within a Scrum team, the first being the product owner. The product owner is the individual who basically gets to decide what is going into the product. What does the MVP look like? He doesn't do this just by himself, but ultimately he is the one responsible for what the end product is supposed to be defined as.

The next person is the ScrumMaster. The ScrumMaster is the individual responsible for actually running the sprint, making sure that the team is on track, that the team has everything it needs to develop properly, whatever it might be. The ScrumMaster also interfaces between, to some extent, the product owner and the Scrum team, although the product owner should, in my opinion, make himself available to the Scrum team should the need arise in terms of defining a product feature, that kind of thing. The ScrumMaster is the person responsible for making sure that the minimum viable product is completed at the end of the two-week sprint. That doesn't mean that necessarily you're gonna have done everything you said you would do at the end of the sprint, but that's the goal.

Noelle: So does the ScrumMaster basically interface with the product owner and the team, and then the ScrumMaster keeps everything rolling. Is that ...

Dillon: Exactly. Perfectly said. The ScrumMaster's job is basically to make sure that everything is, in terms of a timeline, on track, and he also runs the daily stand-ups that happen within a Scrum sprint. He is the guy that runs the kickoff sprint meeting and then also the retrospective at the end of the sprint, where the team comes together and talks about things that went well, things that didn't go well, and what things might change in the next iteration, the next sprint.

The last component is the team itself. In my opinion, the most important part, although they're all equally important. A ScrumMaster would say, "We're all equally important," but the Scrum team itself is the heart and soul of the development process. The product owner and also the ScrumMaster have to rely heavily on the team to actually understand the concept and to build the concept out as the sprint progresses.

Noelle: Would the product owner and the ScrumMaster really rely on the team to be the experts in a sense?

Dillon: The experts and also they're the ones that are, at the end of the day, going to say ... most likely, in most scenarios that I envision, they're the ones that are going to say yeah, this is possible, no, this is not possible.

Noelle: Gotcha. Okay. Cool. It looks like the next point is the five principles of Scrum. Can you outline those and explain how they're used?

Dillon: Yeah, of course. I don't know that I can do it justice in the amount of time that we have, but the first one is the idea that our decision-making processes are based on the knowledge that we've gained from our previous experiences. In the context of Scrum, this means the planning phase before the first sprint starts. Then you move on to the next sprint, and you've got two weeks of time to develop an MVP product, right? Well, when you go into the next sprint, you're going to have all the knowledge that you've gained from your experience in that previous sprint to decide what's going to happen in the next sprint. It's the idea of empiricism, right? All the knowledge that we had ... I mean not all of it, but a lot of it comes from the experiences that we've had, and you want to try to make decisions based on that because it's more scientific.

Noelle: Yeah, and I think it also provides an element of trust for the client that they know we're not just shooting from the hip, but we're actually delivering stuff that has, to a certain extent, been tried and tested in past experience.

Dillon: The next one is the idea of self-organization. For me personally, this comes into play when you're thinking about your team as a whole because your team isn't doing it. You've gotta have everyone on the same page, That means when you put them in a position where they have to be self-organized, is that going to ... are they going to step up to the plate, or is that going to be a problem? If it's a problem, then it affects the rest of the team in a negative way.

Noelle: This whole self-organization is so important, not just in Scrum, but obviously for any team because if you can't ... Basically, if they're not going to step up to the plate that's the point where a lot of times you just have to let them go because you have to have that ... Basically, there has to be that performance, on-time, organization, everything in sync to get the right kind of results.

Dillon: This ties into the next one, which is collaboration. Specifically, within a development or a project management framework, when you're working with a group of other people, you have to be aware of what everybody else is working on because context matters, right?

Noelle: Big picture, right.

Dillon: Exactly. You have to know how your work is going to affect not only other people's work, but a project as a whole. That means communicating effectively with your team members as to what you're working on and making sure that you're using all the tools at your disposal to develop effectively or make decisions effectively. It's as simple as making sure that you're aware of what's going on around you and the context of the situation and making proper decisions, decisions that are not going to negatively affect the rest of your team members.

Noelle: Or the product.

Dillon: Or the product. The next one is this idea of timeboxing, which Scrum talks about quite a lot. Basically, the idea is you want to allot certain amounts of time to fix certain problems. Obviously, this is going to help manage your time better, but specifically, when you go into a planning phase of any project, it gives you the opportunity to allot certain amounts of time to certain things. You're not the only one making the decision on how long something should take. It's a collaborative effort to decide this should probably take this amount of time. You get estimates from all your team members, and then you maybe make an average or something. Whatever it takes to come up with something that everybody is comfortable with and make sure that you are not sending too much time on one particular thing and you're forgetting something else, making sure that you're not spending too much energy on something that you don't understand fully.

It's a time management framework that makes a big difference. It goes a long way, not just within project management, but also if you're doing it from a sales perspective, if it's your sales team, or from your marketing or business development teams, this idea of allotting certain amounts of time to certain things, and then holding yourself to that -- that's the important part.

Noelle: I think it is two things. One, like you mention, it makes sure you're not spending too much time on something, but two, let's say someone gets discouraged and they want to give up, they want to quit. If they have timebox, they're literally held to it. It can kind of help people get over that hump of, "Dang, this isn't working." It can help push them over that, and there's real benefit to that.

Dillon: Agreed. And then the last one, Noelle, is this idea of iterative development. We've been talking about this concept; we haven't really put a name to it. But it's this idea that everything that you're doing, you're gonna take that, and then that's what your base is for the rest of your decisions and for the rest of the product development phase. Let's say you have X product that has a certain number of features and you complete it, and now you're gonna move on to the next set of features. Well, all those features are gonna be based off the previous features that you've already developed.

This is not something that happens within a waterfall project management scenario, but that concept gives you the ability to build something that people are going to use and be comfortable with. It describes that as a process as opposed to just trying to throw darts at a dartboard and hope that they stick. Because that's what's not good about waterfall, often, is we think we know what our clients want, we think we know what the users are going to want, and we build it, but at the end of the day we're not 100% sure who is gonna matter.

Noelle: There's one point several years back where I was actually writing a cookbook. It was amazing for me to see how what you have in your mind is so different than when you're actually holding a tangible or virtual product, is so different. So the benefit that we deliver to clients through doing one round, then another round, then another round ... it's tremendous because it really allows you to cut out what doesn't need to be there, perfect what is important, and just create a product that's really killer, so I love that.

In a minute, I want to talk about Scrum's values, Scrum's five values, but first I want to jump to ... there's a lot of good things about Scrum, okay, but what type of project does not need Scrum?

Dillon: I would say that any project that you understand the technology that you're working with completely, and you know exactly what your users are going to want or what your client is going to want. If you know those things upfront, then maybe you don't need Scrum because ... It's true, building iteratively is not going to be as fast as scoping a project out from the beginning and just building it in one shot. It's not going to be as fast, so maybe you don't need it. But if there's any doubt as to what your users are going to need or what your client is going to want, or if you don't understand the technology completely and you're learning it as you build, Scrum is just absolutely invaluable.

Noelle: So Scrum basically gives the padding for the unknown or gives the padding for the change, whereas waterfall doesn't give that padding, so you've gotta know what you want, exactly what you want ...

Dillon: Yeah, exactly, but not only does it give it the padding, it sets the expectation that that padding is the point of why we're doing this.

Noelle: Which is so good because then the client is expecting it, then it's not like, "What are you doing?" It's expected, and it feels more gentle. To me, it feels like it's more of a gentle process of handling the new, the unknown, figuring out what we want ... it's maybe more relationally beneficial as well.

Dillon: That's a great way of describing it. I would say that collaboration in general is a more genuine development process. Rather than you having this idea ... you, as the provider, having this idea of what you think your client wants and then building it, working as a team with your client to first describe the product and then build the product. Though I think that if you've gotten to the place where you've sold your client on ... or maybe your client wanted you to use Scrum in the first place, but if you've gotten to the place where you've sold your client on the idea of Scrum, you're in a great place to build a really fantastic product.

Noelle: Yes, yeah, totally agree. One more question before we touch on the values. What is essential to have in place for the Scrum management to work?

Dillon: I would say having the right people. By that, I mean people that understand the Scrum process, that understand it, the agile methodology, and that bought into it. If you understand it, but actually understanding the value of ... not understanding the value, but knowing exactly why we're choosing this over something else, knowing why we're choosing agile over waterfall. People that understand that are gonna be better equipped to be a part of a unit, be a part of a Scrum team. I would say that's probably the most important thing, is to have everybody bought into the system, client included.

Noelle: Yeah, definitely. Before we wrap up here ... Couple more questions. Can you touch on Scrum's values?

Dillon: Sure. And again, these values are subjective in the sense that one team may look at values a specific way and they may utilize them or talk about them in a specific way, and some other team, some other person, they might do it completely differently. It's really how do these things apply to you. I'll explain how they apply to me, the first one being focus. It's not a mantra, but it's a way of remembering that what I do affects other people, and it affects the project as a whole. Focus on the things that I know to be true, the things that I know are important, such as making sure that what I'm doing matters in the grand scheme of things, making sure that what I do is visible to my teammates, making sure that what I do isn't conflicting with what the stated goals of the project are, that kind of thing. The second ...

Noelle: It's almost discipline. Discipline almost seems to merge with that.

Dillon: Keeping the goal in sight at all times.

Noelle: Yes, yeah. I love that. Yeah.

Dillon: Number two and number three are connected to each other, in my opinion. Courage and openness. The courage to be open and say, "Look, this is not working for me," or, "I think we could do this a better way," and explaining that to your teammates in a respectful manner. Also, being open to listen to what other people have to say and accept what they say at face value. I think often we forget that people are going to react to things differently than we would naturally react to them, so just keeping that in mind and focusing on maintaining the relationship of the team and the cohesion of the team and putting that above our own personal opinion or our own personal agenda is super important.

The next one would be ... we've discussed this, but the next one is just commitment. Be committed to the process, be committed to the product, be committed to providing something of value. And then the final one is just respect. Respect your team members -- I sound like a broken record, I feel like, but you can't understate how important these people are. You have to respect the people around you for this kind of process to work.

Noelle: To me -- focus, courage, openness, commitment, respect -- all of those are crucial, again, not just for Scrum, they're crucial for building a team, period. I would say especially when you're in a virtual team and you're working over the wires, you're not face-to-face, these things are so important to implement. Also, this makes me think of families. So much of this stuff applies to a family and how ... Basically, business principles relate to family; family relates to business. They're core, good values. It doesn't matter what you apply them to. They're just good.

So wrapping up here, Dillon, I wanted to get a couple thoughts from you. More personal, not just on the Scrum methodology, but your take on it. For someone who's new to Scrum, what would your favorite element be and what would your least favorite be?

Dillon: I'll say that when I was new to Scrum, the collaborative environment was not just novel, but an extremely welcome change. I came from a waterfall background, so being in an environment where people are actually working together ... Not that people aren't working together in a waterfall environment, but it's designed specifically with collaboration in mind, Scrum, that is. That was the best thing to me; the thing that was most valuable to me. The thing that I don't like ... if there's anything that I don't like, it's the fact that if you don't have the right people, in the sense that you've got people that either ... they have to be the center of what's going on at all times, or they have too much to say in every single meeting, then it's not going to work. That just comes back to the values. Do you have people that are going to respect the process and respect their teammates? If so, it's going to work, but Scrum is only as good as the people that are within the system ...

Noelle: Yeah, that's interesting.

Dillon: Yeah, it's only as good as you make it, or as the people that you bring in.

Noelle: One last question for you is ... It seems like so much of the success of a project that utilizes Scrum is based on the ScrumMaster, and I don't think everybody would be a good ScrumMaster. I don't. What would you say ... You are a ScrumMaster ...

Dillon: I'm actually a product owner.

Noelle: You're a product ... really?

Dillon: Yeah.

Noelle: What character traits or qualities would you say a company should really keep in mind when they're looking to hire a ScrumMaster?

Dillon: You gotta find somebody who understands how to make sure that everybody's voice gets heard, number one, and number two, finds a way to make team members useful. Not just in the context of the project, but useful to the other team members. You're almost like a counselor, right? You go in, and you find the problems, and you fix the problems, in the context of team dynamics. You gotta have somebody that's A) willing to do that and B) capable of doing that to be the ScrumMaster.

Noelle: Cool. Awesome. Well, any closing thoughts, or are we good?

Dillon: Closing thoughts ... I would say, do your own research and find out whether or not you think this is something that would be beneficial to you. I don't know that it's going to be beneficial to everybody out there, but I will say that understanding the principles, at the least, will give you a feel for what a lot of people are doing in terms of creating a productive environment for their clients, creating a productive environment for their projects. Maybe at some point in the future, you're going to have a project where you need an agile methodology to pull off a successful project, so keep this in mind and ... Keep it in mind.

Noelle: Yeah. One little note. I am going to try to include the link below. There's a TED talk that talks about how agile can actually be implemented into the family, and it's awesome. So just kind of gives a little bit of a taste of how agile or Scrum principles can be implemented in more than just what they're for.

Dillon: Cool.

Noelle: Anyways, well, it was awesome talking. Thanks for sharing your knowledge, Dillon, and I appreciate the time.

Dillon: Yep. Thank you, Noelle.

Noelle: All right-y, take care. Buh-bye.