Most people in the software industry they got there because they thrive in finding solutions and for us coding is just another language we speak fluently.
And just like in any conversation, we find an organizational system to make sure we follow the topic at hand and we direct our skills toward achieving a goal – a product, a feature, a story.
We define processes and milestones to make sure we keep focused on the same conversation and that we are indeed going towards the goal. They help keep us focused on the long run.
At different stages of our journey, we are inspired by trends other teams or organizations use. They speak so highly of them, it is indeed inspirational. And we want that state of flow in our day to day. We love feeling inspired.
We follow the trends and we add milestones in our journey inspired and forced by the trends and at some point we miss the fact that we are not moving toward our goals.
One of the trends keeping strong in the past decade in the software world is automation – be it development tools, testing, continuous integration and anything in between.
And by all means, it should be a trend because automation is here to improve our lives and to decrease the number of issues in our software products and definitely to increase our confidence in the products we release.
Automation is a thing of beauty, it is the moment when you find the missing piece of a puzzle, it is like those the last steps of a climb just before you reach the peak or like the moments before you finish a race.
But automation is not the end goal, but it is a type of support we use in the process of reaching our end goal.
The goal of most engineers is to develop functionalities and products.
The goal of any software development company or team would be the quality and availability of their products.
And these two actually become one – creation of functional products.
And with this goal in mind we add milestones and KPIs to reach and keep certain precents of automation in our development process.
But then, at some point, we tend to consider that percentage our actual goal. And we model the rest of our activities and tasks to reach or keep that goal.
Without realising it, our day to day becomes more of a struggle than a joy. We are brought together by the goal to create products but slowly, most of our work revolves around keeping that automation instead of the satisfaction of creating and maybe improving our product.
Scenario based development is one of the tools we can use to dig up and bring back that sense of purpose we feel when we build together to develop our product.
While creating automation is fun and exhilarating, if your purpose is different, no matter how beautiful your code is, how performant or how fit it is, that feeling of accomplishment, of reaching your goal or making progress toward your goal is still missing.
The outcome of a properly applied scenario based development in this case is:
- defining what level of automation is actually fit for our product and our team
- adjust the places where automation brings the most value,
- refine tools and processes,
- clearly define and restate the goals
- and most important, bring back the fulfilment we feel when we deliver according to our purpose.
Of course there are other outcomes like less critical defects and faster time to market but they are always as natural consequences of this process but they are not the actual goal of scenario based development. The actual purpose of scenario based development is to bring back the fulfilment we feel when we deliver according to our purpose.