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!

Sunday, August 2, 2009

When Agile Evangelism Goes Wrong

After having been an Agile convert from the more traditional waterfall methodologies, I found myself promoting Agile heavily with the company I was working for back around the year 2004. We had successfully implemented our own custom Agile process within our division and had seen great benefits from it. But, there were two other divisions within the company that were still following more traditional, waterfall processes. While I was not in a position to make changes at the other divisions, I knew that the other divisions didn't like the existing SDLC and morale across those divisions were at an all time low. Seemed like the perfect opportunity to move the entire organization to Agile!

So, I thus began my quest to evangelize Agile as the next coolest thing to recursion. I was ready to promote Agile and convince people that it would help them and the overall business. "This should be easy!", I thought to myself. After all, I knew everyone was looking for something better! I proceeded to document our Agile process we had setup within our division and began sharing the document with other product and software managers across divisions. I even distributed copies of it during a product and technology summit. I made it a point to keep talking to other managers about Agile and what it could bring for them. It wasn't long before I was labelled the "Agile Nut" around the office. While I didn't mind the label, what I came to realize is that my approach to instill a grass roots effort to transform the entire organization had failed miserably - instead of convincing my colleagues that Agile could really help the organization, it occurred to me that I may have turned them OFF to Agile instead.

What went wrong? Why couldn't they see the light even when they were all looking for change? It occurred to me that I must have been so excited about Agile being a great way to help transform the organization that people began to see me as more of a crazy, cult-follower of Agile processes rather than someone "sane" that could help introduce the change at the broader level. Yes - I didn't have support from the C level managers nor the managers in the other divisions. While I was able to convince a few of them that Agile would indeed help the organization, it took lots of discussions and in the end, the idea of an Agile organization was abandoned.

Did you catch the key word I used that was the problem? I had to convince my colleagues that Agile would help them. When they were skeptical about the Agile processes I was talking about, I should have forwarded them book and web resources for them to learn about Agile themselves instead of trying teach them myself. It always seemed like a battle talking with my colleagues - constantly proving to them that Agile methodologies would work for them. If they weren't responsive to what Agile had to offer, I should have let it go and ensured that there were resources available for them to learn about Agile themselves. With all the convincing I was doing, I had instead dug a hole for myself in my efforts to convert the organization. After all, any movement toward Agile would have just proved that I was "right" and my colleagues were "wrong" now.

You shouldn't tell someone the same advice more than twice - if they aren't receptive to your suggestions, then it's up to them to learn for themselves. Providing a framework for letting people learn from their own mistakes and giving them the opportunity to learn for themselves is part of what Agile processes is about - and I should have known better to let the management team at the organization realize for themselves what Agile could bring to the organization.

The organization eventually DID decide to make BIG changes to their development strategy by centralizing their development teams across all divisions. With the newly consolidated development division now in place, the Agile strides we had made within our own division had begun to crumble.

Not all was lost though - our division was eventually sold off to another company and I was able to revive our Agile processes for the most part. But, my experiences with the failed Agile transformation was perhaps one of the best lessons in my career in what I needed to do to help make future Agile transformations - or ANY broad organizational change - a success.

Wednesday, July 1, 2009

Efficiency - A Must Have Agile Metric As Important As Velocity

When I first picked up Agile development, I absolutely got hooked on the simple yet powerful way it described how to track your team's progress on projects with REAL data. Before I implemented Agile, I can't remember how many times business stakeholders or execs have tried the Developer-Used-for-My-Benefit approach, only for it to bite the organization hard in the nuts later. I call it the D-U-M-B approach for short.

CEO: "How's the project coming along Pat?"
Pat the Developer: "Uhhh - going well. I can crank this out in no time - easy!"
CEO: "Excellent - I'm going to give you a huge bonus and tell sales and marketing to start pushing it."

