In the microservice architecture where you have a collection of APIs that consume each other directly or via pub/sub approach, and Front End components that consume APIs, it is important that you execute the development of your features/epics and user stories in a fashion that allows product management, you and stakeholders to see progress and journeys working very early (Sprint 1 or 2).
API contracts need to be negotiated from day 1 and the stubbed version of APIs need to be developed and as the development progresses from sprint to sprint, these APIs will start to form shape.
As for the Front End, you need to have a website working (journeys working) from Sprint 1 and that website maybe using a lot of stubbed versions of APIs which is totally ok. It will evolve as you progress from sprint to sprint and less and less of functionality will be stubbed out.
Conclusion: Develop layers of the cake instead of slices of the cake.
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.
In a lot of cases, companies don’t hire part-time scrum masters or they convert a “technical lead” role into a “scrum master / technical lead” role. What really happens here is that something will have to give. Whether that’s going to be a lack of big picture planning, or impediments not being removed as fast as we would like, I am not sure. One thing for sure is that something will have to give.
In the case of technical leads taking on a part-time scrum master role, it means that the word “technical” in technical lead slowly loses its meaning. Within X number of hours on the given day, that technical lead would be doing less and less of coding and technical work. This could be good for the given technical lead if they want to grow their career into the direction of management, but it is not a good direction if you as a technical lead want to advance your career in the direction of software architecture positions. Let me rephrase this. Any temporary exposure to this type of work is good for people’s career, but I am mostly talking about long term impact exposure.
What could be possible solutions?
It all depends on your organization and what positions and it roles and responsibilities would be closer to the scrum master role in order alleviate some of this work from technical leads who are supposed to be guiding the team at the technical level and also using their knowledge to help out solutions architects and keep solutions architect in check with the reality. Development managers could help out alleviate most of these scrum master responsibilities in the cases when a dedicated scrum master role is not created. In some organization, project managers could perform that role. Maybe there isn’t one solution for all of this. Maybe on some teams, project managers do it. Maybe on some team, development managers take responsibilities.
Perhaps in some cases the technical lead is willing to also cover the scrum master responsibilities but this dialogue has to happen and no assumptions should be made. A short team help from technical leads with these responsibilities should be fine, but if a technical lead is not willing to take on these responsibilities in long term, it should NOT be looked at as a negative thing in that person’s career move within that organization. The organization should be happy that this person’s technical skills would be used to guide the technical team and that energy could also be channeled into technical innovations.