Category Archives: Teams

Annual Performance reviews hazardous for team performance

Posted on by
Reply

Performance Review Game

You don’t have to go farther than your own personal experience to know that annual reviews completely fail to motivate, inform, or protect people.  If you’re own experience is not enough try comparing notes with peers, reading JoelOnSoftware, and PeopleWare by DeMarco.

If you’ve got a great performance from an individual, a review is likely to hamper it.  If you’ve got a great team then individual reviews are likely to sabotage it.  Really.  This is 100% true and there’s plenty of research to back it up.

Managers – if you are relying on performance reviews to create great employees and teams then you’re feedback is way way way (way) too late.  If you are relying on inventive pay to build your feedback is not only too slow but likely to cause more problems then you imagine.  Most of these systems only show employees that they are not valuable and build up your (the manager’s) ego.  If that’s not intuitive to you then you need to educate yourself.  Read and learn.  It’s not too late!

Here’s an NPR article supporting the evidence:  Annual Job Review Is ‘Total Baloney,’ Expert Says.  Employee performance reviews should be eliminated, according to Samuel Culbert: “First, they’re dishonest and fraudulent. And second, they’re just plain bad management.” The UCLA business professor has written a new book expanding on that view.

Death by Ant Bytes

Posted on by
Reply

Or the Dangers of Incremental Complexity

Products are not built in big bangs: they are painfully crafted layer upon layer, decision after decision, day by day.  It’s also a team sport where each member makes countless decisions that hopefully help flow towards something customers love.

In fact, these decisions are so numerous and small that they seem to cost nothing.  Our judgment and creativity to builds the product crumb by drop.  Each and every morning we shows up for work ready to bake wholesome chocolaty goodness into the product.   It’s seeming irrelevance of each atomic bit that lulls us into false thinking that every addition is just a harmless Pythonesque “wafer thin”  bite.

That’s right, not all these changes are good.  It’s just as likely (perhaps more likely) that the team is tinkering with the recipe.  Someone asks them to add a pinch of cardamom today, pecans tomorrow, and raisins next week.  Individually, these little changes seem to be trivial.  Taken together, they can delay your schedule at best or ruin your product at worst.

Let me give you a concrete example:

In a past job, we had to build an object model for taxis.  At our current stage, this was pretty simple: a truck has a name, a home base, and an assigned driver.  One of our team independently looked ahead and decided individually that he should also add make, model, MPG, and other performance fields.  He also decided that assignments needed a whole new model since they could date range (start, end) and handle multiple drivers.  Many of you are probably thinking all this was just what engineers are supposed to do – anticipate needs.  Read on…

By the time he’d built the truck model, it had taken 5x as a long and resulted in 100s of lines of code.  It got worse the very next week when we built the meter interface code and learned more about the system.  For reporting requirements, MPG and performance fields had to be handled outside the taxi model.  We also found that driver assignments were much more naturally handled by looking at fare information.   Not only had we wasted a lot of time, we had to spend even more time reversing the changes we’d put in.

One of my past CEOs called this a “death by ant bites” and “death of a million cuts.”

It’s one of the most pernicious forms of feature creep because every single one of the changes can be justified.  I’m not suggesting that all little adds are bad, but they all cost something.   Generally, if someone says they are anticipating a future need, then you’re being bitten by an ant.

You need to make sure that your team is watching each other’s back and keeping everyone honest.  It’s even better to take turns playing devil’s advocate on each feature.  It’s worth an extra 10 minutes in a meeting to justify if that extra feature is required.

PS: Test Driven Design (TDD) repels ants because it exposes the true cost for those anticipatory or seemingly minor changes.  That “10 minute” feature is really a half day of work to design, test, integrate, and document.  If it’s not worth doing right, then it’s not worth adding to the product.

Wearing the Cape

Posted on by
Reply

Or Team Death by Heroism

I remember the day that put on the hero’s cape and I killed our team.

