scrum-migration.jpg

Using SCRUM on Migration Projects

Danny:Hello, this is Danny Ryan. Welcome to The ThreeWill Podcast, I’m here with Tommy. Tommy thank you for joining.

 

Tommy:Glad to be here Danny.

 

Danny:Awesome, thanks for getting together here on a weekly basis, it’s nice to see your smiling face.

 

Tommy:Sure, it’s good to be here.

 

Danny:We’ve had a couple of podcasts leading up to this topic that we’re going to cover today, which is about the process that we use on doing migrations. I know we’ve been doing some complex migrations recently. It seems like really trying to get our customers to get over onto Office 365 has been one of the challenges that folks are seeing. We’re seeing a lot of projects related to this. For folks who might not know we us Scrum. Scrum is one of the Agile processes that is out there. There are some small modifications that we make just for the fact that we’re dealing with an external client, working with a client, but for the most part we’re using the fundamentals of what Scrum is about. What we wanted to talk about today is maybe any of the modifications that we might make, or maybe even just pose the question, does Scrum work with what we’re doing on these migration projects?

 

Tommy:First of all Danny thank you for the opportunity to geek out on process.

 

Danny:Oh jeez.

 

Tommy:I don’t get this opportunity too often and I don’t believe you let me do this. Yes we can geek on processes.

 

Danny:This is a sign of true love Tommy.

 

Tommy:Yes.

 

Danny:I love you my brother. I love you. I will sit here and listen to you about process for the next, don’t say 30 or 40 minutes. Maybe I’ll give you 15 minutes, how about that?

 

Tommy:Okay, 15. [crosstalk] 15.

 

Danny:Okay, ready? Crank them up, ready, 1, 2, 3 and go.

 

Tommy:Yeah, the process as it relates to migration. We’ve really enjoyed using Scrum as our methodology for doing custom implementations and the work that we do with SharePoint (Scrum on migration). As we’ve approached migrations we thought about using Scrum, and should Scrum be the methodology that we use? That’s what we use today and it’s working for us. I was taking some time recently to step and think about, is that the right choice? Are we just forcing it down the path of Scrum because that’s what we know and we’re comfortable with?

 

I posed that question out to our Yammer group and had some really good feedback on that. The question came up, should we use Scrum? What are the options to evaluate it against? I said, “There’s really any option.” Is there something better than Scrum to do these migration projects? When you see a migration you automatically think about, there are distinct phases when you approach a migration. You have a step, some kind of analysis type step, or people might call envisioning of what is this scope of this migration? What’s the bounds? What are we trying to accomplish as a part of this migration?

 

That goes to another phase which is a planning phase, is, okay this is our scope let’s do the proper amount of planning to know how this is going to fit into the grand scheme of things. Because you can’t just be willy nilly about going after a migration. There’s a organizational impact, it’s not just planning for the work you’re doing to make that migration occur but how does this fit into the grand scheme of things and how can we do this and minimize disruption to the organization.

 

Danny:Yeah it seems like communication is just … This is typically things that we might be working with our client, but ultimately our client’s responsible for the communication that goes out to the people who are using what you’re migrating off of and onto.

 

Tommy:That’s such a huge part of a successful migration, is the communication’s piece. Just like real estate it’s location, location, location, migration it’s communications, communications, communications.

 

Danny:Good [crosstalk]

 

Tommy:If you do not do that you’re destined to have a lot of pain in that process.

 

Danny:I know for a lot of the Jive to SharePoint migrations that we’ve been doing we do them with the workshop upfront and then we have the project afterwards. It sounds like what we’re doing is those … Maybe those first 2 steps during the workshop and then coming up with the plan afterwards.

 

