I&A Series – “Being assigned features after planning before the PI is complete”

I am starting a new series of posts where I will answer some actual problems/ideas presented in an I&A problem solving workshop as part of open space facilitation. This is the first of a few dozen that I plan on covering. If you have any comments, please, let’s learn together.

 

Problem/Idea #1:

 

“being assigned features after planning before the Program Increment planning (PI/PIP) is complete”

 

A SAFe Answer

From a SAFe (and Scrum/Agile/Kanban) perspective, features (or stories) should never be assigned to a team. This is a common anti-pattern/fragile action that occurs during the early stages of cultural change where people are learning to let go of their theory X selves and dismantle the old belief system that people are dumb oxen that must be led by a bridle.

The SAFe uses a Kanban pull system vs. a push system of flow of work (a chain of possession of work) through backlogs at the Portfolio to team levels. This is learned from two primary facets of the body of knowledge and understanding, the mechanical elements of the framework/method/process and from the value systems and principles.

A key aspect of the value system/principles in the SAFe is self-management and self-organization. What are other parts of the value system and principles at play in the SAFe?

Namely:

1. The four SAFe core values of alignment, transparency, program execution, built-in quality, and 9 principles
2. The four core values of the Manifesto for Software Development and 12 principles
3. The values and principles of
   1. Scrum,
   2. XP,
   3. Lean thinking,
   4. Systems thinking,
   5. DEVOPS,
   6. and The Lean Startup cycle

 

It is interesting how much the various framework/methodologies value systems and principles align. They could also be aligned along a spectrum (think!).

Take your Theory X and s**** it

“Assignment” invokes Theory X management style and does not support the idea of self-management/organization.

The right question

Perhaps the better question is “how are features pulled by teams after the PIP event in the SAFe?”

Assuming the Portfolio management function in a SAFe implementation was followed adequately through the portfolio backlog, to the solution backlog and then on to the program backlog…

Features are prioritized in the Program Backlog by the Product Manager(s) (team) based on the business context, cost of delay, job size, and goals for the product(s). The Program Backlog Workshops conducted regularly (formally and/or informally) for products in the value stream address prioritization through Weighted-shortest-job-first or WSJF (at the feature/program level). Within a cross-functional self-organized ART any team on the train with domain expertise/purpose for the scope of the feature could pull the feature.

Now the question posed was how to do this after the big room PI Planning occurs. Well, naturally some folks will say, “you should already have a plan with full capacity allocation for the duration of the PI.”

True that. BUT, we are also practicing Agile behavior and becoming innovators. So, we inspect & adapt to changing business context all the time.

There are many potential reasons why a team could find additional capacity during a PI to pull a new feature. None of which I’m going to discuss here because that is an article in of itself.

As reason tells us, just because a feature is pulled by a team during the PI, and post PIP, does not automatically equate to a commitment to completion of the entire feature during that PI. Feature slicing people! If a “working software/widget/service” slice can be delivered to the DoD in an iteration then there is potential for value to be created and delivered. Take advantage of opportunities to create and deliver value to your customers — always — they’ll love you for it.

As always in SAFe, the program backlog and PBI’s is owned by the Product Manager (PM) role and the feature pulled should be collaborated on with the PM. This is not to be confused with the Team level Product Backlog and Team Backlogs.

So, teams could conceivably come upon more capacity mid-PI and collaborate with their POPM to pull a new feature into their backlogs in the form of user stories and/or enablers. Be careful and remember that excess capacity is an indicator of out of control development. Don’t let it be a pattern.

Step 1 – always, is to collaborate with key stakeholders – POPM, EA, RTE roles and the ART.

Step 2 – decompose

Step 3 – estimate

Step 4 – sequence and plan

It is also important to remember that teams do not belong to POPM roles/team, they are only associated because of the nature of the domain purpose of the team.

 

Acronyms:

PI – Program Increment
PIP – Program Increment Planning
RTE – Release Train Engineer
POPM – Product Owner/Product Manager
ART – Agile Release Train
DoD – Definition of Done

I encourage all readers to check out the SAFe© guidance article on the subject before reading this article. SAFe© and Scaled Agile Framework© are registered trademarks of Scaled Agile Inc.