3

I have a question about this article "The Role of PI Objectives", where the author stated near the end of the article:

As I captured these thoughts I was reminded of a key difference between release trains, and it strongly impacts the degree of value placed on the "focus on outcomes," above. I tend to see release trains fall to one of two extremes: Either they drive the vast majority of their work, 85-95%, through portfolio epics, and reduce the autonomy of the trains; or they drive the vast majority of their work as features, and reserve epics for the 5-10% of work that truly cuts across trains. While I don’t view either of these approaches as fundamentally wrong, I do believe that we will see that a majority of companies solving the big "system of systems" engineering problems, encouraging a strongly epic-driven approach, will find that SAFe for Lean Software Engineering will be a more effective approach.

Am I understanding correctly that if I had to choose between:

a) organizing trains that are strongly epic-driven

b) organizing trains that are strongly feature-driven

you would recommend (b)?

In recent conversations on how to best organize trains, one proposal has been more along the lines of (a) - where we would form trains by looking at our epics and assigning epics to a train, and then organize teams in each train in a manner where we form cross-functional teams to support individual epics (or form teams that could support multiple epics.)

Any feedback anyone can provide would be greatly appreciated!

Improve this question
4
  • Welcome to Project Management Stack Exchange (PMSE)! I edited your post slightly to seek answers from any PMSE member knowledgeable in SAFe.
    – Ashok Ramachandran
    Apr 23, 2015 at 17:23
  • 1
    I havent't read the article, but just judging from the wording, the author says that if you go for an epic-driven approach, SAFe for LSE (safe-lse.com) is more effective. I don't think he's making a recommendation to use one or the other. My assumption would be that the answer to "what would you recommend" would be a resounding "it depends".
    – schaueho
    May 5, 2015 at 17:18
  • @Christine Would you describe your organization as one that deals with "systems of systems"? Do you deal with both hardware and software?
    – Michael Hogan
    May 14, 2015 at 4:48
  • IMO, choosing between EPIC drive or Feature driven RTs is simply a matter of whether or not individual features are directly interesting/marketable or not. In some cases they are, an in some cases they are not, which is essentially in line with the "system of systems" kind of characterization that the author is trying to drive at also.
    – Amrinder Arora
    Nov 17, 2015 at 23:11

1 Answer 1

Reset to default
1

I would lean toward trains that are feature driven for one simple reason: Releasing any package to production, as long as it is not only customer facing but customer-impactful, is much more than an engineering effort. It is an effort that spans disciplines and business units. Sales needs to be able speak intelligently to the customers about it, support needs to be able to do the same, marketing may want to build collateral around it etc. A customer can more easily understand and appreciate new (or simply improved) features than anything else, so you may as well organize your efforts internally to reflect that point of view. It is one more step towards being customer focused.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.