Telling a story in SAFe — Are we doing the right thing?

Telling a story in SAFe (Scaled Agile Framework)?

As you know about SAFe, you have the program team that consists of product managers, solutions architects and program/project managers. Then you have the delivery teams with a product owner and a scrum-master in each delivery team. Product managers take the initiative/objectives from the senior leadership team and they convert that idea or objectives into a list of epics in the chosen tool. Product managers and solutions architects are supposed to meet to review these epics, to solution-ize these epics at the high level. Then they start involving the product owners and their delivery teams who would eventually create a list of user stories that would be linked to epics at the top.

On the other hand in the waterfall methodology, product managers would cook up a book of requirements in the form of a Business/Functional Requirements Document and this document would be given to technical leads and solutions architects to review, come up with the design and start executing.

I have worked within both methodologies and also in the mixture of the two. My experiences painted this picture in my mind about what really works in reality and what looks good on paper.

Let’s zoom in a bit on SAFe.

Receiving a collection of epics does not help with painting the big picture. A collection of epics does not really tell me the overall story as there is no flow to it.

Let’s use the following analogy: A writer does not tell a story by telling 12 people to write one chapter each and then combines it into a novel. The story would not radiate with anybody. The story and message would not be conveyed in the most effective way and even worse, the story would not even be told.

I think we all need to take a big step back and think about this especially if your list of epics gets translated into user stories at the delivery teams level and the final product developed is not what the author meant.

But what did the author really mean if the story was not told in a continuous flow?

There is a lesson to be learned from the waterfall approach. Yes, I said from the waterfall approach. We need to see what pieces of waterfall worked and how we can incorporate that into SAFe to make it more successful. GoodBRDs (Business Requirements Documents) and FSDs (Functional Specification Documents) written in the waterfall methodology by the product team had a very continuous flow. When you read through those documents, it felt like reading a story and as you were reading this story, you were slowly painting the big picture in your mind. Then after some BRD/FSD review sessions, that picture you painted in your mind became even more clear. As a solutions architect, having this picture in your mind is powerful; you can already start designing the overall system and it is just a matter of putting it on paper so that others can take the design and execute.

Let’s go back to the list of epics and how the overall story is NOT told by these epics and how we can improve this. I am NOT proposing that the product team writes 100-page BRDs and FSDs because those BRDs and FSDs also had some boiler-plate sections that did not contribute the to the story-telling.

However, I am proposing that the product team writes something that I call an executive story that will tell us the full story. This executive story would not be a book, but it would NOT be a 1–2 page document either because you can’t tell a story about a big initiative in 1–2 pages. This executive story would be written before any epics are written. This story would be presented to the program team who technically take a role of a book publisher. The book publishers don’t just take your story and publish it. They review it, criticize it and recommend revisions. Once this executive story is polished up and understood by the program team, then the program team proceeds with creating epics and the remaining steps in SAFe.

It is crucial that you keep adjusting the executive story as the requirements that impact the main story get introduced throughout the execution from sprint to sprint and from release to release.

So the epics are just the mechanism for getting things delivered, but the executive story is there to always reflect the current big story or the story that is being executed.

Conclusion: If somebody asks the product team to provide the summary of what the initiative / project is about, they are not going to provide somebody the list of epics to read. For example, you are not going to make your general manager read a list of epics and tell him/her to paint the picture after reading dozens of epics; that would not be right. There is an elevator-pitch summary and there is also an airplane-ride detailed version that I described as the executive story. The executive story is not only for executives; it is written with technical details geared towards the program team (solutions architects, product and project team) and it meant to tell the overall story in a continuous flow.

Almir M.