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!

1. ENSURE YOU HAVE ALL ROLES DEFINED TO MAKE THE PROJECT A SUCCESS AND ASSIGNED THOSE ROLES TO THE RIGHT TEAM MEMBERS
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.

2. AVOID CHANGES TO YOUR TEAM’S PERSONNEL
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!

3. MAINTAIN CONSISTENTCY FOR HOW YOUR TEAM ESTIMATES
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.

4. RETROSPECTIVES AFTER EACH 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.

5. WELCOME FIRST TIME FAILURES OR MISTAKES AS LEARNING OPPORTUNITIES
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.

6. PROJECT TEAM COLOCATION
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.

7. ESTABLISH A RHYTHM FOR EACH ITERATION
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. :)

8. ELIMINATE EXTERNAL TEAM DEPENDENCIES
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!

8 comments:

  1. Great post Grant! I can say from experience is having worked with you that you practice what you preach. Look forward to more Agile posts from you.

    ReplyDelete
  2. Grant, very informative. Looking forward to reading more posts!

    ReplyDelete
  3. Great post, do you think this is more something to apply to scrum or do you apply this with agile methods in general?

    ReplyDelete
  4. I tend to believe these are methods that should be followed with all Agile methods in general - especially if you have a non-distributed team. But, I'll admit that of the different Agile flavors out there, Scrum seems to be one I've more heavily leaned upon as a basis for most of my Agile practices for new teams I've worked with. As with most SDLC/project management processes though, it's really about finding the right one that will work with your particular situation.

    ReplyDelete
  5. People need to experience the "nirvana of consistent velocity" to really understand why we are crazy about it. Some might say it's just another data point. And it indeed is just another data point. But it is the one that will determine whether team members will stay in "high state" or not. ;)

    A couple of more tips from my experience.

    Make sure to celebrate the sucess very often. At the minimum, each sprint retrospective needs to include celebration. As Grant suggests, even a failure is a reason to celebrate.

    In an ideal environment, it is the company (or perhaps the entire division or department) that has adopted Agile and not just a couple of teams. It is when there is no company-wide adoption that you need to worry about keeping the team with consistent velocity together. And it is not easy to do in reality. Resources need to be managed at the top level and it can be quite frustrating to see a group of people that insist always working together. In my opinion, it might also hurt the moral of individual team member and her growth potential could be crippled.

    ReplyDelete
  6. Thanks for the additional tips Young!! Definitely agree that it's not easy to keep teams together in reality - but if management and the organization really choose to break up a stable team, at least using Agile, they can see how that decision ended up affecting the teams' velocities - for better or worse!! I hope the growth of individuals on a team can come from taking on additional responsibilities/roles with each new project the team takes on...

    ReplyDelete
  7. You make many solid points here; all of which I agree with.

    I think continuity of membership for the team is a significant point that many organizations do not consider. Even experienced practitioners need time to get acclimated to working with one another before they can reach peak performance. It may take experienced Agilists less time to move through storming -> forming -> norming, but the phases are natural and inevitable for any "new" team.

    Retrospectives are critical. A retrospective needs to be an open and honest communication session without allowing for blame or a general gripe session. Most important are lessons learned and the action items the team will use to reinforce the learning. Many team do retrospectives and even address open technical or blocking issues, but fail to address critical root causes such as poor requirements, bad estimates, or unrealistic schedules. Without addressing the root causes, those teams are resigned to repeat the failures of the past.

    Keep up the good work!

    ReplyDelete
  8. Hi Grant, Lots of good points. I am going to add allowing full self empowerment for the team, which may violate you first two points though, The roles should be able to fluctuate over time, and I think some of the most interesting things can happen when the makeup of a team changes

    ReplyDelete