Agile Transformation Managers: Iterating on the Car Analogy
Agile transformation is a hot topic in today's business world, as companies seek to increase efficiency and adapt to rapidly changing market conditions. This blog post aims to provide a comprehensive and educational overview of Agile methodologies. To make the concept more relatable, we will use the analogy of an old car.
The Car Analogy - Incremental Improvements and Customer Feedback
One of the best ways to explain Agile is through the car analogy. Imagine a customer who wants a car to travel more comfortably and quickly from point A to point B. Instead of building the entire car at once, an Agile approach would involve delivering a series of incremental improvements based on the customer's feedback.
First Iteration: The Skate - The customer receives a skateboard to fulfill their basic need for transportation. They provide feedback, such as needing something to hold onto.
Second Iteration: The Scooter - The customer is given a scooter, addressing their need for stability and hand support.
Third Iteration: The Bicycle - The customer receives a bicycle, offering an even more comfortable and efficient mode of transportation.
Fourth Iteration: The Motorcycle - The motorcycle provides a faster and more powerful solution, getting closer to the customer's ultimate goal.
Final Iteration: The Car - The customer finally receives the car they initially desired, but the journey of incremental improvements and feedback has ensured the end product is tailored to their specific needs.
That’s all great but… What if you already have an old car and want a new one?
The Ship of Theseus and Legacy Products
The Greek myth of the Ship of Theseus provides an interesting perspective on how to approach the transformation of a legacy product.
The myth raises the question of whether a ship that has had all its parts replaced can still be considered the same ship.
This concept can be applied to the process of transforming a legacy product into a new one without completely discarding the old one.
Key Questions to Consider
Assessing the Value of Legacy Systems and Products
Before diving into a transformation, it's essential to evaluate the current capabilities of your legacy systems and products. Ask yourself the following questions:
Are the current capabilities useful in the future?
Was the legacy product built with high quality and future-proof capabilities?
Is the legacy product built on a modern tech stack but with low quality?
Prioritizing Features and Objectives
Using the analogy of transforming an old car into an airplane, some features might not be applicable in the new context. Focus on meeting the fundamental objectives first, such as transport and the ability to fly. Additional features, like comfortable seats, can be prioritized later in the development process. This approach aligns with Agile principles, emphasizing the delivery of the most crucial features first.
Refactoring vs. Rebuilding
Depending on the quality and future-proof capabilities of your legacy product, you may need to decide between refactoring or rebuilding it. If the product was built with high quality and future-proof capabilities, consider refactoring only the components that need improvement. Remember that working technology, whether old or new, still holds value.
On the other hand, if the product is built on a modern tech stack but with low quality, you'll need to weigh the urgency of having a working product now versus the long-term benefits of building something new. If time is of the essence, transitioning to an entirely new product may not be a feasible investment.
Collaborating with Experts
Are the legacy product developers still part of your team?
Leveraging existing expertise: Your legacy product developers possess valuable domain knowledge and expertise that can be critical to the success of your Agile transformation. They have a deep understanding of your product, its history, and the challenges it has faced. Ignoring their experience could hinder your company's ability to make informed decisions and adapt to change effectively.
Based on these questions, you can determine the best course of action for your organization. This table provides a summary of possible scenarios and recommended actions.
Product A A working product as this one does not need to get retired, specially if there's no need to add
major capabilities.
Product B If you don't have the team who built this but is still a great product, and you need to add capabilities
that are widely different, reuse what has been created, bringing it to the new tech stack.
Have the stakeholders keep using the old one and join you for feedback on the new one.
Product C Most likely you can keep this working, but you'll need to avoid changing things that are
not impacting the client. It's possible that you get a case of whack-a-mole chain reaction.
Product D Nothing useful to keep, noone to explain you how did they do this, this not being part of
the modern tech stack: starting over is a good call.
Product E Even if some things "could be better", that's not reason enough to drop it and move forward with
a new other product. You will still face problems like the Product C had, but to solve them should
be a lot easier with the team that worked on the legacy still here.
Product F It's where no one would like to be, you have people with constant complains about the product.
But you'll have to work with what you have.
How to Involve Stakeholders
Often, stakeholders may not feel responsible for the product's outcome, leaving IT to figure out the project's success on their own. To address this, involve stakeholders in the process by:
Communicating the importance of their role in the project's success
Encouraging their participation in decision-making and prioritization
Providing regular updates and opportunities for feedback
Pitfalls and How to Avoid Them
When undergoing an agile transformation, it's essential to be aware of potential pitfalls and how to avoid them. Some common pitfalls include:
1. Reinventing the entire product: Ensure you have thoroughly analyzed the variables before deciding to create a new product. Remember that creating a new product can take significant time and resources without providing immediate value.
2. Documenting everything upfront: Agile methodologies embrace the idea that priorities can change, so avoid trying to predict the future and focus on short-term adjustments.
3. Requiring a fully completed MVP: Deliver only what fulfills the purpose and gather feedback to prioritize the next steps.
Keys to Success
To achieve a successful agile transformation, involve stakeholders in the process and ensure they feel responsible for the product's outcome. Both stakeholders and IT should have a shared vision and common goal for the success of the product or project. Some strategies to engage stakeholders include:
1. Regular communication and feedback sessions with both team and stakeholders.
2. Joint decision-making with stakeholders on priorities and features.
3. Collaboration between IT and stakeholders on project planning and execution.
Conclusion
Navigating agile transformation with legacy products can be challenging, but by considering key questions, avoiding common pitfalls, and fostering collaboration between stakeholders and IT, C-level and Product managers can successfully guide their organizations through the process.
