Storytelling and Software Development
It appears the power of storytelling has found a happy and relatively new home in the land of software development, within a process called “Agile”. More and more, this increasing trend is causing a shift in how the programs we all use and love (or love to hate) are being created.
For years, software was more commonly developed under what is called the “waterfall” approach. This classically linear and sequential method was called so because work “flows” down a highly structured and set path. Requirements describing what should be built and delivered are assigned to specific teams, creating an environment where you pretty much have one chance to get everything right.
Agile replaces that by having the teams deliver an increment of value, instead of a small piece of functionality. The idea is to build the software in increments, (instead of tackling the whole project at once), starting with this most important parts first. The crucial way this is done are through “user stories”.
You may be asking yourself, “What’s the difference between an increment of value and a piece of functionality?”
Great question. This is exactly how Agile is different from the “waterfall” approach. While a piece of functionality is basically the result of a requirement, Agile initially uses empirical data by telling “user stories” from the point of view of the customer on what they want or need.
Here is an example of a “user” story :
“As a dog, I want to be able to order food online so I don’t have to rely on people anymore.”
(I didn’t say it was a “human” user story.)
To further expand on this, I’m sure it’s safe to say that a dog will also have a hard time typing, so an additional user story would probably be needed to include this “increment of value” for all the (dog) users.
What you are basically doing here is telling a story as the user or “product owner”, explaining what you want, and why you want it. I like to think of a user story as a very-high level definition of a requirement, with just enough information so that the developers can produce a reasonable estimate of the effort to implement it.
There are definite perks to Agile’s story telling methods. This firstly allows for specification changes as per end-user’s requirements, apelling more customer involvement and satisfaction. When the team can interact directly with the customer, asking questions, getting clarification, discussing ideas, then there is a greater likelihood that what is produced is what the customer wants.
This also promotes more involved and self-managing teams. A “product owner” (a.k.a. customer) puts stories into the backlog, and then controls the development by prioritizing the stories with the most important ones on top. At the beginning of each “iteration” period, within a “scrum planning” meeting, the team determines what they will commit to over the next 10 business days. They write out the tasks that make that story happen, and development begins. Each day there is a “scrum” meeting, where the team and the “scrum master” get together to review the following:
● What did you do since the last scrum meeting?
● What are you planning to do until the next scrum?
● Is anything holding back your progress?
In the daily scrum, the scrum master is a leader, leading the team through the process. While the scrum master can offer advice, he does not tell the team how to go about their daily development activities. It is up to the team to decide the best course of action. That is what is meant by self management: the team manages the “how” rather than a project manager telling them.
This concept of really listening to the customer, embracing their point of view, while empowering your teams to self-manage, prioritize, and solve their own challenges are why more and more businesses are becoming “Agile”. It’s quite amazing how all of this surrounds the power and importance of telling a story.