Should You Measure Teams or Individuals?

March 29, 2011

How do you measure performance? Should you be measuring performance at the team level or the individual level?

The use of autonomous teams in Agile development leads many to conclude that team is the only concern. The case being made is this: If you focus on individual goals and individual incentives, you will cause individuals to operate in ways that are counter to the collaborative teamwork that you seek.

Likewise, there are times when individuals resent having their performance strictly assessed at the team level. Sometimes people are assigned to teams late in the game, or are temporarily taken off the team to deal with a critical issue that limited their involvement with the team. Fair enough.

Resentment can surface in another way, as pointed out by Morten Hansen in his book, Collaboration: How Leaders Avoid the Traps, Create Unity, and Reap Big Results: “People working in teams can shirk and get by because individual output is not being measured, only team output.”

Morten notes that when people can hide, they often do. It’s called social loafing. People on the teams, however, know how much everyone is contributing, which is where the resentment comes into play. (The daily standup with crisp answers to the 3 questions combined with the collaborative nature of Agile teams definitely helps to address this issue.)

Our First FedEx Day: Results!

March 26, 2011

We had quite a first day… and a long one at that!

We began and ended on time, starting at 3:00 PM on Thursday and going until 3:00 PM on Friday. During the week, everyone began to get clearer about what they really wanted to work on, and the initial potential shipping orders were updated to be actual shipping orders and moved into the shipping orders folder on our SharePoint server.

We had dinner brought in on Thursday night, and you could feel the level of excitement and fun in the air as people grouped together in different locations and talked. People were definitely passionate about what they were working on, and everyone was clearly motivated to pitch in and help their team. We even had a few one-person projects under way.

Innovation and Fun: Our Own FedEx Day

March 21, 2011

Dan Pink’s book Drive inspired us to try our own FedEx day using Atlassian’s model. We’ve already held a couple of brainstorming meetings to generate ideas, and we’re fast approaching our FedEx day that runs from this Thursday afternoon to Friday afternoon. This will culminate in the awarding of a trophy designed by Joe Sanderson, complete with a miniature FedEx truck on top along with a lighthouse and moose to reflect our Maine locale.

As expected, we have a number of ideas to work on that have been tossed around as concepts from time to time in the past, but never pursued. And there are some excellent variations and innovative twists to those ideas as well. It’s great to see our organization dedicating this sliver of time to go after some of these ideas! In fact, it’s looking like we are going to have a surplus that will have to wait until our next FedEx day.

Coaching Agile Teams and Moving to the Next Level

March 18, 2011

I had the pleasure of spending the first two days of this week in a Coaching Agile Teams course taught by Lyssa Adkins and Michael Spayd. The teaching was actually very interactive. There was absolutely no chance of nodding off, believe me! Lyssa and Michael provided just enough information to guide us; but a subtle reality is that they coached us into self-discovery, and I came away my own personal learning. I’m sure it was the same for others.

And when I say subtle, I mean it. During the week I’ve had a chance to reflect more about the course, and I didn’t feel as impacted right after it was over as I did two days later. I’m feeling like I need to make a more profound shift in my style, but this has been more of a gradual realization than a sudden, transformational shift.

Book Review: Clean Code

March 15, 2011

Clean Code: A Handbook of Agile Software CraftsmanshipIf you want a great book that clearly examines the how’s and why’s of software craftsmanship, I strongly recommend Bob Martin’s Clean Code. Bob provides an excellent, guided tour of software craftsmanship from soup to nuts.

Bob asks, “Have you ever waded through a mess so grave that it took weeks to do what should have taken hours?” He follows up with nothing that with problem software, “Every change they make to the code breaks two or three other parts of the code. No change is trivial.”

He doesn’t pull any punches in his response: “The fault is ours. Not the requirements, not the schedule, not the stupid managers and useless marketing types.”

Don’t Measure. Diagnose!

March 11, 2011

I’m growing less found of the term metric. Particularly in how it is typically applied: as a measurement that leads to a judgment. And while some judgments are certainly a good thing – like recognizing improvements and/or excellence – there needs to something more to the equation than management simply measuring and judging.

Software projects always face a number of challenges, and management should be playing a supporting role with autonomous teams to help them reach their goals. There are ways the managers can do this, but measuring and judging alone won’t create a “partnership effect.”

Redefining Management

March 8, 2011

“Getting things done through others” is a common, one-line definition of management. While it accurately reflects the fact that there is separation between those who perform the work and those who don’t, this definition needs to change.

A major reason for this is historical. 20th century management techniques involved rigidly defining, organizing, and controlling the work. Work where the actual steps that produce output are very specific, concrete, and not subject change. Where the design of the work can be performed once and applied repeatedly; like the manufacturing processes where decisions flowed down from a hierarchy and the assumption was that those at the top knew more about the nature and needs of efficient, productive work than those executing the work.

Don’t Squander Your Opportunities at the Daily Standup!

March 4, 2011

The daily standup Is NOT a daily status meeting.

It is an opportunity…
  • To identify where knowledge and experience can be shared.
  • To identify impediments.
  • For each team member to make a commitment.
  • For the team to monitor its progress as a whole.

There’s Only One Reason for Defining Agile Development…

March 1, 2011

And that is to get people talking about what it means to be Agile.

Attempts at succinctly defining Agile development – including my own – have proven difficult. In an effort to be accurate and complete, some definitions end up incorporating a lot of concepts, like the principles and values of Agile development along with the mechanics of Agile execution. As a result, the definition becomes very descriptive and wordy.

Other definitions are so short that they are vague and incomplete. What good is a definition if it doesn’t provide clarity about what is being defined in the first place?