I&A Series – “As a member of the leadership team we need to see the portfolio roadmap with early warning signals / input for potential technical or schedule issues”
I started 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 second of a few dozen that I plan on covering. If you have any comments, please, let’s learn together.
“As a member of the leadership team we need to see the portfolio roadmap with early warning signals / input for potential technical or schedule issues”
A SAFe Answer
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.
“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.
Quote Posted on Updated on
Reblogged with permission from Tushar Paunikar, the original author of this content, as a contributor to blogagility.com. Originally published on LinkedIn August 3, 2017.
You always have a choice! If you think about it, you always have a choice. No matter how hard it is to accept, but you always have a choice.
The alarm goes off at 5 AM! You have a choice.
Not feeling too upbeat to go to work? You have a choice.
Bored with the daily mundane tasks you are required to perform at work? You have a choice.
Disillusioned with the state of affairs of the current government? You had a choice. Rather you will again have a choice.
Quote Posted on Updated on
Reblogged with permission from Tushar Paunikar, the original author of this content, as a contributor to blogagility.com. Originally published on LinkedIn, November 22, 2016.
Life can be pulled by goals just as surely as it can be pushed by drives. -Viktor E. Frankl
Metrics drive behavior. I bet all would agree. We have experienced this umpteen times in our professional life. Even our personal life is abundant with examples where metrics influence people’s behavior.
If my kid has the target to score an ‘A’ in Math and that target is linked to a new bike, he will try to find insincere ways to achieve his target, if he sees his attempts to study sincerely may not be fruitful.
If a developer has the target to maintain 80% code coverage and that target is linked to a quarterly Most Valuable Player award, (s)he will try to find nasty ways to increase code coverage, if (s)he sees that all attempts to write meaningful unit tests may not meet the project deadline.
I promised a picture of the (jokingly) “super duper dependency board runway” (PDB) for our Agile Release Planes (ART) two weeks ago from my amazing uber client people at ESC. Well, here you go.
before the ART 1 and ART 3 PI4 Planning (P4 PIP):
Kent Beck – “This Agile thing should be about the need to heal the divide between business and development.”
And here we are in 2017 with scaling framework zealots launching rockets and starting wars bashing other frameworks? Doing exactly what Mr. Beck’s vision was against. Not debating ideas in the marketplace respectfully. Outright disrespectfully bashing and promoting misinformation campaigns.
WHY? Have you lost your way illustrious thought leaders? Aren’t we supposed to be better than this as change agents for good? What happened to healing the divide between business and developers?
Why are you creating divisions in this fledgling “Agile” revolution? For money? Fame?
This is not “Agile” behaviour.
SAFe© and Scaled Agile Framework© are registered trademarks of Scaled Agile Inc.
I am no artist but at least I try. Here are the general guidelines to develop PI Objectives. Try not to regurgitate your teams pulled features as objectives. Think about how your team is going to deliver business value to the customer.