As recently as 2017, half of all CEOs said that Agile software development methodologies were a fad. And yet, Agile projects are almost 30% more likely to be successful than other projects. When it comes to something with an incredibly high failure rate—like a cloud migration—that added boost to your odds of success is nothing to sneeze at.
At first glance, Agile might not seem like the most obvious approach to something like a complex refactoring or replatforming. Modernizing your IT stack requires careful planning in the early stages, and many developers and higher-ups alike think of Agile as something that promotes improvisations and looks down upon comprehensive planning and documentation.
Luckily for those of you who are inclined to make your cloud migration strategy more Agile-aligned—this view of how Agile works is just flat out wrong. In point of fact, any number of Agile strategies and principles can help speed up your modernization and improve cost efficiency. You just have to implement these tactics in the right way.
|
Jumpstart your Agile software development! Join us for a webinar to get tips from the pros.
|
Build a Detailed Cloud Migration Roadmap
First things first: even simply rehosting an existing solution for a cloud deployment requires comprehensive planning and the creation of a roadmap or cloud strategy document. Some of you might be worrying that this goes against the tenet of prioritizing “working software over comprehensive documentation,” but fear not: just because working software is the goal, that doesn't mean you can’t utilize documentation to get you there. In fact, you need documentation, especially in the preparatory stages, if you want to have any hope of averting a cloud disaster.
This means that your first step is to set your vision of the digital transformation down on paper. This can take the form of a cloud strategy document or something similar, but it should include a number of elements:
- A top level summary of the project and its expected outcomes—along with the overarching vision for implementation, measurement, etc. This step is crucial for giving everyone a touchstone around which they can coalesce.
- A workload inventory that details every workload’s existing status, cost, billing model, vendor, etc. plus an initial suggestion for whether to rehost, replatform, or refactor.
- Suggestions for cloud governance rules and guidelines, including classifications for different datatypes, regulatory rules, disaster recover plans, change and incident management policies, and, crucially, cost control measures.
- A sketch of roles and people across the project—with a suggestion for who might act as your cloud architect, who will be in charge of specific budget and control levers, etc.
Again, this kind of planning doesn’t go against the principles of Agile—rather, it makes Agile development flows possible. When you’ve got a project with thousands of individual tasks that need to be performed, the absolute last thing you want is people trying to wing it.
Break Down the Migration into Epics and Stories
Once you have key elements of your roadmap plotted out, you can move on to steps that are more obviously rooted in Agile methodologies. Specifically, you can start to break down your migration into epics and stories. As Amazon points out in its documentation: “Using an agile approach with epics (large stories), you start small, iterate, measure, manage, and scale. You can use an agile methodology for the preparation and implementation stages of large migrations to the cloud.”
Essentially, by breaking down a large, complex project this way, you can begin to fit the process into more typical Agile frameworks: daily standup meetings, users stories, story points, and the like. In addition to having a cloud migration architect, you’ll also want a strong Agile leader (a SCRUM Master, an Agile coach, or someone with comparable skills and experience) who can adapt the methodology to the specifics of your project and IT ecosystem. This type of leadership is crucial when it comes to removing obstacles and breaking down barriers so that your team of developers can keep progressing until you have a completed migration. This—the ability to position a team so that it can work without stoppages towards functioning software—is how Agile works at its best.
Implement Best Practices for Agile Stories
Because you’re ultimately breaking down the various elements of your migrations into stories, it’s crucial to make sure that those stories are following best practices. Traditionally, Agile user stories take the following form: “As a [persona], I want [goal], so that [reason]," with additional context potentially coming within the bodies of the relevant tickets. But within that form, there’s a lot of room for interpretation. For instance, a best-practice story will offer a specific and measurable goal, as opposed to something either vague or subjective, “I want the page to load in 2 seconds,” as opposed to “I want the page to load quickly.” By using a specific, objective measure in this way, you decrease the possibility of confusion or ambiguity over whether the tasks has been successfully completed or not. If the page loads in 2 seconds, your job is done—if it doesn’t, it’s not fast enough.
More broadly, the most useful user stories are the ones that are essentially idiot-proof—i.e. those where a developer with little familiarity with the project could hop in and understand what needs to happen just from the story. To make this work, you need to avoid jargon and language that’s loaded with implicit assumptions, especially those that might be limited to your specific niche or functional area. You can accomplish this by working conscientiously to make the implicit assumptions in your stories explicit, giving background on the persona in question, and giving a clear indication of what it means for a ticket to be “done”
This might sound like a lot of work for a team already has the lingo down and seems to be firing on all cylinders, but it’s a best practice nonetheless. Why? Because with a large project like a cloud migration, there’s a good chance that at some point in the process you’ll to seek out more developer capacity in order to keep things running on-time. When that happens, you want the new resources to be able to slot in and start contributing as quickly as possible—which can’t happen if you have to impart a ton of functional knowledge just to get them to understand the stories they’re working on. This is especially true over the course of a multi-year project, where there’s bound to be some amount of turnover across teams.
Learn (and Document) as You Go
So far, a lot of our focus has been on putting elements in place to keep the ball rolling no matter what. This might have given the impression that even an Agile cloud migration has to be extremely rigid—but this isn’t necessarily the case. Like we said above, in a longer process there will be turnover, just as there will be other changes, and tactics based on Agile methodologies are some of your best assets when it comes to rolling with those changes and even capitalizing on them.
This doesn’t mean that you should change direction or reinvent the wheel midstream for no reason—that way lies disaster. But it does mean that you can improve upon your process as you go. For example, if you start out writing user stories that require a lot of implicit, specialized functional knowledge, you shouldn't stick with that method just for the sake of consistency. On the contrary, if you have the opportunity to start implementing best practices in this area more consistently, you should go for it. Likewise, if you find yourself bringing in new resources to ramp up your capacity and keep your time-to-market in check, you don’t have to shoehorn the new resources into the existing way of doing things if they can present something more optimal. For companies that don’t specialize in cloud technology and cloud migration (which is to say: most companies), there’s a lot of value to be gained by working from the assumption that it’s never too late to bring in a cloud expert or Agile coach who can smooth out potential slowdowns.
Use the Right Resources
Like we said above, in a multi-year refactoring effort there are bound to be moments where it looks like your capacity might not stretch to get the job done in time. In these instances, you’ll either look elsewhere in your organization for developers who can help, hire and onboard some new staff, or seek outside help from a nearshoring or outsourcing operation. If and when it comes to that, you’ll want to be sure that you’re setting yourself up with a team that can thrive in an Agile environment. This means experienced developers who have been seen their share of software development lifecycles, sure, but it also means finding team members who are passionate, curious, and capable of communicating effectively across touchpoints.
Because Agile really is all about person-to-person working relationships, having the right people really does make a difference. What do the right people look like? Well, they’re excited to share their expertise and knowledge when given the chance. They like to work smarter, rather than harder—creating tools and automating tasks wherever possible to save unnecessary work. And they want to learn, whether that means taking advice from an existing Agile coach or coming into a new setting and working to learn the specific business cases and functional knowledge they need in order to be truly versatile team players. This might seem like a lot to ask for, but when it comes to a cloud migration—something that can take years and require countless hours of complicated labor—the right people can make all the difference.
Learn More About Intertec's Cloud Solutions:
Intertec’s teams have hands-on experience in developing and migrating applications on leading cloud platforms. In addition to design and development, we provide a complete range of application testing, deployment and ongoing support services, including managing physical infrastructure and offering outsourced DevOps teams. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!
