1. Home
2. Blog
3. SAFe. Exploring client needs. PM and PO role

In our previous article, we talked about Epics and the related processes. But companies have clients who need their needs to be implemented as fast as possible. Who manages all these requests? Who translates them into things which teams can then implement? Who validates the results of the implementation? This is an easy answer because in Scrum there is a specific role called the Product Owner who deals with all that. Are these activities and this role present in SAFe as well? The answer is yes, but with a big twist.

 

The Product Owner in SAFe (Scaled Agile Framework)

 

First of all someone needs to manage the clients. To always be in contact with them. To constantly explore their needs, answer their requests, prioritize them and define a roadmap of deliveries. Not only that, but this guy has to be an expert in the specific domain of the product or service under development. He needs to monitor the market and business context changes. He also needs to be able to look into the future and anticipate from an economic standpoint what makes sense to be implemented or not.

Secondly the teams need a constant presence from someone who is a functional expert and can help them translate the needs coming from the customers into stories which they can understand and implement. Help them prioritize the work, answer any questions they might have during day to day activities. They need a guy to handle changes in requirements, in scope and priorities from a pragmatic point of view while still considering their technical needs. They need their progress to be communicated to the business people in a way which can be understood and responded to.

 

Looking at the previous two short sections, do you think a single person can handle both areas? SAFe people say no! That is why they have defined two separate roles: the first one is client and business facing and is called the Product Manager. The second one is team and technology facing and is called the Product Owner. Does this separation bring a bit of complexity and maybe conflictual points of view? Maybe, and that is why these two guys need to work most of the time as a single entity.

 

When talking about “work break-down” these two roles, working in collaboration with the Epic Owners, will slice the Epics into Features and then into Stories, provide estimates (involving the teams as necessary), work with them during the implementation phase and then re-aggregate the Stories into Features and the Features back into Epic MVPs and Epic implementation.

 

 

Building large systems. Cone of uncertainty. Planning horizons

 

The next section refers to an organization that needs to build a large solution, a system that involves thousands of people, has a lot of subcomponents, needs a lot of interaction and also incorporates stuff coming from third party suppliers as well. Do you think the development and delivery of such a system can be handled by an agile approach?

 

By now you should know that the answer is yes. SAFe has a configuration dedicated exactly for such companies which is called “Large Solution”. This organizes the enterprise into a structure called Solution Train with the purpose of modelling all the needs of a big system implementation. It starts from defining the needs as Capabilities, slicing them into Features and Stories, implementation, aggregation and validation. This configuration defines that the Solution Train needs to be composed of multiple Agile Release Trains, incorporates the third party suppliers and takes care of Solution integration aspects and parallel but equally important concerns, like compliance for instance. You will also find all the roles and functions that are collaborating within this organization.

 

During the iterative implementation of any solution all we are doing, at an abstract level, is aimed at reducing the “cone of uncertainty” in relation with the features (scope) and design that will result in a successful system capable of serving the real customer and market needs. The cone of uncertainty is a metaphor emphasizing that in the beginning the amount of unknowns is quite big, but by using the iterative approach, these uncertainties are transformed into fixed knowledge, fixed design and fixed scope. These iterative steps constitute learning cycles and if we look at the way the processes are defined in SAFe we can identify them starting from the team level, on a daily or Sprint basis, going up to the Product Increment cycle, at the level of the ART, and Solution Increment for the Solution Train.

 

Ceremonies for running learning cycles in SAFe (Scaled Agile Framework)

 

There are specific ceremonies helping to run these learning cycles at each of the three levels. Ceremonies like Product Increment Planning, Pre and Post PI planning meetings, System and Solution Demo. The Solution builders need to understand that the biggest of these cycles actually controls the evolution of the system and new functionality cannot be added faster than the slowest integration frequency. So when trying to optimize the delivery of value and make it more efficient, the approach should be top to bottom.

 

Because everything is Agile and even such a big organization will have to be capable to quickly respond to change, a false impression could be created. The impression that in the Agile world there is no planning, there is no control and everything is a just a chaos. But if we look more closely we can see that in fact in Agile there is actually more planning than in a traditional approach. In Waterfall for instance, all the plans happen at the beginning and the assumption made is that you can foresee the future with a high level of precision.

 

In SAFe, and being in the context of a Large Solution, we can identify at least five planning horizons going from a high level of details and strong commitment up to the more coarse grained and less committed on:

• Daily plan at the level of a team – happening mainly during the Daily Stand-ups
• Iteration/sprint - plan defining the work a team will work on during the next iteration
• Product Increment planning - at the level of the Program and covering Committed Features and Enabler for the current PI
• Product Roadmap - covering short-term (3-4 PI) estimate of Features and Milestones
• Solution Roadmap - covering a multi-year vision, milestones, events, and roadmap for the Solution