Saturday, April 23, 2011

The Best Thing You Can Do For Your Team

One of the most important things I've learned over the course of my career is how important it is to ensure your teams have the information they need to succeed. In my opinion, effective team management is not about how well you direct your staff. It is much more about how effective you are in your ability to provide all relevant information and support for your team to succeed themselves.

We're lucky that so many Agile techniques aid us with this approach. Story board walls, burn up charts, build monitors, retrospectives - all aim to arm your team with information they need to self-direct towards success. However, project leaders must also embrace this concept themselves to find all information needed as well as the best way to radiate it. Different projects may also have unique definitions of success that project leaders should be careful to examine.

Good managers find a way to radiate all relevant information that your team needs to succeed. The closer this information is to real-time, the better.

Somehow, we've grown to expect that it is often management's job to fix problems. However, often the right thing to do is to simply let your team know about the problem so they can fix it themselves with management's full trust and support.

I've seen good data and metrics go to waste in a report being generated solely for upper management and stakeholders, never to be seen by the team themselves. Here are several issues that could happen as a result of this approach:
  1. Management doesn't read or ignores the report
  2. Management directs the team to start doing X, leaving the team in the dark on why they should be doing X
  3. Management implements patch fixes, which don't fix the root cause
  4. Management comes up with suboptimal solutions since they aren't the ones doing the work
Every member of your team is a professional. As professionals, they should be given real-time information that allows them to see when they are failing. As professionals, they should be given real-time information when they are succeeding. As professionals, they should be given real-time information that allows them to self-direct themselves towards success.

Tuesday, March 16, 2010

Are Velocity Goals Really a Good Thing?

So, some feedback from a colleague of mine (thanks DocOnDev!) got me thinking about whether or not establishing a velocity goal for your team is really a good thing. Seems like an honest enough goal for your team - you have a deadline and specific features to meet and you set an iterative velocity goal as such to meet said deadline and features to be delivered, being careful not to have the velocity goal exceed what your team can deliver.

But, in setting that velocity goal up for your team, are you really communicating to your team (even if you don't mean to) that ALL you care about is getting to that velocity goal? Perhaps your team is then taking short cuts or avoiding large refactoring efforts so that they can complete stories as quickly as possible, compromising quality?

Perhaps the answer to this question really lies within each member of the team you're working with. I know developers who would never compromise quality to meet a date, but then you have the opposite spectrum of developers who may hard code unit tests to always pass! DOH!

I guess the lesson here is to make sure that it's clear to your team that even though we have a velocity goal set, it's important to never compromise the quality of the code base or our own personal integrity to meet said velocity goal.

Perhaps it also depends on your specific project - maybe the most important thing for the organization you're working for IS the deadline and a velocity goal becomes an effective means of ensuring that the team meets that deadline.

What's your take on having velocity goals for your team? Is this a good or bad thing?


See comments to this posting for additional thoughts on this issue!

Tuesday, October 20, 2009

More Effective Retrospectives With The W.Ack.Hm White Board

Regular re-occurring retrospectives DURING the course of the project is a key reason why Agile helps make projects successful. Why wait until the end of a project to learn what worked well and what could have been improved when you can adjust things during the course of the project? Project "post-mortems" held only at the END of a project should be a practice that dies along with its morbid name!

But, no matter what approach I took for the retrospective, I ran into one nagging problem... people seemed to struggle to remember what happened during the last iteration. Or, if they did recall anything, it was usually much more of the negative rather than the positive. An effective retrospective should highlight and celebrate our successes as much as our failures - so it was of little help when people would only remember the failures!

So - soon after starting up my latest project, I decided to try to tackle this critical problem. How could I truly maximize the benefit that regular retrospective meetings can provide for a team if the team either couldn't remember key issues or were really more focused on getting back to work on their current stories?

Enter the W.Ack.Hm (pronounced "Whack'em!") White Board!

I simply took a portable whiteboard and drew three columns with the following names:

1. Wahoo!
2. Ack!
3. Hmm...

But, instead of filling these columns in during the retrospectives, the board was simply left out near our story board wall for the team to enter items IN REAL TIME. There was no more need to open up those cob-web covered doors to the memories of our last iteration!

If someone was having problems checking in their code since the source control server seemed to be lagging, they could simply go up to the W.Ack.Hm board and write that issue under the "Ack!" column! If someone found a way to resolve a design problem that was nagging them for the last few days, they could go up to the board and write that under the "Wahoo!" column - perhaps even showing it off to the team right then and there! If someone was reading up on a new technology that they thought could help us, they could write it in the "Hmm..." column.

Grant - why didn't you just use more generic names like "Positives," "Negatives," and "Thoughts?" Well - first of all, you can't get a creative name for the board with those three words!! And, "Wahoo! Ack! Hmm..." are much more fun and active words - hopefully inviting you to write something down under those columns. Making things fun is a subtle but very important difference in getting more participation from your team!

Okay Grant - I get it! How did it work out?

To my delight, after the first week implementing the W.Ack.Hm White Board, there were 6 items in the "Wahoo!" column, 10 items in the "Ack!" column and 3 items in the "Hmm..." column. By contrast, the last retrospective I ran with the team resulted in 1 positive and 5 negative items being listed - and no thoughts on what could be done to improve things. By using the W.Ack.Hm white board, we had more than tripled the amount of items we discussed during our retrospective!! How's that for maximizing value from your retrospective!!!

Another benefit from this approach is that there was no longer a need for a long, drawn out period collecting feedback from the team since you already have most of the items to discuss already written down. I still allocate some time for the team to enter additional items to the board - but that phase has been trimmed down to be only a few minutes at most! We're now able to finish our retrospective meetings in 30 minutes flat - and they feel like a much more efficient use of our time since we are actively discussing the items on the board for almost the entire meeting.

As with any retrospective meeting, they key to making them work for you is to collect that information and create action items that are worked on as soon as your team has the ability to do so. Thus, I ensure that the contents and discussions around the W.Ack.Hm board are collected and stored within a WIKI page that I've setup for our retrospectives. I also proceed to enter action items to resolve any issues into our issue tracking system where we can then proceed prioritize and deliver on those issues, adding direct value to the project.

I can honestly say that some of the most critical risks to the project have been mitigated by items and discussions brought up during our retrospectives. To my surprise as well, we've also been able to implement most of our "Hmm..." suggestions as well! Results will vary based on your team and project schedule - but if you aren't actively working on issues resulting from your retrospectives, why even have them if they aren't going to provide any value?

If you've gotten this far into reading the post, I can only hope that you are thinking about instituting this for your team as well... may it help your team out as much as it has helped ours!