SAFe’s emphasis on writing Features and waterfalling them into the Agile Teams is unfortunate.

This approach can easily result in what is commonly known as a “Feature Factory”. In a Feature Factory, the focus is on discovering and writing Features. Unempowered teams are handed Features to go off and build. This makes the Agile Team accountable for delivering Features (an output), instead of true business outcomes. It stifles innovation as Developers are rarely involved in solution discovery. It positions the Developer as a robotic order-taker verbalizing the incessant refrain of “Just tell me what to do”.

I had high hopes that I was wrong. I re-reviewed several SAFe knowledge base articles that potentially addressed my concern:

  • Design Thinking
  • Continuous Exploration

The SAFe Design Thinking article covers discovering and designing the right solution, measuring success, generating insights, and fast prototyping. But read the article carefully… All of this effort is described as a means to an end – to write desirable and useful Features and feed these Features into the ART Backlog for the Agile teams. A more efficient Feature Factory model. Slaves to Features.

The SAFe Continuous Exploration article covers Agile Teams involved in exploration of customer needs, customer visits, Gemba walks, and brainstorming solutions. But again, read the article carefully… Like the Design Thinking article, the end goal is to write the needed Features and get them into a backlog. A more efficient Feature Factory model. Slaves to Features.

Not good!

Comparatively, the Product Operating Model (POM) concept of “empowered teams” accountable for business outcomes is a clear winner. In POM, the focus is on solving customer problems and delivering business results.

Imagine a world where the significant time, effort, and cost of writing Features up-front is replaced with validated learning cycles. That’s right – instead of writing Features, let’s pair the Agile Team up with the Customer/Stakeholder, give them a problem-to-solve, and ask them to jointly discover a good solution that is valuable, viable for our business, usable, and technically feasible.

Once the solution is agreed to, the Agile Team can decide the Stories and Features needed in support of incremental delivery of value. In some cases, Features won’t even be needed! Then build and deliver the value.

Notice that Feature writing is relegated to the Agile Team and not required as an up-front activity. It becomes a natural activity after the solution is agreed to in support of planning the incremental delivery of value. It belongs within the Agile Team.

Product Operating Model for the win!

Wrap

Consider an empowered team model when thinking about an Agile transformation. Don’t get caught in a situation where the brainpower in your Agile Teams is only partially utilized!

Contact us for your SAFe training needs here. For more on SAFe, visit here. For more on what all is typically involved in an Agile transformation, visit here.

I would love to hear your thoughts and experiences!