Where is the Magic wand?
I am always wondering where I was the day they distributed the Magic Wand. I mean, every time I join a new Team/Project I always have to carry with me a set of tools that make my job easier. Some of these tools are within Visual Studio, some are pre-defined architecture diagrams that I created with Visio or Balsamiq, some are links to articles and books that I share with the teams.
Unfortunately, very often I see the demand of a Magic Wand, a tool that I don’t carry with me just because I simply don’t have it and probably I’ll never have!
Now let’s make the concept more clear, there are usually three different situations where you will be required the use of a Magic Wand:
- First, most common, the impossible timeline. You get a request from a Stakeholder or even a Product Owner to accomplish a task in a time that it’s human impossible
- Second the Ferrari buyer, you are required to design a functionality or a set of functionalities with a budget that is waaaaay to low than the minimum required
- Third the Tetris puzzle, you are required to add a functionality to an existing structure, but the existing structure does not allow you to implement the functionality and you don’t have time/resources/space to refactor the existing code
Of course there are a lot more situations where you are required to provide a Magic Wand, the three reasons mentioned previously are common in my job, and this is how I usually try to tackle them, even if this doesn’t mean that my solution is always the right one …
The impossible timeline
You have a meeting with your Product Owner and you discover right away that he wants you to implement a very nice piece of functionality. It requires some refactoring of the current code, a bit of investigation on your side, and probably a couple of weeks between coding/testing and update the documentation. Wow, great, you know that you’ll be busy in the next months with something very cool so you are all trilled and start to discuss with the PO a draft of a backlog that you have created previously.
Right away you discover that your backlog is simply non achievable. You estimated three sprints for a total of almost two months of works while your PO has already said to the Stakeholders that it won’t take more than a couple of weeks!
In this case, the only thing that we can do is to draw the backlog, probably using a Story Map approach, and share the backlog with Stakeholders and POs together, in order to show what is the real amount of work required. I usually work with Balsamiq and I create story maps that look like the one on your left.
Using this approach you can clearly show to the Stakeholders that in order to make an Order, for example, you need to create few things like: infrastructure, HTML views, REST methods and so on. For each task you can clearly identify how long it will take and that will probably give to them a better picture of what’s needed to be done.
The Ferrari buyer
The second situation where I am usually forced to use a Magic Wand is when I encounter the Ferrari buyers. Why do I call them Ferrari buyer? Well because those type of Customers/Stakeholders or whatever you want to call them, they are usually looking for a Ferrari master piece but with the budget of an old Fiat. That’s why they struggle to find a “YES” answer when they propose the project or they request a new functionality.
Did it ever happen to you? You propose a project for a budget, let’s say of 30K a month, the Stakeholders are trilled and excited, every body approve your project, but usually for a third of the budget … Wow, how can we fix this now? They want the functionality, they want us to implement it but with half of the planned resources …
In this case is not enough to show to your customers what are the steps required for a task, you need to start to talk also about resources and time. If you can prove how long it takes a piece of functionality and how much will cost the person involved in the project, you can then easily come up with a formula like this one:
Cost = Time * DeveloperCostPerHour
And I usually implement this concept on top of my backlog, like the following picture:
Ok this is not a Magic Wand but at least you can show to the Ferrari Buyer that the optionals are not coming for free!
The Tetris Puzzle
Ok, this one has happened to all of us at least once, I can’t believe you never had to code a new functionality into an existing mess (ops), into an existing application, with some crazy acceptance criteria.
Let’s make an example. A while ago I had to work with an existing Windows Form + C# platform, used to generate mathematical results after the execution of a long running task. The long running task was executed outside the context of the app, it was on a different tier (Database tier).
The application had a major issue, the entire User iInterface was synchronous, so every time a request was made (Data, Commands), the User had to wait until the User Interface was free.
You would say, what a pain …
Btw, the request from the Product Owner was to make the User Interface asynchronous, using less code as possible, in the minimum achievable and high quality level possible amount of time.
We analysed the application and we discovered that there were a lot of Views, User Controls and customisation from third party libraries (like Telerik, DevExpress …) that required a complete refactor process because they were not able to receive asynchronous data properly, without raising Invalid thread exceptions here and there.
Well, at the end it was hard to convince the PO about a massive refactor, but we didn’t really gave him a second choice, and this is really the point. If you give them a second cheapest choice, they will always choose that one and you will be stuck in the middle not able to say NO and not able to finish in time.
Well I hope you enjoyed my rant …
Raffaeu