Process

Tushar Paunikar: Agile and the KRA Conundrum

Quote Posted on Updated on

Reblogged with permission from , 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.

Read the rest of this entry »

Advertisements

SAFe© – The Program Dependency Board, a real life working example

Posted on Updated on

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):

Read the rest of this entry »

How to describe a Fractal in Agile

Posted on Updated on

A fractal is a mathematical set that exhibits a repeating pattern displayed at every scale.

Modularity and Fractal behaviors of scaling “Agile” frameworks. Do you see the consequential behavior of scaled Agile implementations as fractal patterns? Shouldn’t they be or are they?

Should a team’s relative estimating be fractal? performance in value and successful outcomes?

Any math nerds want to help out a coach? Does the analogy work?

Admittedly, I’m not smart enough to wrap my head around much more than simple addition and subtraction. I do see the similarities and I am always looking for better ways to describe what we teach. Thoughts?

Defining Velocity for relative estimating teams (Agile)

Posted on Updated on

Defining Velocity

Let’s define “velocity” in “Agile” (or should I say more accurately relative estimating teams?) terms before we get started so that we have a shared understanding of what the community and thought leaders have to say.

524px-Kinematics.svg Read the rest of this entry »

The thought leaders that lost their way

Posted on Updated on

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.

Read the rest of this entry »

The Agile End Game 

Aside Posted on Updated on

And the Agile Game of Thrones continues, a self-defining and destructive process where no people or processes or frameworks win. Everyone loses. The Agile End Game.

Next time can we do it TOGETHER?

Or, perhaps we should work on common ground now to defeat the enemies that so called “Agilists” claim to challenge?

How Do Committees Invent? /Conway’s Law

Posted on Updated on

Have you ever worked in an organization run by committee? All decisions requiring consensus, even the minutiae? Immutable command and control structures that were often too busy to collaborate with underlings? What did their results look like? I like how Mel ties in the social construct and communication into the discussion of organizational structures. How we work together is important, just like what we are working on.

To the extent that an organization is not completely flexible in
its communication structure, that organization will stamp out
an image of itself in every design it produces.
… Because the design that occurs first is almost never the best
possible, the prevailing system concept [the design] may need to
change. Therefore, flexibility of organization is important to
effective design. Ways must be found to reward design managers
for keeping their organizations lean and flexible.

-M. Conway

http://www.melconway.com/Home/Conways_Law.html