Applying Agile Scrum to CPQ Development and Support
There are many benefits to an agile approach to CPQ development and support. Join this session to learn how to improve your value delivery, be agile enough to adjust to the needs of the business, achieve higher-end user adoption, and improve solution design.
Full Transcript
[music]
Mino Serna: Thank you for joining me at the end of this wonderful week. My name is Mino Serna. We'll get this figured out once conference is over, get all the technical difficulties over. So, I'm with Enhanced Tech Solutions, independent consultant, partnering with PROS. I've been in the sales operations, sales enablement space for over 10 or over 15 years. Been working with directly with PROS for just over 10 years. I've done quite a strategic solution, design, architecture, development, support, the whole gamut in the CPQ space with PROS. Leading into my current role, I was working previously with the real largest medical device company, Medtronic. I was able to start that implementation 10 years ago with the original Cameleon CPQ that did transition into the PROS smart CPQ that we have now. Started with three small workflows in that environment, built it out and was able to grow it, scale it independently, and then transition into the smart CPQ into pricing and really build out that where handling over three quarters of a billion dollars in revenue through one work stream in that tool....
Mino Serna: Starting very small, scaling it and really living the ecosystem in the cycle throughout the entire program. So, come with quite a bit of experience, quite a bit of knowledge, and quite a bit of relationship with PROS, the tool and everyone around it. Today we're gonna be talking about utilizing Agile Scrum for CPQ Development Support Delivery. A lot of this is gonna be, we've heard from a lot of other presentations that we've had in regards to about recognizing ROI, getting that out there. CPQ is where we wanna be. There is ROI and that we've heard it. The question we're gonna ask here is, is it worth applying scrum, agile scrum to your delivery and support model? Is that gonna be a benefit to us? So, a quote from a CFO that I've worked with when we're trying to get some projects off the ground is that CPQ is one of the most complex and difficult projects you can take on.
Mino Serna: However, CPQ projects have one of the highest ROIs out of any project. So true. No one ever said that CPQ is gonna be easy. Oh, no problem. We'll get this in, we'll be done. It is not, it's the space that we live in. Does this look familiar? Yesterday, Andres put this up and just reinforces is that from Forrester that we had the platform generates 400% ROI in three years. It's there. The ROI is there. We got the right tool, we got the right partners, we got the right pieces. And the question is, we're gonna recognize it. It's there no matter how we deliver it, whether it be Waterfall, whether it be Agile, it's there. The real question is is what benefits do we get? And how quick can we recognize that benefit. If we can get this ROI recognized sooner, if we can build better relationships, if we can have a better tool process throughout it, that's where it really comes into it.
Mino Serna: Some of it is measurable. That's, our profits that we're gonna measure to see that otherwise are just, you don't measure it, it's just intangible. The relationships we build with our partners, with our stakeholders, with our customers, that's what it's really about. And that's where those recognitions also come in and it all starts from the beginning. All right, I'm gonna go ahead and just give some quick overviews about what the waterfall methodologies and the Scrum kind of little compare contrast right here. And really that way we can call out where these benefits start coming from going through. So, it's gonna be a little bit high level of a introduction for those of you that haven't done Scrum, but it's really just kind of really call where those benefits come from. How many people are using some type of an Agile delivery method right now?
Mino Serna: Okay. How about as a scrum? Anybody with actual Scrum Agile? Okay, very familiar. Good. For those of you that are not, there is a transition. That's one of the things that we'll be talking about is what that transition, where they're at. And one of the things we'll also be talking about is really the... It's not always gonna be a clean cut straight Agile approach. That'd be ideal. It's just not out there. As we know with Waterfall, it is very linear, top to bottom. We get those requirements. We start working through our development cycle until we get to the deploying maintenance. Agile is an iterative approach of this. Learning from what we're doing, being able to get those requirements design, start developing, get feedback and iterate. Improve, build from what we got a little bit more granularity is gonna be Agile Scrum framework.
Mino Serna: Here are the different steps. We are gonna walk through these in segments throughout this presentation and show where these values come from. But it is about the introduction of your project. You're getting your backlog, building those requirements, getting those refined and small enough to a sprint backlog so you can deliver in your sprint, two to four weeks sprint cycle to deliver value, get feedback, bring it back, and then reprioritize, re-evaluate, and then move again. So, being able to be Agile with our teams, figure out what we need to do. All right? Now, does this look familiar? Anybody that was here for day one, very person right out the gate started talking with Michael Wu. Well, where's my, anyways, over here we talked, notice the cyclical cycle. This is AI learning, this is machine learning model analytics and results.
Mino Serna: It sounds like feedback. There's a whole feedback section here. And decisions. Actions from a person, not from a machine. If it's good enough for AI learning, if it's good enough for our machine learning that we wanna move to anyways, why can't we do that in our development, our delivery. We get that real feedback and course correct. Do what we need to do till we have refined product. And that's really what it's about optimizing. This whole session optimizing profit, optimizing what we're doing, optimizing our processes, and this will allow us to refine as we go, allows us to make the right decisions, prioritize, and keep the engagement in there. All right. So no matter what type of a delivery method you use, whether it's gonna be waterfall or whether it's going to be agile, we face the same pain points when it comes to our CPQ projects. From a business stakeholder perspective, we've heard this theme multiple times already this week there's disruptions.
Mino Serna: Do we know the pandemic was gonna be here? Supply chain issues, inflation, those type of things. They happen. We have to react quickly. The business is constantly innovating, right? No one's in here to say, I love where I'm at. I'm gonna stay right where I'm at for eternity, we want to grow, we want to move, we need to adapt, right? So, our business is always changing long development life cycles. That's completely contradictory to the innovation and the quick changes. Sales cannot manage on a IT delivery framework timeframe. Hey, we got a new product coming out, great, we'll be nine months before we get that end for you. No, we're gonna market next week. Things happen, we have to adjust. And then scope creep. Well that's a result of us innovating. Is it really, especially in a delivery cycle you have this long six month implementation. Is it scope creep or is that we had to readjust because something changed, right? We have to be innovative and be able to adapt. And then user adoption, right? That's everywhere. Every single session, somebody mentions users and adoption and got tools not worth, or then if no one's going to use it.
Mino Serna: So how do you build that user adoption? That's just a common theme and you will see that this process... This framework really helps bring that up, okay. From a delivery standpoint, we have from an IT side, delivery teams, we have pain points that are commonalities as well. The complexities. We already know CPQ is not an easy space. It is a complex area. Project transparency, being having that relationship, the open communications, that transparency of where the project is, where we're going. Are we going to the vision? How many people have seen on long waterfall project? It's green. It's green, it's green around track. We're red, whatever happened to yellow, right? How did we go from one to the next overnight, right? The optimistic approach is great, but really.
Mino Serna: It just happens. Having that transparency is always a difficult piece of it. Stakeholder engagement, yes, I had them early in the beginning of the cycle, but it's so long they started dropping off. They're just kind of getting feedback check-ins or do I have the right people here to be able to get the needs I have? And then, looking at it from a perspective on my building to a moving target. So, is it the actual project delivery? Do I have break fixes that are in here for what's already in production? Do I have enhancements for the tool that's already in there? Because I'm now doing project on top of it. How do we handle those? Do they work together? Do they work off to the sides? Being able to address those type of things. And that's something that we can have to bring in for make sure that we're on pace, that we're giving what we want to our users.
Mino Serna: All right? So, waterfall methodology, as we said, it is linear, right? It's like being on that river there for this waterfall. You're looking ahead. I know where I wanna to go. I wanna get to those rainbows because it's beautiful over there, right? So I have my vision, I have my requirements, I know where I'm gonna get, but it's linear. You get that tipping point, it's a straight shot. You're getting to the bottom right? You can hit all the steps to the bottom, but you get to the bottom, that's where we're gonna deliver. So it's out there. That's where that clear "vision" it comes into. It's clear from where I'm at now, but as we start going and learning more, it's not as clear anymore. Because it's like, "Oh, I didn't think about that. I didn't think about that part either." So it's really how clear can you really be upfront?
Mino Serna: Waterfall projects are constrained, budget, scope, time. And that leads directly to... Well, we know it's gonna be a big bang at the end of that project. So, what can I fit in during those constraints? Something's gotta give, right? And our stakeholders are used to asking for, "If I don't ask for it now, I will never get it." Because phase two... That's a year from now, it very well could not happen. There may not be budget then, the direction of the business may change. There's different things. It's like, if I don't ask for it, now, phase two may never get here. How many times have we seen band-aids be permanent solutions or MVPs that just never get any further, right? Because phase two, the budget, whatever it is, it just doesn't happen. Those are the pieces for it. So here we go. Clear product vision. We know we have certain things. We know what the market needs. We know based off our collaboration at the beginning of waterfall, of what our vision that we want the product to be.
Mino Serna: And we have an idea of what we can accept as an MVP. There's two different things that are in here. But then you start going linearly, we get to development requirements are there, well, the developers may not have a clear understanding of where they're at. We need more time. We need to figure out what these requirements are, understand where it's at. They think they get a beta out to release. It's like, here's what we thought based on requirements. The user gets to it. It's like that did not match up. That's we're off target. All right? Now is once we go to deliver, I'll let this speak for itself. How many have seen these? So true, right? There's this beautiful picture of what sales is sold, what they think we're gonna get. We did an update, we've made some changes to make better the time it hit live. Oh, boy. We've seen it. We gotta do something about it. All right, so the question is, is Agile Scrum the right answer?
Mino Serna: Let's just talk a little bit about what Agile Scrum really is and what makes it work versus the foundation over here. These are the five core principles of Agile Scrum, respect, openness, courage, focus, commitment. Those are all terms that we've heard also throughout this conference, right? And it's about our players that are in the Scrum space that are part of our team, our stakeholders, all adhering to that. Being open, being able to communicate, being ready to commit to this project and our product, right? The respect. Huge, right? Being able to have that with each other, have that collaboration. If you're not respecting what others voices are you don't have that trust factor. It's all about building that trust. That leads into our three pillars, transparency, inspection, adaption. Hey, those all sound familiar too. So you have the transparency of where we are in the project, what's in our backlog, what we're taking on next, how we're going to deliver the inspection is that review? What do we have?
Mino Serna: Let's get that feedback. Are we talking to each other? Are we getting where we wanna go? And then the adaptation. How do we go from here once we have that feedback? It's not just a feedback, put in the suggestion box and we'll get to it someday. We have real time feedback, let's get on a backlog, let's prioritize those. Maybe sometimes they need to pull up or go back, but it's really getting that, how are we going to adapt? And that's what gives us our Agile Scrum. Okay. Now with those core principles, with those pillars, it's about Scrum having the right people in the room. You can't hide in the corner if it's around the room. You have everyone involved. They're all part of this, and everyone has a voice. It's those key principles that make it happen. I love the CPQ space. I'm passionate about it. So I'll probably start getting animated and start talking a little bit more but I love this space. It is the hub of sales and finance and everything else. It's the tool. It's what gets us going. It's not necessarily the process, right?
Mino Serna: It's not the overall, but it is the tool that everyone has vested interest in. Everyone on this screen has some type of a vested interest in CPQ. Some people are directly interacting with it. They're gonna be utilizing the tool, analyzing it. Some people are gonna be feeding it with those leads. The opportunities of the prospects. Some are gonna be reporting off of it, recognizing all the way down to delivery recognition and all is tied to CPQ in there somewhere along the way. So, it's having the right people in the room. And Scrum does that. It brings in all of our stakeholders. It keeps them in the conversation, keeps them full transparency as to what we're building when we're building it, and that they're accounted for. Keeps them in alignment, right? How many people have seen pricing, the pricing teams and sales team being us versus them. Strategic pricing is like, "Okay, here's our vision. Here's what we're our strategy that we're gonna go with. We're gonna have our set baselines here." And sales is like, "Great I have a quota. That's a great suggestion, but I'm gonna sell it here."
Mino Serna: And you've got your price leakage. It starts going through. So, by keeping everyone in the same page collaborating together, we have the right people in the room to start refining our tool where we want it to go. So, again, a little bit more high level overview of the Scrum model. We're gonna be breaking these up into sections. That way we can see how they work. But just so you can see end to end, that backlog continually maintained. It's not something you just one and done. You don't start at the beginning of the project and say, "Here's my requirements and now let's go set scope." It's, here's where we start from what we know now, and then it'll get refined as we get feedback and figure out what we know. It's the sprint backlog, taking that backlog and bringing it down to a smaller chunk that we can handle within the two to four weeks. All right? And that sprint cycle is defined by the team and it's a set. Once it's set, it's there. So we give the transparency and value to our stakeholders for feedback. They can set their watch by how often we're gonna deliver, right?
Mino Serna: We set it, every three weeks you are going to, we're gonna be in this room and everyone, all my stakeholders are gonna be here for my review if you choose to be. But you're all here. You're gonna have all the visibility to it. You can now see, give feedback of what this value we're bringing into you and we will be talking about it. And then there's that review cycle, which goes both ends down to the bottom from the user perspective as well as part of the scrum team. And we're really gonna dive into that as we come along. Okay. So again, just kind of what we saw from Waterfall at the start of your project. You have a vision. I know where I wanna get to, I wanna get to the hills. So, for those of you that have never been to Denver, you're missing the mountain. So, I'm giving you your chance to see them in this presentation, okay? You'll never miss what's missing 'cause it's here. But when we start, we're looking down the road. I know where I want to go, I wanna get there. But the key difference in the acknowledgement that you have with Agile Scrum is you right away acknowledge and admit, I don't know what I don't know.
Mino Serna: I know what I want to do for a business, but I don't know what, especially for new customers that are coming on, right? We've been talking to sales, we talked about the tool, it has all these potentials, but I don't truly know what that tool can do for me or how it can do with my processes to really enhance where I'm at. It's not about lifting and shifting what I'm doing now. There's a reason we're looking for new tools or try to improve. We wanna improve our processes, we want to improve what we're doing with the tool. So, the only way you're really gonna get to that is actually start touching it, seeing it, feeling it, and acknowledging that I can tell you what I wanna go to now what I think I want and that gives me a good starting point. But now how do we adjust? How do we keep moving forward? And how do we get to what we really want? So, that we talked about having the right people in the room. We talked about refining that vision, right? So, we start from the beginning with the vision, but it gets, it's iterative.
Mino Serna: We keep looking at it. Is it the right vision? Does it stay the same? Did something major change quickly that now my vision has to shift pandemic, right? Some people had certain sales models that they were doing pandemic hits. Like we gotta pivot immediately, right? If you're in the middle of a development cycle, your whole project's scrapped because now you have to do it. But if you're keeping your pulse on it, you can start to adapt and bring those into what you're currently doing and then those requirements. So the question is, now what? Now that we know we don't know. I know that you know that, I know that you know type of thing, right? It's we don't know what we don't know. Now what, well here's what Scrum does as a visual, right? It's not waterfall. We know where I want to go to get to that peak, but we do it in segments. Some have higher value delivery than others. But we have these switchbacks, we get to the end of one cycle. We look back where we've been, what did we do? Where are we going? What is gonna be the best path for this next sprint? I'm not gonna say my next sprint is getting all the way to the end. I know that's not it. I gotta take it in steps.
Mino Serna: So, we cut switch back, work our way again. We hit pitfalls. Some have been gained more ground than others, right? And that's just natural. You're gonna take on bigger items of value in there. You're gonna take on smaller chunks. But so there's different, it's not a set amount that you're gonna deliver at any time. 'Cause it's not a matter of quantity, it's a matter of quality. It's about that value that you deliver during that sprint. And so this is a great representation. What that really Scrum path looks like. It's being able to adapt and adjust and still make your progress as you're going through. Okay? So, Scrum and Colton I'm just referring to it as a sprint prep. So it's that backlog that we talked about. That's your initial requirements that you're starting with from at the beginning inception. But that backlog is constantly being maintained, right? So, as you get feedback, they're like, "Hey, I didn't know that this is possible. Can we or should we do this?" This is where it sets apart from being scope creep. Because you're now learning and refining it and it may be a feature that you wanna do in the future, but it doesn't get lost.
Mino Serna: How many times do those feature requests? Ooh, it'd be great if someday we can do this. Oh, we'll put it onto a parking lot item and never see it for four years. It gets put into the backlog, it gets in there, it's managed. In that way it can get prioritized either in this project later down the road 'cause it's continual, it's a continual improvement process. But it doesn't get lost. It gets accounted for and it's there. So you can start seeing A, that one, that wishlist item ties directly with some of the stuff we're doing. Let's pull that in. It's an easy value delivery, 'cause it's there. You have ability to all these possibilities. And then the sprint backlog, it's that refinement of what do we wanna pull in as a team. It's a self collaborating team, the Scrum Team, that's doing this made up of your Scrum Master. You got your Scrum masters, your product owners and your developers. Your product owner sometimes will be from the business, sometimes from IT. Again, it's a self-organizing team of who's in this room. It doesn't have to be by title.
Mino Serna: I've had some scrum teams that are mostly business folks and that we have offshore, other people that are using the developing. It could be that I've had a project owner that was from the IT side just 'cause of where we were in the project. But it's something that has a pulse of the business and it can help prioritize and be the voice of the business and help that transparency and communication. So it's all about that piece and that's what that sprint backlog in the prep is, is like what does a team want to commit to bringing in for this two... Let's just call it a three week sprint, and what do we think is achievable during that time? And together from as a product owner, which piece is gonna be the best value to go during this sprint. If it's a brand new build, maybe foundational from a architectural, 'cause I need this as a foundational piece of my deployment. It could be actually when you start getting into features, I'm gonna get this feature in now, 'cause I can start applying it now. So it's really chunking those up into a tangible piece and something that I can build off of and get feedback off of.
Mino Serna: Okay, so it's used gonna be sharpening the vision, intake of those requirements, backlog refinement, and ultimately on track course correct or pivot. This is that opportunity to review. Are we still on track? Is that vision that I set initially still what I'm trying to get to, did something major change? Is there something that I just learned during that sprint that says, "Whoa, hold on. I never even accounted for that." So we need to reprioritize some of the stuff that we did because this was just out there. So, it's that gives that great opportunity. But the prioritization leading into it is key. That prioritization comes from the business. It comes from that collaboration of what we needed building it in there. So the scrum sprint itself. There's a few things that we have in here. One, because of that prep, it is a set scope that you're bringing into that sprint for that three weeks. You know what we're going to accomplish, what we're shooting to accomplish. From day one, the backlog user stories are refined, that way day one, they come into sprint, they can start developing.
Mino Serna: It's not like, "Okay, here's my user stories, now let's spend three days of discovery and trying to clarify what I need." These cases should be refined enough that they can start day one, hit the ground running, "Here's what I'm gonna start doing in developing." All right. It's a team approach. So, based on the prioritization, your backlog items are gonna be agreed upon by the team. Not everyone on that team may have the skillset skill set for what's gonna be developed at that time. So, everyone ships in and learns what they can do, support the team, but that also strengthens your team. So their skill sets skillsets, instead of just being in those verticals, start getting wide. They start having cross-training abilities. They start learning what the other teams are doing. It just allows them to support each other in a team fashion much better. So, it starts building a better collaboration amongst the team as well. They're working together, they're accomplishing what we want to do. One of the big keys is that definition of done.
Mino Serna: This is one of the other areas that is very beneficial to where you're at because everyone's working off of that definition of done. If you're in a Jira, I prefer a Jira method to be able to capture everything 'cause that documentation, your requirements, all of your use case, everything is tied together in all in one location. You keep building from it. So, if you're doing a continuous program, you're building from it, you have an enhancement, you can look back to the original requirements that are there. You can see what original definitions are done. Were used to build it in the first place. How many projects that you have, we're gonna do an enhancement, well let's go do another four weeks of rediscovery and find out where the project really is. If you're working off a continual improvement process off of a Jira, it's all there. You can see where they've changed. This is where that whole... Where I brought up about support enhancements and new product fixes.
Mino Serna: If you're working together off of the same backlog, those items get into it and you can see it's no longer a working target. We're like, "These are related. I see how they're tied together. I see where the requirements come from, the dependencies." That's part of it too. Pulling at strings, where are these dependencies at within my features that I didn't... That's part of the unknowns. Like if I pull at this string, what am I gonna do next? Well, if you have it in one spot, you have that and the definition does that allows everyone to improve your UAT, 'cause they're all working off the same piece that system testers test it, one way users get it and it's like, "You miss something." Well, it's already predefined. You already know what we're trying to build to and how we're gonna test it. Accountability, that Daily Scrum back to transparency trust is right there. Daily Scrum gives us that. Okay. And that Daily Scrum is every day getting the team in and using that time as a short touch base, giving that transparency of, "What I committed to do yesterday, here's what I'm going to commit to do tomorrow. If there's any blockers, anything that I need to get me moving forward, that's what it's gonna be."
Mino Serna: It's given that touch base, that transparency, really being able to talk about what I've done, what I need to be able to commit again for tomorrow, and then the next day do it again. Where am I at? It's not just like, "Yep, everything's still on course fine." No, what did you commit to? Restate it? What have you done? What are you going to commit to again? And then we keep that transparent. Again, back to that, how do we go from green to red? No in between. You are fully aware of where this at, the team's aware of where we're at. And then this scrum cycle is a full development life cycle in one sprint. You're going all the way from the development to the user testing. And the key is we have real users doing our testing. You have a true user acceptance testing. So, you have real users in the short sprint evaluating that value that you just put out there and giving you that feedback. So, you have them in front of it, they can start giving those feedbacks now instead of waiting six months and then realizing, "Hey, can you guys do something about this or that?" And now you're like, "Okay, now we got it. It's gonna delay us." Making quick adjustments, quick touch bases.
Mino Serna: Okay. Now one of the sprint review, after that sprint's done, we put the value out. The number one piece, the one, and this is probably one of the biggest change management pieces for everyone that's never done it before, is don't let perfect get in the way of good. It's iterative. It's iterative by design. Don't let perfect get in the way of good. You gotta get something out there so we can review it so we can get it in front of people, so we can see what we want to do and how, if it's going the right way. So, get something out there, we're gonna iterate on it, right? It's going to be out there. And that's where, that's that change part that for our stakeholders, they see it they're like, "But that's not doing everything out." Yeah, it's not there yet, but it is something to base off of, right? How do we go is, are we on the right track? Because if I'm off foundationally from the get go, if I wait at six months, I can totally just scrap it and we've gotta start over again. But if I could at least get that initial touch point is this, are we gauging that we are on track, we are delivering what we wanna deliver.
Mino Serna: Perfect. That's where we're at or something changed. Something changed, our business changed, our product changed. Something happened then we know we can adjust for that. So, don't let perfect get in the way of good. We are gonna iterate that stakeholder clear expectation. Again, setting that watch our stakeholders know that every three weeks we're gonna have this sprint review. We're gonna go over what was done. And it's only complete work that we took into that sprint that we completed during the sprint that's gonna be reviewed here, right? This is open, honest transparency that here's what met all of our definition of done. If it got all the way to the end, but it didn't get that finer user acceptance testing signed off, it's not done. It does not get presented in review, 'cause now you're setting up a promise that may not be there, right? Because after this review process, that priority may change, it may shift, that may not be the priority. So it's like, y"Yes, we're 99% of the way done, but I really need to focus on this other piece. Let's just put that back on the shelf. We'll pick it up once we go."
Mino Serna: Or it does get carryover, but that's okay, right? It's about the value you deliver. It's not about the quantity, it's not how much you got done in that sprint. It's about what kind of value you deliver during that sprint. That's really what we're looking for. And there we give that real time feedback. We're soliciting feedback from everyone that's in that room. We wanna know, is this what you're expecting? Is this what you're seeing? What do you think? Is it good, bad, ugly, whatever it is, we need to know this is part of it. This is for you. We wanna know what that feedback is and being able to work from it. And then again, back to that transparency. It's showing them what we have while we're seeing it while we're building. Okay, so the part we didn't cut on there, it was that top loop about the Scrum team retrospective part of the review that's specific for it. And this is key to those Scrum values, open, courage, focus, respect, commitment. And that sprint retrospective is a Vegas environment. What happens in retrospective stays in retrospective. All right. This is a safe place for that scrum team to live. So they can be completely open, they can have the respect.
Mino Serna: This is that team that's working day to day, shoulder to shoulder, working together. And they review what happened during that sprint. Not the whole project, that sprint. How are we not just gonna iterate the product that we're doing, but our delivery? How does the scrum team... Did we do what we need to do? Are we getting the right help we need, are we doing the right things? But they can be completely open, honest, and just let it fly. 'Cause nothing there is gonna leave that room. It's for them to come together and reevaluate what they're going to do next to deliver. So, what happens in retrospective stays there. Sorry. No leaders are allowed in that room. They're not there, right? A leader director comes in and says, "Hey, I wanna sit in on it." People just immediately climb up. Nope. It can't be as open as I wanna be, right? It's our scrum master that's host that's gonna get there. And it's about battery in our system, but it is that safe place. So that is one of the key pieces about the iteration. The feedback from the stakeholders helps the process, helps the product, the retrospective helps the delivery and helps us self-organize to keep improving and keeping that moving forward.
Mino Serna: So, one of the big activities I like to do folk, there's multiple different ways to get through this review. One of them here is the sailboat method. And this one here is really gonna be like, top right is gonna be the wind. What's the wind in our sails? What helped move us forward during this sprint, these last three weeks, what really helped me be successful? What helped the team be successful? And everyone that's in there from the scrum team is encouraged to be at and asked and committing to providing this information, right? No one should be sitting silent. What things were the anchors? What things slowed us down, got in our way that just were made it difficult that we either did or did not meet what we wanted to do? What are the rocks or risks we see ahead of us? Let's start looking ahead. Based on what we saw here, do we see things that are gonna block us from our next sprint? What are we gonna be doing? And then that goal and vision, our vision going into the sprint was here. Did we get there? Did we not? Are we still on the right vision over the overall product?
Mino Serna: What is our goal for this next sprint? And being able to self-organize again as a team. What are we gonna commit to together to either keep the same, to change in our process or do something different, right? But it's the team to organize together. The scrum framework is not a process. It's not a set way to do it. It is an iterative learning way to deliver. So, every scrum team's gonna act a little bit different. I've had people come up, what's the best process to handle this? Well, this other team did it this way. It's not the best practice. The best practice is what you define for your team. What's gonna make you the most successful most with the most proficient at what you do. That's gonna be the best practice for you. It's the best practice for yourself not industry-wide. It's gonna be... You can get some ideas from what other people do, but you still have to formulate your own best practice.
Mino Serna: All right, so this kind of sums it up, right? Best quote from Mofiki, the past can hurt, but the way I see it, you can either run from it or you can learn from it. Scrum Agile, machine learning is all about learning and changing, adapting to what you've just done. Looking back, quick feedback. It hurts less to fail. You fail quickly. React quickly, right? And that's one thing that Scrum does allow you to do is your teams and they're not used to hearing it. And this is where you get leadership buy-in. That they should be able to hear the say this as well, it's okay to fail. In this environment you're encouraged to fail. I'd rather you learn and fail now in a three week sprint than fail completely on a full project after six months. And we just waste, and have to start over again. So, if you're gonna fail, fail quick, it's gonna happen. Let's learn from it and let's adjust. So let's start getting to the end of this here. What's applying Scrum, right here. Profit's gonna come from CPQ. We've already talked about that.
Mino Serna: CPQ, PROS is the right solution. It's the right tool. Profit's there. You've already picked the project, you've already picked the tool. So, revenue recognition's gonna go up, price and automation's gonna go up, market shares gonna go up. You have the right tool, you have the right process, you have things. It's how quickly do we start recognizing on pieces of those that we can start putting into play immediately. Operating costs., bring those things down, 'cause we can start getting process improvement sooner in some places if it gets prioritized. Price leakage, avoiding that us versus them on pricing and sales, right? They're all in the same room. They start collaborating on the same vision and process. Time to market, how quickly can I make a change and get it out there and be the first one in there to either get new products out, make a change rather than waiting through that IT development lifecycle of, okay, another six months and we just gotta get this right. It allows us to move quicker. Those are things that are measured.
Mino Serna: In the space I am as a BRM, the biggest benefit overall to the project, to the tool, to your overall user acceptance is really that stakeholder relationship. You give trust, you build trust, you give that transparency. They're part of the process. The system is for you by you. They're now vested in what we're doing, what we're building. 'Cause they have that feedback. They're being listened to, they were making actions on it. So, they are invested in what's going on. And that trickles down for every level of that from the sales teams that are gonna be using it from the leaders and people that are gonna reporting off it. So, that's where it comes. So you improve on engagement, the transparency, the value delivery. They see this throughout the entire process quickly. Culture, it's a culture of success of winning. How many burnout projects have you had from your teams? That's like, "We've been at this for months and we haven't delivered anything yet and they're just getting burnt down and worn out." And just like there's no success.
Mino Serna: You finally deliver, okay, two weeks later we're starting our next project, right? You don't even have a chance to bask in your glory. But every three weeks you have value. You're seeing that value there. The team feels good, 'cause every time we're producing something, there's always something there. So, the culture greatly improves. And then there's that mission harmonization. Everyone's in the room, they're talking, they have the same ideas. We're building to the same goal. So, we get to get the harmonization across all of our groups. So, sounds great, it's awesome process, but there are things to consider if you haven't made the transition yet. One is how do you get everyone trained? What are you going to do to approach your teams to actually start utilizing an Agile Scrum? Do you have a scrum master or a team that's already in place that you can start implementing. But then there's also the change management with it. So there's the people that are gonna be doing it, the scrum teams are made up of both business side and IT or whoever PMO, however that's going to work.
Mino Serna: But having that change management, not just for the teams that are in the scrum team itself, but the stakeholders, everyone that's gonna be involved, they're so used to that, MVP being such a negative connotation, 'cause it's like if I don't ask for it now, then I'm never gonna get it. Or that's where I'm gonna be stuck with on an MVP. So, I stopped using MVP completely. It's a primary delivery, right? This is what I'm gonna give you first, 'cause we're gonna iterate on it, right? Minimum viable product. Just that no viable, that means it can live on its own. No, this is our primary delivery, 'cause I know I'm gonna get you more and I'm gonna keep in making it better for you. Scrum or fall, it's gonna be necessary. It's gonna be necessary. We have to do that scope. There's gonna be times that we just have large capital. No one wants to just write a blank cheque and then go to the CFO and say, "Hey, can you just keep that blank cheque for me? 'Cause we're gonna start building a project. Well what am I gonna get?"
Mino Serna: And then we'll figure it out, right? It's not gonna happen. So, it's something you do have to set those scopes the time, the budget, that part, and then deliver in an Agile format within those timeframes. But giving yourself that ability to adjust and shift to the business needs during the delivery. Funding model, this is gonna go directly tied with delivery and support. Your new implementation projects are typically gonna be your capital expense. So, that's where you have your straight budget up front. Once you start getting into support so your break fixes your any enhancements that go on. There's an operational side, so they're two different, usually you're gonna have an operating expense and a budget and then your capital expense. So, what those aren't funded in the same spot. How do we go Agile's intend for an iterative delivery ongoing, keep this thing moving, keep going further.
Mino Serna: So, it's really about figuring out how that's gonna get funded and what you're gonna put in place. And so that way your teams can work together. But working from Jira environment where you have one backlog no matter what you're doing, whether it be support delivery enhancements, everyone has the same picture, they're all going from it and it reduces that time of rediscovery everyone. There's no more moving targets. You get to work together and collaborate throughout. So, this is really the things that you would want to think about as you're going into it. But there are obviously many benefits and it's that speed of delivery of that ROI. When we're gonna recognition those benefits, those values, and the value we gain from our customers, from our stakeholders, from anybody that's involved in the process. 'Cause they get to see it, live it, and really own their own system. So with that, I'll go ahead and end right here and open up questions.
[music]