Agile. Leadership. Coach.
A user story is a method of expressing a need or a problem in a way that gives the team solving the need or problem maximum flexibility in the solution they create. A user story also includes specific information that helps to clarify assumptions and prevent misunderstandings when developing a solution.
Even with that, many people don’t understand what user stories are and struggle to use them effectively.
I don’t love agile. I don’t like agile. I have no agile tattoos. I’ve never named a dog ‘burndown’. I’ve never gotten in a flame-war defending agile. My identity isn’t tied to agile.
These statements may not make sense coming from an agile and leadership coach who coaches, teaches and mentors agile all day. But they are true. I do not love agile.
Here’s how I’ve approached a redesign/replatform of a legacy appliction.
The first thing I do is I vote everything off the island. 100% of existing functionality, processes and assumptions are out. Anything that wants to be part of the final solution has to fight to get back in.
This approach means that even if you have a legacy system, something that has been up and running for quite a long time, everything must go. Business rules, custom implementations, hacks, cruft, things that aren’t used by customers but you still regression test it…all of that is gone.
All of that is assumed to be thrown away. Then you take a fresh look at what the present requirements are, the current need for your current customers. And that’s what you build. Or at least that’s where you start.
The primary reason to do it this way is that it doesn’t start the rewrite by anchoring on the previous system. When you are bartering or negotiating on a price, there is always an anchor point. Someone will say, “I’ll pay up to $100” and the negotiation pivots around that. The anchor determines what you are reacting to. The anchor determines which way the discussion naturally pulls.
The challenge here is that if you anchor off the existing system, you will end up with something that looks very similar to your existing system. Maybe you need exactly what you have today, just in the cloud and on a technology you can hire people to support. However, odds are good that your customers have changed, the technology has changed and your business has changed. What you have today is the accumulation of a lot of decisions that were good at the time but when you put them all together and let them marinate for a few years, you have a system that is difficult to maintain and slow to change.
Ultimately you need to anchor not on your current system and its current capabilities, you need to anchor instead on the current and present needs of your customers and prospects. That needs to be the starting point.
The nice thing is because you have built this system before and because you’ve been in this business a while, you have a lot of great ideas. You know a lot of things that work and a lot of things that don’t work. You’ll have a lot of good instincts for what the customer’s needs are and you’ll likely be able to make some quick decisions.
But you don’t want to go through this effort to end up with a shiny new version of the complex system you currently have.
As you start these discussions to redesign the system, here’s a key phrase to look out for. If someone asks, “Why should we add this feature? Why is it important?” pay very close attention to the next thing said.
If the next thing you hear is, “Well….someone might want to do x,y or z” then you need to take a pause.
This ‘someone might want’ phrase is an immediate sign that we’re not solving a real problem. Instead we’re solving a hypothetical problem, an anticipated problem, a potential problem. In short, we’re solving for a problem we don’t yet have.
I will challenge that statement when I hear it. I’ll say, ‘give me the name of a person, give me the name of a real user and exactly when and how they’re going to use this feature.” Once we have that we can have a vigorous and informed discussion on the priority of this idea relative to everything else and decide if it is important right now.
Sometimes it is a priority, most of the time it isn’t. Most of the time it is evidence of still being anchored on the old solution.
Many times when you are working on a rewrite or replatform it gives you an opportunity to go into the world with a very small and targeted solution that will allow you to reduce risk and learn rapidly.
This means that who you target as your first user or first customer will have a huge impact on how quickly you can get into production with your new system.
If you target an existing, demanding enterprise customer as your first user, your initial version into production will be large and complex (and won’t look too different from your current solution).
What would happen if instead you picked a new customer who hasn’t been implemented yet? What would happen if you picked a smaller, simpler customer who might potentially want to become a development partner with you on the new system?
You’d likely have the ability to build the backbone of the system quickly and simply and be able to get into the market for real feedback faster. Once you have that first simple customer live you can look for the next use case to support and keep iterating.
The nice thing is that if your new system has new features or better performance, that can create a pull for your existing customers to migrate over to the new system. And if they see the benefits and want to move, they’ll likely be more willing to rethink or even discontinue some of their current processes in order to make the move. This results in a simpler new solution.
Links for Production Support talk at Agile 2018
Helpful links about agile
I found out a week before my wedding that we weren’t going to have a wedding cake. The baker which we’d paid to design and bake a multi-tiered, multi-flavored wedding cake for 300 people had gone out of business.
While not fun at the time, it turned out to be a great lesson in project management and what MVP really means.
When things go wrong in production it is critical to get things fixed immediately. Good teams can do that. But great teams fix the problem in production and get to the root cause so this type of problem never impacts a user again.
When I was a software developer and I met someone for the first time and they asked me what work I did, I would reply, “I type for a living.”
Links and bibliography for my “Overcoming Resistance” talk