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!
Posts
