Skip to content

Rants of a Madman – Agile and Performance Objectives – Only Pigs Allowed on the Field

July 12, 2013

I love Agile.  I also love Performance Objectives and Management By Objectives.

There was a product manager (a position often found in commercial software companies and not in IT) that I knew once who was the product owner for an Agile team.  In this role this person was responsible for the what and the why whereas the team was responsible for the how.  That said they couldn’t make a decision if their life depended on it.  It was always “well maybe we could do this” and “well maybe we could do that.”  I swear, if they were standing in the street and a loaded tractor trailer rig was barreling down on them full speed from blocks away they would have analyzed all of the possible moves and potential outcomes, but at the end of the day they would have wasted all their time vs. just getting out of the way.  I’m serious.  One would think the agile thing to do would be to get out of the way, then upon reflection in a retrospective (after they achieved their goal) decide if they would have done so differently with even better results next time.  Not so in this person’s case.

The problem for this team is that they never had any story cards to work on.  There just weren’t any.  There were just so many unexplored options that had to be considered and evaluated by this product owner.  On the flip side it did make it really easy to groom the backlog…there were no stories to groom.  Time would slip by with the team doing busy sustainment work vs. actually working on new product capabilities.  Marketing, Sales, and Management were not too happy about the situation as they wanted new, meaningful product releases that lived up to the hype of what was promised to them in various meetings earlier in the year.  There was a lot of finger pointing back and forth as commitments were missed, but at the end of the day the development team was always hung out to dry.  After catching the blame one too many times the team finally revolted, self-nominated their own product owner to act as a proxy, and simply leveraged the product manager for input.

There was another case of a different product manager who as the product owner for an Agile team who had a very similar problem, but they had no issue when it came to making decisions.  They made lots of decisions; tons of them every day, but most of them revisiting previous decisions.  Not only would they think “well maybe we could do this” and “well maybe we could do that”, but they insisted on taking the development team along with them for the ride.  Every idea was a story and this product owner would insist on even interrupting the sprints to change the stories out from underneath the development team as they were working on them to try the other alternative.  I know Agile is designed to embrace change, but the healthiest change is scheduled for future sprints (one should never really ruin the cadence of the team by messing with the current sprint in flight).  That said this product owner would shout from the rooftops “Agile is supposed to allow me to change my mind and you are not being Agile if I cannot change what the team is doing whenever I want; we might as well go back to waterfall!”

In this case the development team just thrashed as it constantly reworked code over and over and over again.  They couldn’t even try to spin it as “refactoring” as they were in a constant state of rewriting what had already been done.  As you can guess a similar blame game came in to play near the end of the project:   the development team had an innate inability to make its commitments to the business.

In both cases these product owners were experts at always throwing the development team under the bus for missed schedules and commitments.  They felt that they were playing their roles and were therefore doing their jobs.

So what does this have to do with Performance Objectives?

My issue, quite frankly, was that everybody’s top job should have been to deliver high quality products on time that delight customers.  Period.  Doing so should have been the shared performance objective for the product owner, scrum master, and all the team members. 

It wasn’t that the development teams were not making their commitments; it was that the Agile teams were not.   Let’s rephrase this:  If the development group isn’t making their commitments then the product owners should share in missing that shared commitment as well.  Had the product managers also had this shared objective as part of their own performance objectives then everybody might have worked together much better.

As many of you look at 2nd half of the year and are revisiting your performance objectives for the second half, let’s make sure that everybody is a pig and nobody is a chicken.

Don’t know what I’m talking about?  Go to Google and type “Agile pigs and chickens” and enjoy.  Wikipedia has a quick recap:  http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig

 

About this series:  I love Agile; I also hate Agile.  I love how it can free teams to truly delight customers while delivering high quality products on time.  I hate how Agile zealots can use the Tower of Agile Babble to confuse the heck out of teams trying Agile on for size.  My goal is to help new teams actually embrace and become Agile without having to learn all of the pomp and circumstance in one big fat swallow.

Advertisements

From → Agile

One Comment

Trackbacks & Pingbacks

  1. My Most Popular Blog Post In 2013… | Mark Lawler

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: