How Epics Get Things Done
“Always show your working out!” was the mantra of my maths teacher in senior school. This series of blog posts “On the Nature of Lean Portfolios” is an exploration of Lean Portfolios. It is the thought processes running through my mind, exploring the possibilities so that I understand why things are happening rather than just doing those things blindly. It is not intended to be a fait-accompli presentation of the solutions within Lean Portfolios but an exploration of the Problems to understand whether the solutions make sense. There are no guarantees that these discussions are correct, but I am hopeful that the journey of exploration itself will prove educational as things are learnt on the way.
Please also see the free upcoming webinar based on this blog content!
How Epics Get Things Done
We’ve discussed the lifecycle of Epics extensively in these blog posts, the progression that it goes through to try and achieve success, but we’ve not yet touched on the practicalities of how Epics get things done, how Features are negotiated into the backlogs of the Development Value Streams. There are some interesting discussions here because the process is driven by the relationships and behaviours of the Epic Owners and Product Managers and how those relationships play-out will have a significant effect on the smooth running of the Portfolio.
Fig 1: Epic Feedback Loop
As a reminder, this is the Epic Feedback loop and it’s the “Negotiates Work Into” link between Epic Owner and Product Manager that this post is exploring.
Don’t Interpret the Hierarchy Literally
If you interpret Scaled Agile’s Big Picture literally, and some peoples brains are wired for literal interpretation, then Features come from Epics. The Epic Owner dictates to the Product Manager what the Features are, an it’s from this that some of the criticisms of SAFe arise, perhaps the critics are also very literally minded.
Fig 2 : Not Feature Hand-down
It doesn’t have to be a dictatorship, although this is what many organisations fall into because they’re recreating the old behaviours within the new system rather than using the new system to encourage behavioural change.
Ideally the Product Manager responsible for the backlog of Features would be empowered with the responsibility for the Product and everything associated with the Product. That’s why the Agile Product Management course that Scaled Agile provides talks very little about the SAFe Framework, but instead covers techniques for interacting with customers, it talks about the viability and sustainability of the product and examines pricing strategies. The Product Manager is engaging with the customers, and facilitating the Product Owners within the Agile Release Train to engage with the customers too. Collaboratively, as a team, the Product Manager and Product Owners own the Product. Therefore the Product Management Team is best placed to understand the customers needs and should be soliciting ideas for Features from the customers and getting them onto the backlog. This is the sort of Product Management / Product Ownership that Marty Cagan encourages, he doesn’t like SAFe, perhaps he’s interpreted the diagrams too literally, but the only thing stopping the Product Managers from being empowered is the will of the organisation, and that’s true regardless of whatever framework is being utilised. Without wanting to denigrate anyone currently in the Product Manager role, often organisations put an individual in place as a proxy rather than the person that is ultimately accountable for the product and of course that creates an extra layer of communication that doesn’t need to be there.
If we’ve empowered our Product Managers to truly own the Product the Agile Release Train is responsible for, then what of Epics and Epic Owners? The Epic provides intent for a change to the business, the Epic Owner is communicating that intent. The Product Management team can work with the Customers to solicit Features that would fulfil that intent. As those Features are released the metrics on the Epic should prove whether they have fulfilled the intent of the Epic and influence the Product Management team’s conversations about what should be done next. It’s not just the Epic, the Portfolio Vision provides intent as well. An organization can’t blindly do whatever the customers desire, the customer requests need to be compared against the vision for the organisation to ensure that the organisation is viable into the future.
Fig 3 : Epic’s Need Help To Achieve Their Goals
SAFe Principle #8, Knowledge workers know more about doing their work than the management do, this statement also applies when you look at the hierarchies within SAFe. The people that know the Product will create better Features because they’re the people closest to the customers and interacting with the continually. Product Management should know more about their Product that the Portfolio does, but Product Management needs the vision from the Portfolio to validate whether the Features it’s creating look like they are contributing to that vision.
Connect With The Customer
Connect with the customer. It’s a step in the Business Agility Value Stream, it’s on the Responsibility Wheels of Product Managers and Product Owners and it’s an absolute necessity if the organisation wants to be Customer Centric.
Features can have many customers. The users are one class of customers, but there can be others. Regulatory bodies for instance; if their needs aren’t satisfied then the users needs are irrelevant because the product won’t be allowed to reach them. The engineers within the ART are also customers, they care about the quality of any changes because they want the product to be technically sustainable as they will be maintaining it in the future. From the perspective of this blog, the Epic Owner is a customer, they want this Feature to contribute to the success of their Epic.
This blog isn’t going to go into the detail of Design Thinking Techniques, and I’m fully willing to raise my hands and admit that I’m no expert on Design Thinking Techniques. The details of how to interact with the customer, how to get the customer’s needs from them and into the Feature, that is for the Product Managers to work out. Different customers, even to the same feature, may have different interaction patterns and require different engagement techniques.
That those needs have been found, from all of the different customers, is what’s important.
Many minds minimise mistakes
Design Thinking has solicited the ideas for Features, those that are going to be taken into PI Planning need elaboration so that everyone understands what the challenge represented by the Feature is. There’s no point elaborating Features that aren’t going into the next PI, put those Features into the backlog as a placeholder, onto roadmaps to visualise sequencing, but don’t elaborate them until they’re needed.
When a Feature does need to be elaborated it is best if that elaboration is done as a collaborative activity. Every time collaboration is mentioned, think knowledge transfer. The elaboration of Features is done collaboratively by the Product Management, Product Owner group through them questioning customers (and remember the discussion above that customers is not just the users) about what they want, this transfers knowledge from the people, the users, that have a need to the people, the Product Owners, that can fulfil that need by getting their team, or teams, to undertake the work to fulfil the user needs of the Feature. That the recipients of the work item, in this case the Product Owners, create the work item is a powerful trick, it means they have to have understood enough to be able to write it down, at worst they know who the expert is and can arrange for them to explain to the team. This also empowers the Product Owners to actively participate in ownership of the product, which avoids them become mere messengers, as discussed in the Principles and Preparation part of the blog series on PI Planning.
Many minds, many perspectives, you’re bringing the collective brainpower of the group to elaborating the feature rather than a single individual, therefore a much greater chance of catching errors and mistakes.
But Product Ownership isn’t the only input to elaborating a Feature, there needs to be technical input as well. Architecture, Compliance, Security, UI/UX concerns, these might all have input into the Feature. Getting those inputs in early so that they steer the development is preferable to those roles acting as gatekeepers at the end, throwing work back. This early input is the Shifting-Left, to earlier in the timeline, that you’ll so often hear in Agile circles. Don’t take my list of roles as exhaustive, you, or your Product Managers and Product Owners, need to work out who else should be collaborating to elaborate the Feature and invite those Subject Matter Experts along. Collaboration is also knowledge transfer, product knowledge towards the technical people, technical knowledge towards product staff. Enough knowledge to know when to involve those with specialist knowledge directly in the conversations.
The nature of the Features varies over time
You won’t know everything up-front, indeed trying to plan out all the work for an Epic up-front is an anti-pattern and a symptom of the old-world behaviours and processes persisting under the guise of some agile buzz-words.
If the Lean-Startup mentality is being followed then there tends to be a progression in the Features:
- Early features will be customer experiments to gain insight that this Epic is an opportunity worth pursuing further and sets the business vision and strategy.
- Later features are technical experiments to help validate that the opportunity, confirmed by the customer experiments, is technically feasible and set the technical vision and strategy.
- Later features get the product(s) related to this opportunity released, and into the hands of customers.
- Later features are created as a result of customer feedback and Product Management soliciting ideas for Features to move this Epic’s Business Outcomes towards their targets.
It’s the Epic feedback loop that is driving this, feedback from releasing Features informs the creation of future Features. It’s worth pointing out that releasing a Feature doesn’t always equate to a release of the Product. An enabler Feature that has done some experimentation, and that could be either customer or technical experiments, releases knowledge back to the organisation for decision making and planning.
Prescriptive Features are sometimes useful
As much as possible Features should not be prescriptive, they should be a challenge, a problem for the ARTs to solve, but there are some instances where the Features inevitably become prescriptive. Typically, these instances are not the problem-solving of engineering but are where the teams need to follow the steps in a larger process to achieve something and that process is non-negotiable1. Recently I’ve been working with a medical equipment manufacturer and there is a sequence of steps that they have to go through, once all the engineering has been done, to get the product through regulatory approval. The features relating to those steps inevitably become somewhat prescriptive: produce this paperwork, send that document, obtain 3rd party verification;
Conclusions
Epics get work done by negotiating work into the backlogs of the ARTs; done right the process can uphold the Lean/Agile Principles and Values and respect our goal of customer centricity by getting the Product Managers to elicit ideas from the customers that contribute to the Epic.
Next Steps
Now that we’ve explored how Epics Get Things Done, the next topic to explore is When Is An Epic Done.
#1 All processes are negotiable, but trying to negotiate changes to the process when actually doing the process is likely to be the wrong time to make changes. Use the Inspect & Adapt processes at the train level to negotiate changes to the process.
I hope that illustrates How Epics Get Things Done; watch out for the further blogs on Features and User Stories!