A few years ago I would have felt really good about saving the deadline and exposing the deadweight we’d been carrying on the team.   I’d get a good performance review, a bonus, and some expectation that I’d be picked first on the corporate playground baseball team.  Everyone was oblivious that I just cost the company a lot of time and money.

So with all this goodness raining down on me like gumballs in an Adam Sander movie, how does wearing the cape cause team death?  Let us count the ways:

  1. I’m going to do my job badly.  A Hero only focuses on winning the day.  Like Batman saving the Gotham, we aren’t worried about the collateral damage.  We don’t care about the unfortunate drivers in the way of my super awesome armored tank-bike!  Can you afford to have documentation, cross-training and automated tests become collateral damage?
  2. My teammates are going to feel pretty crummy.  Who gets to be Aquaman on you team?   I’m telling them that they could not do their job so I’ve got to do my job AND their job.  There’s no way to sugar coat that ego buster and their not likely to offer much help after that.
  3. Decisions will be one-sided.  Without a team, the hero has no balancing ideas and will go racing off into obvious traps and dead-ends.  On my latest hero project, I worked all weekend and was told on Monday that there was a check-box on the operating system that would have done the same thing!  Doh.  Why didn’t my teammate give me a heads up on Friday?  Why should he bother – it was better cinema to watch me ricochet all over the project.
  4. Heroes require drama, so nothing will ever stabilize.  It’s silly to dash and keep saving the day if everything’s working pretty well.  Once I’ve put on the cape, I’m much more likely to invent crises to solve because most of the work that is needed to ship a product is pretty drama-free.  Some of the heros I’ve met just leap from job to job faster than a speeding bullet.

Looking for some kryptonite?  It’s not that hard to find:

  1. Stop rewarding heroics with praise, money, pizza, or beer.
  2. Make the hero take a long vacation, transfer them, or fire them.  Really, you can live without them.
  3. If you’ve got a hero, pair them with another person (they can respect) to minimize the damage.
  4. Have heros take on the grunt work instead of letting them cherry pick the best work.
  5. Stop the team.  If you believe team needs a hero then you need to reevaluate your deadlines, feature list, or external messaging.  Generally, an emergent hero is a symptom of a larger problem.

Wonder team powers, activate!

Screening Recruits for Agile Savvy

Posted on by
2

We’re hiring new managers and developers into my team and its important (to me) that we find people who will embrace our Agile processes.

Sadly, many people experience with the fluffy Agile decorations and not its core disciplines; consequently, interviewees will answer “yes, I’ve done Agile” and not really (IMHO) know what they are saying.

So I wanted to craft some questions that will help identify good Agile candidates even if they have no experience (or negative experience) with the process.

  • Explain a time that you did not agree with a design decision that was being made. [Good candidates will tell you that they had a healthy debate about it, made sure they were heard, and then supported the team decision.  Excellent candidates will give you a specific case where they were wrong and the outcome was better their suggestion.]
  • How have you handled the trade-off between shipping quality software and getting a release done on time? [Good candidates will be pragmatic about the need to release but own quality as their responsibility.  Excellent candidates will talk about implementing TDD and automation so that quality can be maintained throughout a release cycle.]
  • How have you made changes to your work habits based on retrospectives? [Good candidates will tell you about items where they had to acknowledge other people’s suggestions and change their behavior.  Excellent candidates will be excited about having ownership in their team’s continuous improvement and can give examples.]
  • Why are sprint reviews important? [Good candidates will say that it’s important for a team to show progress to other groups.  Excellent candidates will tell you that it’s how a team shows that it is meeting its commitments and getting feedback to improve the product.]
  • Is it possible to achieve the objective to be “ship ready” at the end of each sprint? [Good candidates will say that ship ready is a great target but only practical in the last sprints before a release.  Excellent candidates will explain that being ship ready is a core driver for the process that ensures the team is focused on priorities, quality, and breaking work into components.]
  • Tell me about the best performing team that you’ve been part of. What made it a great team? [Good candidates will tell you about having quality people or a very tight focus.  Excellent candidates will tell you have the shared goals of the team and how people gave up individual recognition to accomplish team objectives.]
  • What does it mean to for a team to be transparent? [Good candidates will talk about status reports and documentation.  Excellent candidates will talk about being willing to take risks and fail fast.]

