Transitional Velocity and your Agile Rollout
You’re going agile and you couldn’t be more excited. You’ve read about all of the benefits and want that for your organization, and you want it now. Slow it down a little bit Buddy; realize that not only will Agile development change the way you work, it will possibly require organizational and cultural changes. Your organization only has a certain amount of change it can consume successfully in any given period – you only have so much transitional velocity.
One of my partners in crime at VersionOne, Mike DePaoli, has started a series of posts regarding using Agile to scale Agile. I couldn’t agree more with the thread and chatted with Mike briefly about adding a topic I spoke about at Agilepalooza – the idea of transitional velocity. We know what velocity is in terms of agile – the rate at which a team is delivering value, usually measured in average points per sprint or iteration. Transitional velocity is how much change we can successfully introduce and make sustainable in a given timeframe.
When rolling out agile practices we simply cannot change everything right off the bat. I have seen this a few times when agile comes as a top-down movement or when it comes from over-excited developers. Introducing large amounts of change all at once won’t stick and will just end up confusing people. Instead, we need to consider our transitional velocity – how much change we can successfully introduce and make sustainable in a given timeframe. Just like planning a product, we need to roll out changes using knowledge of our transitional velocity.
How would you start doing this?
- Understand the challenges facing delivery at your organization
- Understand and embrace the strengths in delivery at your organization
- Look at practices that can enhance these strengths or help with these challenges
- Create ‘acceptance criteria’ for when you would feel that these practices have been accepted. Once these acceptance criteria have happened, you will feel like this challenge has been addressed / strength has been enhanced and is stable
- Using your knowledge of your organization, sort out the changes in order of amount of change this will create to your team. Similar to story-estimating, give these some sense of relative sizing. Note any dependencies as well
- Pick a subset of these changes that you think your team can handle in a timeframe (NOTE: Change is hard, I wouldn’t recommend a 2 week timeframe for this, something larger along the size of a few months)
- After your timeframe, look at the changes and calculate your transitional velocity by simply sizing the ‘change estimates’ you assigned to these practices
- Rinse, wash, repeat
How about an example:
Say I am at an organization and I have concerns about our software delivery. Our strengths lie in deep domain knowledge across our teams and highly skilled developers and testers. Our challenges include high defect rates and large piles of documentation and change requests. Looking at this and reading about agile software development, I (somewhat arbitrarily) decide that our teams need to be co-located, we need automated testing, continuous integration, pair programming, TDD, short sprints along with sprint planning, requirements as stories, and daily standups.
Being responsible, I look at how much change each of these practices would bring to our organization. TDD gets a higher estimate because our teams are still struggling with unit test consistency. Pair programming also gets a higher estimate because it would require physical changes to the work environment. Short sprints and sprint planning seem like a nice, easy way to start getting some change in place, as they will get our groups talking. I decide to focus on those, along with daily standups to start building trust and common voice among the team, before I try anything else.
I define acceptance criteria for these changes (acceptance criteria being when I feel the change has taken hold) – short sprints are working when a team is comfortable with their defined sprint, it is less than 4 weeks, and there is minimal work not being completed in a sprint. Sprint planning is accepted when a quick check with team members respond that they don’t want sprint planning removed. Daily standups have been accepted when teams are having quality meetings in less than 20 minutes and blocking items have been identified and removed by teams. I give each of these changes an estimate of 3 compared to a 13 for pair programming, and the rest fall in between. After 3 months, I check back and see if these changes are sustainable. If so, I know that I could introduce about 9 changes in the next few months. Pair programming seems too large to introduce all at once, so I would have to look at how I could get to the same end goal through multiple steps.
I continue efforts to improve the organization, always basing my amount of change against my measured transitional velocity. You will have some overachieving teams, and they can ‘pull’ practices to try from the transitional backlog or create their own. Transitional velocity targets organizational rollouts.
Use transitional velocity along with using an agile or Scrum tool to visualize your transformation holistically. I like storymapping a transition as it helps provide a long term view and binds it to ‘why’. Just as agile won’t guarantee a successful project, this approach won’t guarantee you a successful transition. It will only raise your chance of success.
Read more by Joel Tosi @ http://communalosmosis.com