I was recently inspired by Linda Liukas’ Hello Ruby books and especially her talk on the usage of stories to describe computer analogies to children. As a father the subject hit well. How would I describe the work I do on a daily basis to my children so that it would be tangible for them? By telling a story in a language that children understand.

Axel Waal, Project Manager, Profit Software

Similarly, at work, storytelling can be a very powerful tool in explaining why things should be done in a certain way, to convince people of a certain action or an idea. The stories can also be a way of helping organizational and cultural change happen. By creating the stories tangible and close to our day-to-day work, we can demystify the abstractness of the world of software development.

Let’s take as an example the need of streamlining our development processes. We have used stories to engage close teamwork between the typical roles in software development (designers, analysts, developers, test engineers etc.) and fostering more collaboration between the co-workers. By creating interesting stories that show what everyone can gain from blurring the typical roles in our development processes and how beneficial this can be, we have actually made the change happen.

One of the sagas to foster collaboration has been to “shift left“, which in a few words means early contribution from whole team and getting feedback as soon as possible. Some of our software development stories behind these steps are the following:

  • Our analysts and designers get feedback through open design discussions where whole development team is contributing and “table testing” the design. Information is shared from day one to everyone involved.
  • Before any code is written, we identify together, in co-operation, critical areas to focus our effort on. We find the testing path and landscape in collaboration and allow everyone to contribute to the ride.
  • Quality feedback is shared to developer and rest of the development team when the first lines of code hit the version control. From the time that the developer commits a change to our build machinery and goes to grab a cup of hot beverage, the automated work has already begun. When returning to the work station, the first feedback is already waiting to be digested.
  • During the lunch hour, one can trigger even larger set consisting of tens to hundreds of virtual workers grinding away to do the labor of tens of manual workers. The time that was traditionally needed for longer regression set has diminished from weeks to 1 hour.
  • During the night, we can utilize even more firepower and machinery to achieve heavy labor integration verifications which will be ready early in the morning for the first to check.

When we go further in the storytelling and look into the yet unwritten parts, we may find tales about helpful AIs or even automated exploratory testing.

Ultimately all these stories are focusing on getting our daily work more efficient by avoiding unnecessary manual labor and getting automatic guidance when needed. Similarly, through collaboration the quality of the software should be and is the responsibility of all the participants in the development process. Understanding what others do and what their tale is can help to achieve common goals and create better quality.

The tools and methods we are using are the medium, yet the culture and mindset are the areas to nourish and harvest. If we can motivate people to share their narrative and develop them into actual instruments to be enjoyed by others, we have built a strong ground for constant development. The road ahead is filled with possibilities.