If they can’t pass theses questions then go buy a lifeboat.  You’ll want it for that that waterfall you’re going to be riding down shortly.

Don’t confuse the decorations for the process!

Posted on by
2

Or “Icing is pretty, but you need a cake too!”

Good Agile Process books will explain in chapter 1 that the stand-ups, iterations, demos, retrospectives, long planning meetings, et cetera are all “decorations” for the process.  This is an important concept that gets completely lost when they spend the next 43 chapters talking about how the decorations are used to support the process.

The decorations are not the process!

Having stand-ups does not make you agile.  Doing work in sprints does not make you agile.  Using story- cards does not make you agile.  Doing retrospectives where people share honest feedback does not make you agile (but could help you become agile if you actually take the feedback).

Agile is a business discipline.

Agile teams have the discipline to focus on delivering a product that generates revenue.  Management supporting agile teams has the discipline to reward team work.  Product owners have the discipline to provide crisp actionable priorities.  Everyone has the discipline to be transparent and willing to adapt as the environment evolves. 

These disciplines are hard to build and maintain, but they are fundamentally valuable.  They are honest and practical.  They are revolutionary.

Now, if you embrace the agile disciplines then the decorations will reinforce your efforts like mocha fudge icing on a double-dutch chocolate groom’s cake.

Unfortunately, if you lack the discipline then the decorations become a whip used to micromanage teams into a long frustrating death march.  Sadly, I’m finding that this experience is the more common one in the industry. 

Bon appetite!

Won to End (1..N) Ranking

Posted on by
Reply

Or I can buy a new toothbrush in Newark

Our team had a breakthrough moment last week, we changed our MRD* into a prioritized (1 to N, no ties) list and immediately identified some artificial work grouping that would have jeopardized the whole release.  Within 5 minutes, we’d done more to rescue our release than the 4 weeks prior.

Working on a traditional MRD is packing to go on a vacation.  You’ve made great plans, you’ve read all the brochures, and you can visualize yourself on the sparkling white sand surrounded beach chair relaxing next to your partner under gently swaying palms. 

Paradise sounds great, but the cold fact of today is that you’re late for your flight and you have to pack everything into a single suit case. 

Remember the McCallister household in Home Alone?   They were so busy packing and rushing out that they left behind sweet defenseless Macaulay Culkin.  Treating an MRD like a suitcase makes you so focused on the little details and the deadlines that you and your team will likely miss the big picture.  And once you’ve started your team may not react to market changes because they’ve already packed their mental bags:  “honey, we can’t have dinner with the President tonight because you promised that we’d play tennis.”

Another frustration I have with MRDs is that they are classically adversarial.  “Why did you pack that?  If you’re bringing that yoga matt then I’ll need a polo helmet!”  The fault is not in the people, the very nature of the document creates antagonism because the document is considered a monolithic whole.

It does not have to be like this.

Creating product direction should be more like planning a road trip than preparing for a transoceanic flight.  We know where we want to go, the essential things we need and who’s in the car: that’s enough to get started.  We’ll discuss the roadmaps as we go so we can explore the interesting sites (“geysers, cool!”) and toss out the bone headed detritus (“infrared beachcombing metal detector?”) along the way.

It takes trust and discipline to free fall into this type of planning.

When my team ranked our traditional MRD items into a 1 to N list, the conversation immediately became more focused, birds began to sing, and we each lost 5 pounds.  Several things happened when we changed the list. 

