What are we doing? Why are we implementing this sorry excuse of a user story? What will this user story achieve in the bigger picture? Is there even a bigger picture?
I have attended several refinements as a coach, where I was waiting for those questions to arise… Unfortunately, they are rarely asked. Usually, because there is no easy answer to these questions. The difficult truth is that we all like to please others, so we would rather stick our heads in the sand and hope everything will turn out fine.
And that is exactly what we get. Instead of having an awesome job, doing cool stuff and making a difference: our job will be just that, it will be fine. And it could be so much better, with some practises I will share in this blog.
If you do not understand how your work contributes to others, you will gradually lose motivation and become passive and responsive at work
I don’t know about you, but I want to be more than just fine. I want to live an amazing life and I would hate to become a responsive individual. And I believe I am not the only one driven by this idea.
When I was young, I resented people that showed responsive behavior at school or at work: people who only act after they have been told to do something. But over the past few years I discovered that this happens for a reason. Responsive behavior is a natural result when working in a non-motivating environment.
One of the most important factors of a motivating environment, is to have a sense of purpose (see Dan Pinks Drive). We need direction. We need to know how our efforts can have an impact. If we don’t understand how our efforts can contribute to a greater cause – a cause bigger than ourselves – we tend to settle for the status quo, and just do as we’re being told. So without a sense of purpose, we tend to become those responsive individuals. We need direction to be amazing. We must create it for ourselves, or we need someone with a vision.
So how do we create this direction, this sense of purpose in our work environment?
I’ve discovered that the best way to introduce purpose in an organization is at two levels: at a conceptual level (a product vision) and a tangible level (metrics). The conceptual level helps us understand how our contributions can help achieve something bigger than ourselves, it gives us meaning. It’s also essential to answer questions like: “Why are we implementing this user story?”. The tangible level helps us focus on doing the important stuff and not dwell on philosophical discussions, it’s actionable.
Conceptual level: create a shared vision for the product
A shared vision enables developers to think about what’s best for the product. Should we implement this user story? Or should we do something entirely different? Perhaps there is a way to solve the customer’s problem with a single line of code. To have this discussion, teams should be aware of a vision for the product. Even better, they should understand it and be able to criticize user stories, using this vision.
A good vision always takes into account the principles of SAM:
Specific: A product vision must be specific, so that developers can use it to discuss user stories.
Acceptable: A product vision must be acceptable, for developers to take it seriously.
Meaningful: A product vision should explain why developers spend 8 hours a day on this product, and not quit tomorrow and join the competitor.
BAD VISION: “Our product is almost as good as our competitor’s.”
GOOD VISION: “Our product will help people to visualize quality.”
GOOD VISION: “Our product will turn online shopping into a personal experience.”
GOOD VISION: “With our app the user can order food with a single click of a button.”
These product visions are acceptable, can inspire certain people, and can be used to criticise or discuss user stories.
Visualize the important metrics (instead of just velocity)
Metrics are incredibly powerful. Whatever metrics you choose to visualize with your team, those metrics will become what the team will focus on. If you set up a dashboard in your team room that visualizes the amount of 500 errors in production, the team will focus on reducing the amount of 500 errors. This is automatic behavior. We want other people to think positive about us, so if you visualize any aspect of yourself or the team, your natural behavior would be to improve that aspect.
Unfortunately, many teams that are starting with Scrum use velocity as a primary metric. Based on the previous example, you might be able to guess what this will result into… The team will focus on delivering as many user stories as possible, but with no regard to the quality of what they deliver. Then the customers will become less satisfied and demand new things, which results in huge pressure to deliver a lot of crappy software.
But as you might understand by now, this can be used to your advantage as well. If you create a metric for the quality of your software, and make this visible for the entire the team, the quality will automatically go up. Simple as that!
The difficulty lies with selecting the correct metrics to visualise. These are some of the useful ways to visualise important metrics:
- The code coverage results from running your automated acceptance tests.
- The amount of individual users on production.
- A coloured led lamp showing the status of the build pipeline.