Uh-oh... I think we all know the end of this all too well-known scenario... :(

Gathering actual hard data while your project is running is the only practical way to measure the completion of your project - and Agile processes are all about collecting and charting this hard data, making it visible to the entire organization so there is never any question where a project status is at!

One of the core hard data metrics within Agile practices is the team's velocity - the amount of work the team is able to complete in a given amount of time/iteration. Using the team's last velocity, the team can predict what their velocity will be for the next iteration. Charting the team's velocity for the project will allow you to make some smart data-based decisions as well by analyzing their velocity trends. For tips on providing your Agile team the best chance on achieving a high, stable velocity, read this later!

However, even with all the great info velocity charts provide, I found myself wanting something more than just the velocity chart. If resource days are limited in an iteration due to holidays, vacations, or sick days, the team's velocity can drop significantly. It makes complete sense of course - fewer working days = reduced work completed for that iteration. But, how could I prove that the dip in velocity was just due to the limited number of resource days? How could I prove that the team worked just as hard as they would have if they were fully staffed for the entire iteration?

Enter the efficiency metric. The efficiency metric allows you to determine how efficient the team was for each iteration, but in a way that it factors out the number of resource days that were available during that iteration. Thus, even if there was an iteration when the entire team took a few days off, where the Velocity Chart would show an obvious dip in the amount of work accomplished, you can rely on the efficiency chart to show if they were just as efficient working that iteration from the previous ones. Below is an example Team Velocity and Efficiency chart based on data collected for the same iterations.

You can see that even though the team's velocity dropped signficantly during iteration 14 because half of the team was out due to the flu for a few days, the efficiency chart shows that the team remained consistent in its effort to get work completed - which tells you that during that iteration, a dip in velocity was entirely due to the lack of resources that were available that iteration.

COOL BEANS GRANT - I GOT IT!! So how do you calculate a team's efficiency?

E = V/R

E=Efficiency for the iteration
V=Velocity for the iteration
R=Total number of person days worked on the team for the Iteration

Hopefully, you're already tracking velocity (V) for completed iterations. You'll also need to start tracking total actual person days (R) worked for your completed iterations as well. For example, if you have a team of 5 and your iteration is 10 days, then the maximum possible R value for your team would be 5 x 10 = 50 days. The actual R value would thus be the maximum possible R value for your team minus the number of absent days per team member during the iteration (e.g. 50 max - 1 sick day = 49). Tip: Plug all of your numbers in a spreadsheet and setup formulas to do your calculations for you! Efficiency is auto-calculated for me once I've entered velocity and resource days for the completed iteration into my spreadsheet. After you've got your efficiency calculated, producing your Efficiency Chart is as simple as producing your Velocity Chart - just chart it over each iteration!

Below is an example spreadsheet showing calculation of Efficiency using Velocity and number of resource days.

Now that you have your efficiency chart at hand, viewing it in combination with your velocity chart unveils much more information about your iterations than the velocity chart would have provided alone. See a dip in your velocity chart but efficiency was stable? Resource days must have been limited that iteration. Like velocity, the trend for the efficiency chart for teams heading in the right direction should be very similar to that of the velocity chart: new teams will likely have a few beginning iterations where efficiency may be erratic when they start settling into the project and learning to work together. But, eventually, you should see a peak and plateau, representing that the team's current maximum efficiency has been achieved. Note that efficiency ratings are not the same between different teams - so don't get all twisted up if one team seems to have a smaller efficiency than another! To me, a successful efficiency chart is not about how high it reaches, but about if it has reached a peak and consistent plateau.

Having efficiency also allows you to obtain what I'm calling the benchmark velocity for your next iteration. If you're using velocity charts right now, I'm sure you've been told that the best way to determine how much work the team can do in the next iteration is the velocity from the last iteration. I beg to differ!! With the efficiency metric of the last iteration in hand, simply multiply it with the expected number of resource days for the next iteration, and you've got the benchmark velocity - the velocity your team would hit if they work just as efficiently as they did this past iteration.

v = E*r

v = benchmark velocity for next iteration
E = efficiency from just completed iteration
r = Total number of expected resource days available for upcoming Iteration

Below is a spreadsheet showing the simple formula to calculate the benchmark velocity.

Grant - why do you call v the "benchmark" velocity instead of the "expected" velocity? After all, isn't that what it really is? When the team needs to decide what their upcoming velocity commitment should be, there are more things to consider than just the pure numbers from the previous iteration. For example, maybe your office is scheduled to move to another building next week. Even though everyone is still working those days, you shouldn't expect them to be just as efficient as they were last iteration!! Thus, you and the team should expect to have a lower velocity for the upcoming iteration than what the "benchmark" velocity is calculated to be... hence the term "benchmark" instead of "expected." Saves you the trouble in also explaining to project stakeholders, customers, and execs on why the "expected" velocity wasn't reached as well if you had called it that!

Allowing your team to view the benchmark velocity and then talk through any outside factors that could impact the upcoming velocity for better or worse should allow the team to settle upon a velocity number that they can commit to. A fully self-organized, steady team should more often than not accept the calculated team benchmark velocity as their commitment. If your team is consistently committing to numbers that are drastically different from the calculated benchmark, it's a clear signal that they are still learning how to stabilize their development efforts for the project. Don't be surprised if the team decides to commit to a velocity that is higher than the benchmark as well!

The efficiency metric is now a must have for all of my Agile run projects - it's my hope that your team and organization will also benefit from using this metric as well!

Monday, June 29, 2009

8 Tips for New Agile Teams to Achieve a High, Stable Velocity

One of the most common Agile project management techniques to measure the continuing growth and success of your team is the beloved Velocity Chart, which simply shows the amount of work your team has completed after each of your iterations.
If the team you are working with is new and knows nothing about Agile, you should expect an erratic first few iterations where velocity can greatly differ as your team learns the process and gets accustomed to working with each other. Over time, teams headed in the right direction will increase their velocity and hit a peak and plateau, a key milestone that unfortunately not enough Agile software development teams are getting to in my opinion. When the team has achieved this state, they have settled into a rhythm and maxed out on the amount of work they can accomplish. This is not to say that there aren’t any steps that can improve the team’s velocity beyond this plateau, but this is a subject best suited for a future discussion.

So what's the big deal in getting a team to reach their velocity peak and maintaining a plateau? Well, for one thing, team morale is often extremely high when teams have established this state; it signifies that they work well together and are able to get the work they need to complete at a sustainable pace. The business also benefits by having a team that is dependable and consistent in the amount of work they are able to deliver – a project manager’s wet dream (yuck!). Seriously though - a highly and consistently performing team makes project forecasting and planning much more accurate and allows the business execs, stakeholders, and clients to know with much better confidence WHEN the team can complete a project with proper estimates in place. For example, if I had a choice between two teams to work with - one which was showing a consistent plateaued velocity and another that shows velocities above what the first team could do, but had erratic changes in team velocity, I would much rather work with the team that had reached a plateaud state. An erratic velocity iteration over iteration means that the team hasn't fully worked out their kinks and thus is a riskier team to work with.
Below are some tips I've learend over the years practicing Agile software development on what you/your team can do to promote the evolution of an Agile team towards achieving their own velocity chart plateau!

In order for a team to be successful, they need to have all the appropriate roles and skills within the team to keep progress moving within the project without having to wait for resources outside of the team. In my opinion, a minimum self-organized team needs to have a project manager, a product manager, a developer, and a QA person. If possible, it’s always great to include the customer/client as well on the team – but I realize that may not always be possible!! Of course, each project may differ in the roles and team members that may be necessary to ensure your project remains successful. For example, if your project requires several new complex databases and servers to be spun up, it would probably be a good idea to have an IT staff member assigned an official project role as well.

One of the worst things you can do to prevent a team from reaching their plateau is to move personnel into and out of the team. That’s why it’s so critical to establish the right roles and team members at the onset of the project so that they can grow into the roles that have been defined. But ultimately, realize that any change in personnel means your team must re-learn how to work effectively with each other and often re-establish their own roles. If you’ve already got a team that has plateaued, do yourself a favor and make sure they STAY together as a team – it’s difficult to get a team to that state – so why would you willingly break that team up after the project is over? Have them tackle the next project together!

How much work your team accomplishes each iteration is defined by the estimates/point values the team (and only that team!) gives to stories that they work on. If they suddenly change the way they estimate stories mid way through a project, it will completely throw off the validity of your velocity chart!! This is not to say that each team member should continue to strive to make their estimates and point values as accurate as possible – but just remind them that each of them should maintain consistency in the way they estimate from iteration to iteration.

It’s vital that your team always evaluate themselves after each iteration and talk about things that went well and things that didn’t. Doing this is an important step that allows your team to grow together; it also sends them a message that ultimately, they have direct responsibility over their own work and team environment and DO have an active say on how THEY can improve their day to day work. Re-enforce the message that improvements points are the entire team’s responsibility to resolve – there is no such thing as individual failures on Agile teams (usually!). This will help set the tone that finger pointing and name games are not to be tolerated on the team and that if one person has a problem, it’s the team’s responsibility to correct that problem. Resolving issues and re-enforcing good behavior together as a team will promote self-organization and ultimately lead to improved velocity over time.

If you’ve got a new team, failures and mistakes are to be expected – it’s part of their learning process in finding a way to work better with each other. Sure, reading up on Agile processes and information like this one can help avoid costly rookie mistakes! But ultimately, mistakes are bound to happen even to the most senior of Agile teams. Instead of reprimanding the team or individual(s) that made those mistakes, establish a culture that virtually celebrates failures/mistakes as learning opportunities for the entire team. The second ANY team member doesn't feel comfortable talking about their own mistakes or failures only jeopardizes the team's growth potential.

THERE IS NO SPOON... err... WALL!!! Have your ENTIRE team sit next to each other in an open , non-partitioned environment that allows them to interact with each other on a daily basis FACE TO FACE! Yes - I DO mean everyone - most importantly your customer-proxy!! This will actively promote the growth of this team and ensure that they learn how to work with each other on a day to day basis. Okay - maybe your developer is getting cranky and says they can't concentrate enough when they need to in such an open environment. Just establish some sort of signal that says they want time to themselves and shouldn’t be interrupted unless absolutely necessary. We used over-the-ear headphones (noise cancelling also helps) as a way to tell others to back off – I’m concentrating!! If we had non-urgent questions for that team member, we would just ask them later or send them an email and have them answer it on their own time. Alternatively, if your office has extra rooms, make one room a “quiet lab” where they can work in peace, doors closed, but ONLY when necessary.

Make sure any re-occurring meetings that happen for your team happen on the same schedule based off each of your iterations. That way, your team can establish a rhythm with each iteration and can get accustomed to having “Retrospective Fridays” or “Monday Iteration Planning” meetings. Do your best to avoid having your team’s resources participate in any meeting outside of the already established, re-occurring meetings you have laid out for them so they can maximize the amount of time they work on the project and don’t get distracted with non-project related meetings.
There are of course many other things that I've probably missed here - but hopefully these tips will at least give you some guidance or thoughts on areas that you may not have considered otherwise - at least consciously. :)

While not always possible, eliminating external team dependencies and EMPOWERING your team to control their own destiny will avoid situations where your team will be negatively impacted by factors outside of their control.  It could be anything from ensuring that your team has access to development and QA environments running the project to more business focused dependencies like ensuring that there is an appropriate client/client-proxy that is readily available to make product/business decisions for your team.  Look out for external dependencies during your retrospectives and move them INTO your team when possible!