Tommy:Yeah, when you look at those workshops at the end of the day it’s helping a organization decide, should I do this? What’s the rough budget for going after this? Especially with the Jive to SharePoint migrations it’s, okay I’ve got this in Jive, where does it go conceptually over into SharePoint. What we do in these workshops is we’re doing an inventory for them in an educational piece to let them know what is involved of this process of moving from Jive to SharePoint. We come out of that and we’ve done some of the analysis piece basically, some of the planning, really, really rough side of the planning side. It’s really enough planning to arrive at a budget so you can make an ROI decision and you can get a sense of, can I get this done in time?

 

Because a lot of times the approach with these migrations is, okay I’ve got a renewal, we’re ready to move and it’s going to be financially advantageous to move by this day. Our workshop allows them to understand what are they going to do and how much is it going to cost. Then we really need to go through all those steps, they might be compressed after our workshop but we’re still doing a certain amount of detailed analysis and planning before we get into some of the more implementation steps.

 

Danny:As you know I find it refreshing that there’s a deadline out there, because for a lot of typical collaboration types of projects that we’re doing where there isn’t a deadline to get something done by a certain period of time, it’s sometimes tough to make a decision whether to do it or not to do it. It’s just nice to have something. Fairly early on when working with clients who want to do migrations I start putting together and action plan around it, which is saying we do this during this time, we do the workshop here, we do this next, and sort of work our way backwards. It’s one of those things as a good project manager I] want to give a sense of urgency at the right time. If you don’t spell out, “Hey guys, really it’s like … I know we need to move over in October of this year, but if you back things out, we need to get a services agreement in place right now if we’re going to make it.”

 

Tommy:When we’re doing those we’re estimating certain things, one is the actual physical migration and the other is what types of enhancements do we need to make as a part of that generic process and tooling. What additional scripts or enhancements to the tool needs to take place? Do you have anything that needs to be custom built on the other end? Let’s say maybe you’re using for the case of Jive, you’ve got a landing page in Jive that has widgets and it’s arranged in a certain way. Maybe we need to build that on the SharePoint side so we can give the user a similar experience when they show up at the new location, when the previous location is shut down.

 

When you look at those steps, the analysis and planning, what comes right after that is what we call configure and develop. Configure and develop is, what do we need to configure in the tool and the environments to run a migration, and then what do we need to develop to enhance the kind of out of the box migration experience. That might be from the tooling or the destination side to create some things custom to get a better adoption after this is migrated.

 

Then we go into a pilot and we go into an actual production migration, and then a stabilization transition to get that platform finalized so you can shut down the previous environment. With those phases, the way I look at it when I put my Scrum hat on is I look at each of these phases-

 

Danny:You have a Scrum hat? Wait a minute.

 

Tommy:I do, I do.

 

Danny:You have a Scrum hat.

 

Tommy:It’s kind of messy.

 

Danny:Where is it? You keep that by your desk? You pull that out when somebody takes the wrong move?

 

Tommy:I wear a few hats around here.

 

Danny:You wear so many hats you don’t have hair on your head, neither do I but that’s not the reason, that’s a whole nother thing. Go ahead, sorry. You were saying about a Scrum hat?

 

Tommy:When you’re look at these phases … Let me get back to my process please. When you’re looking at a phase, I can draw the analogy of that phase is like a release in Scrum. When you have a release, within that release you have sprints and within that you have your daily cycles. What we look at is when we get into that phase of planning, or let’s say if the configure and develop phase, we have a budget set for that that is enough budget to get the goal accomplished, but we want to accomplish that goal in the most optimized way possible. You go into that phase and you say, “Here’s the 10 things that we know, the 10 stories that are inside of this phase,” and we want to give the highest value during that period of time.

 

When we come up with other ideas, let’s say, during that phase then we can adapt to going after the better ideas. That’s, I think, the beautiful thing about Scrum is you’re not committed to a story until you get into that sprint. You’re flexible enough to change your mind if you want to spend that money in a better way.

 

Danny:It all goes back to your manufacturing days, just in time, minimize rework. It just seems to be that’s what you’re ultimately trying to do, is not creating a bunch of rework.

 

