Modernize: The action plan
With a solid understanding of the risks involved and varied approaches, set out to modernize. While rebuilding takes time, making this move can significantly alter the future for organizations. Below is an action plan for modernization initiatives leveraging Devbridge’s proven-best practices working with Global 2000 enterprises across multiple industries.
Determining the effort
Decide what type of effort offers the most benefits for the business. Focus on outcomes over feature parity. Rather than trying to identify and build everything based on guesswork (i.e., what you think your customers may need), prioritize what’s relevant to customers noted in user research or the current business model. Evaluate the entire system and replicate select elements with clarity on all the features known or unknown.
Getting started with a Lean Requirements workshop
The workshop is designed to challenge the team to think critically about the best digital product for the enterprise. Gather stakeholders together in a room for 1-2 days. The Devbridge team facilitates activities.
Users, roles, and goals
Story map or service blueprint
Risks and impediments
Technical feasibility
At the end of the workshop, the team is armed with critical assets informing the work.
Six key outcomes
Defined business goal: A clearly defined business goal with success metrics.
MVP requirements: The minimum amount of requirements necessary to kickoff the design process.
Hidden requirements: Bringing people from different functions together to uncover what impacts goals, scope, and priorities.
Shared understanding: A shared understanding of the business process, end users, and their pain points.
Scope & priorities: An agreement on scope and priorities to meet the business goals.
Product release strategy: A phased approach to releasing your product to market.
When replacing an application: Create a story map of an entirely new system.
Stakeholders jot ideas down on post its and present ideas, discussing each concept with the group. The dev team arranges the epics, features, and stories into the story map. Epics and features flow from left to right in a logical user path (e.g., searching, checkout, and then booking). Arrange the stories under each feature in a logical flow to visualize the entire scope of work.
As a reminder, don’t rely too heavily on feature parity. Yes, there is some value in flagging the options no longer needed and old functionality to avoid potential failure. However, now is a prime opportunity to redefine the software synced to the company’s current and future needs. Focus on delivering outcomes. Be deliberate and work with stakeholders to only identify features that benefit customers or business needs.
When rebuilding an application: Capture the areas requiring rework in a service blueprint.
A service blueprint provides the entire team insight into the business systems, third-party integrations, and manual steps featured in the legacy systems relevant to customers and back-office personnel. Break the monolithic legacy system into domains, prioritizing each to inform the initial iterative component build and release of the new system. Highlight specific pain points as well as low-risk opportunities to set aside for future workshops, estimate, and build. Capture risks, impediments, technical feasibility, and priority items.
Defining scope
After the workshop, estimate the effort based on business goals, story points, and complexity factors. Determine the drivers influencing the work ahead (e.g., the cost and time).
Increase the team size or run parallel teams to hit the product release date or expedite or larger system efforts.
Keep the team size smaller and spread the development across several, incremental releases to pace funding better aligned with the business or access revenue from new features support further investment.
Sometimes a workshop is not enough to inform the initial build. If there are still unknowns, difficulty evaluating risks, or in need of additional information, add a discovery phase to better define the work, including:
Heuristics
User research
Competitive analysis
Ideation
Service design
Technical spikes
Prototypes
Establishing success metrics
Craft metrics to measure and monitor success. Set specific, measurable, achievable goals. During each sprint and release, validate the approach against the established metrics. If running off-course, reset and set new success metrics based on the company’s current state, future state, or market conditions. Partner with consultants to support teams needs to scale up or down based on demand, provide specialty services, or fill technology knowledge gaps.
Building and delivering
Rather than trying to modernize the entire application with a big bang, use an agile approach—breaking legacy monoliths into components and services. Reference the workshop assets, like a service blueprint or story map, to inform the product roadmap. Focus on building high-priority elements.
Demine which aspects to work on and in what order. Run daily standups to ensure teams remain aligned during execution delivery cycles. Slice the workload into manageable increments with two-week sprints released every two to three months—working toward a twelve to eighteen-month final delivery. Leverage an iterative build-measure-learn approach to evaluate success after each release and reincorporate learnings from recent releases back into the product. Once all components are assembled and interconnected, remove and replace the legacy system.
Modular modernization
As a foundation, a modular approach enables organizations to manage applications at an individual component level, relying on the system’s data as a building block. To implement, build, test, and run applications in a virtualized environment. Modular builds include a set of connected micro-applications or microservices along with corresponding compartmentalized domain data. Start with the least dependent components of the legacy application identified in the story map or service blueprint. Then, stitch the components together, creating a way to scale pieces of the work banking on successes or quickly responding to failure.
Analyzing the outcome
User research, lean requirements, and dual-track scrum enable teams to deliver fast. Pivots throughout delivery are possible due to the nimble process. Agile, cross-functional teams own the product backlog, user research, design, testing, development, and release strategy.
Unlike building a widget, digital product requirements often shift throughout delivery. Markets change. Stakeholders view working demos and raise questions. Supplement initial bias with user research.
Work with stakeholders to remedy concerns and review analytics to identify features to retire or add. Maintain the underlying software and libraries and continue to foster continuous release cycles using DevSecOps. Dual-track scrum allows the team to react to changing requirements with minimal rework and ship a product faster.