First, we looked at the deliverable as a system, not just a collection of features.   “Yeah, mayo is not much good without the bread, keep those together”

Then we started talking about what the customer needed (not what we had to deliver).  “Rob, we know you like sweet hot banana peppers but those are really optional compared to slicing the bread.”

Finally, we found it much easier to compare items against each other (“yeah, the ham feature is more important than tofu move that higher” instead of “we can’t ship this product without both ham and tofu!”)

Once we had the list ranked, it was obvious to everyone which features were required for the release.   Our discussion focused on the top priorities and engineering was able to focus on the most import items first.

Spoonful of Zietgiest

Posted on by
3

Do you want to have a winning team?  Bring a spoonful of zietgiest to your next meeting!

For me, Zietgiest is about how group dynamics influence how we feel about technology and make decisions.  It’s like meme, but I like Zeitgiest more because of its lower vowel ratio (Hirschfeld = 2:10).

Yesterday, my release team meeting had negative Zeitgiest.  Locally everyone was checking email while the remote speaker flipped through dense powerpoint slides.  It was like watching my divorced aunt’s family vacation slides via Webex.  We needed a spoonful of zietgiest!  That’s how I found myself explaining some of our challenges with the phrase “turd in the punchbowl” and getting people paying more attention to the real work.  A small positive spark and faked enthusiasm changed the momentum.  Yeah, it was fake at first and then become real zeitgiest when the other attendees picked up on the positive vibe.

The idea of seeding zietgiest is critical for everyone on teams.  It’s like the William James expression,feeling follows action: if you act happy then you’ll shake off the blues and start to feel happy.  Yes, this is 100% real.  The same applies for groups.  We can choose to ride or steer the zietgiests.

There’s no reason to endure low energy meetings when you can get out your spoon and stir things up.

Free Fall

Posted on by
2

Or elimination of pre-discussion bias

Learning Free Fall was the hardest of all the Agile comeuppance meted out to me.  Of course, it was not called free fall by the team teaching me about it.  Instead, it was the sinking feeling that I was always arguing the wrong side of every issue.  I was supposed to be the hot architect but my ideas kept getting shot down by the team.  They weren’t wrong per se, but they were not as good as the team could figure out during a discussion.

Meetings went like this:

Rob: “Hey guys, I’ve got this great idea that all of our SQL queries should leverage the zeitgeist feature because it will improve performance 25%.”

Team: “Um, yeah but zeitgeist requires us to perform green joins on the red data.”

Rob: “That’s a good point.  I thought that most of the data was yellow.”

Team: “That’s true.  What about meme queries?  They’re like zeitgeist but work for yellow and red data.”

Rob: “I really thought that zeitgeist was the way to go.  I think we can make that work if we limit the red data.”

Team: “Zeitgeist was a good suggestion, but we’ll go with meme.”

While my ideas helped the team, I could not get over the fact they did not go with my original idea.  Even worse, I would keep fighting for my idea after the team had obviously moved past it.  It slowed down decisions, made meeting more contentious, and caused our optometrist bills to skyrocket from excessive eye rolling.

All that changed when I learned how to trust my team and free fall during meetings.  Free falling (queue Tom Petty) is decoupling the problem from your idea of how it should be solved.  If you bring the problem to your team without a solution then you’ll get everyone’s brain working on ideas for the solution.  When I stopped being emotionally committed to the solution, I was much more ready to listen to other ideas.  More importantly, it was obvious to everyone else that I was more willing to listen so they were more willing to contribute and less interested in arguing.

When I started the discussion without having picked a solution, it was obvious to everyone that their ideas would be heard. 

We had more ideas, better discussion, and better results.  Generally, the team result was much better than my original idea and (bonus!) the team was always more willing to implement them after a free fall discussion.

Free fall takes some practice.  Find a buddy to help you stay on course by kicking you under the table when you’re reaching for your parachute.  Trust me – it’s like EPO for your team (and it’s legal!).