Tommy:Right, but with migrations the, quote, standard is you really do have those phases that are logical steps to get you there. You’re not going to flex as much on that because it just doesn’t make sense. You skip one of those steps and then you end up putting yourself at risk for a successful migration. We’re finding that it really is a mixture of a waterfall, you have this phase and this phase and this phase, that you don’t do them all together every sprint.

 

You really need to be in a mindset of, “Let’s finish a certain amount of analysis. Let’s finish a certain amount of planning. We need to finish the configuration and development, and then let’s pilot this thing to prove out everything that we did leading up to that is working. Then let’s go into production, guns loaded,” doing this as fast as possible. Because as soon as you start that migration now you’ve got 2 places where that content is and the sooner we can get it all in that destination and be able to shut down the source, the better off that organization is going to be in terms of being confused and disrupted.

 

Danny:Yes. Chris and I talked about ludicrous mode.

 

Tommy:Yes.

 

Danny:We need to then go into ludicrous mode.

 

Tommy:It’s all about ludicrous mode, yes.

 

Danny:We’ve got the special sauce for turning on the ludicrous. I want to thank you today also for wearing cool socks again.

 

Tommy:Right?

 

Danny:You have outdone me.

 

Tommy:How do you like that?

 

Danny:I know people can’t see this.

 

Tommy:You’re going to have to have a vlog so we can show the socks.

 

Danny:I think I need to take a picture of that and I’ll put it up on the blog as I post it up. Man, that’s pretty nice. He’s got grey and blue and dark blue socks. Does that match your Scrum hat?

 

Tommy:It’s why I have multiple hats, whatever the color of socks I have I put on a hat.

 

Danny:I like it. You met with somebody today as well.

 

Tommy:I did. I actually met with 2 clients today, very good morning.

 

Danny:It’s great. That’s good. I’m glad to hear that. Anything else we want to talk about with this?

 

Tommy:You’re ready to be done with processes, aren’t you?

 

Danny:I know, I know. I know. You’re like, “I just got started Danny, I’m about halfway through the subject.” To wrap it up Tommy what do you …

 

Tommy:No, I think a lesson learned, and I’m working on the blog when I get to that point. I’m really just making sure that we’re doing the right thing by applying Scrum to our migration projects. It seems to fit. I think you have to put it in the right perspective and not make it Agile from the perspective of it’s just one big project. We can go in any direction. I think that works well for some app dev that we do, but when it comes to migrations we need to have some discipline of these phases and there are certain things that have to take place in those phases to be successful.

 

Danny:Good. That’s great that we’re taking the time to learn that. I, from an outsider again looking in on a couple of these projects, it seems it’s continuing to serve us, flexibility wise as well.

 

Tommy:Yeah, that’s what we want.

 

Danny:[crosstalk]

 

Tommy:We have the 3 Cs. I think having choice, we want that in every project that we do. We don’t want someone to feel like, “I’m stuck.” We want to give them the right guidance and put in the guardrails but give choice within those guardrails.

 

Danny:I like it. I like it. I’m whispering now, I don’t know why. I don’t know why I’m whispering. Great, thank you for taking the time to do this.

 

Tommy:Sure Danny.

 

Danny:It’s a pleasure, even when we’re talking about process. It was a pleasure. I stayed awake for the whole thing. I’m here, I’m right here with you. Thank you everybody, you stuck with us too, wow. All right, way to go. Thank you for taking the time to listen today. Definitely if you’re looking at migrating to Office 365, especially for folks who might be doing from a platform like Jive or some other content platform, feel free to reach out to us, it’s a topic we’re pretty passionate about talking about. Just come to us through the website, just go to the contact us page, that sends me an email and we’ll talk very soon about it. Thank you so much for taking the time to listen today. Have a wonderful day, bye bye.

 

Tommy:Bye bye.

 

Danny RyanUsing SCRUM on Migration Projects

2 comments

Join the conversation

Join the conversation

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