Visualization in Scrum
Before talking about visualization in Scrum, we need to understand what visualization refers to, in this context we are going to refer to visualization as an experiment with imagination, where you think on situations that can happen in real life.
In the Scrum visualization, I highly recommend two main types that need to be applied with the team, “Negative Visualization” and “Easy Visualization” I’m sure you imagine what these two types of visualization refer to, but anyway I’ll explain them in the next part.
Look at the worst-case scenario that could occur to your team, maybe the technology is obsolete, the product owner leave abruptly, or even if your bigger competitor launch to the market before you, all of these cases sound awful right? Well, that’s actually what we mean by visualization. The benefit of doing this is understanding the risk and understanding eep walking without fear because you thought about what to do.
Let me tell you a story, in one software company where I worked we create an app with a huge social media campaign, with a countdown creating huge expectations and we create a visualization but we did it wrong, we think in the best scenario where we got 10,000 users at the same time! To prevent this we use the AWS elastic load balancing and some other AWS awesome services that make us feel safe. The big day was December 7, because we want to be ready before Christmas, and as Murphy said “Anything that can go wrong will go wrong” yes everything went wrong, AWS went down during that day making our app fail on the launch day, worst first approach with our users.
In Agile we always need to fail fast so we can learn even faster, so each thing that you are thinking to create keep this question in your mind “How would this be done if it was easier?” and don’t overthink this, just imagine if this problem were simpler how would you do it? And if you can’t visualize this, you might not understand what needs to be done.
To create this easy visualization you can use a 1,2,4 approach. This approach is easy first imagine that you have 4 months to deliver the first version of anything you want to test, then think about what could you achieve in two weeks, and at last think what could you deliver tomorrow; This last iteration of visualization sound difficult but after the 4 months and two weeks thinking one day suppose to be easy, if not try to understand better the problem.
The Mirror Technique
This is just an extra, place yourself in front of a mirror and think where do you want to be at a certain time, maybe one year, we don’t need to think in 5,10 or 25 years, with 1 year or even less is enough, think about your biggest dream or aspiration and after saying this, is the moment to be hard with yourself, tell you all the things that you’re missing to achieve your dreams, now that you understand all the things needed and what you’re failing on, its time to start getting better one thing per day. In one month look at yourself in the mirror, you will notice the difference.
This is cool… but what about Scrum?
Think about the Scrum Values, which one is the most important? That’s a tricky question the 5 values are equally important if you don’t remember the Scrum Values (courage, focus, commitment, respect, and openness) maybe you need to read and understand them before using visualization.
When we do the visualization technique we directly go with commitment because as we commit to achieving the goals we need to understand how can we fail these goals, after understanding how we are going to fail we need to focus on the easy visualization part to deliver value as soon as possible, did you see that? We touch on two values that will help our team but this is not the only thing we are going to work with these techniques.
While doing this you might listen to some of your peers saying ideas like “what if this technology disappear in the following weeks” we need respect there’s no stupid idea, we only have stupid people that judge ideas, then we need the courage to do the right things and work on any tough problem that appears.
At last, we need openness, anything that we learn here we need to be open with our stakeholders a challenge is easier if we work as a team.