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?

  1. Understand the challenges facing delivery at your organization
  2. Understand and embrace the strengths in delivery at your  organization
  3. Look at practices that can enhance these strengths or help with  these challenges
  4. 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
  5. 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
  6. 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)
  7. After your timeframe, look at the changes and calculate your  transitional velocity by simply sizing the ‘change estimates’ you  assigned to these practices
  8. 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

This entry was posted in Agile Development, Agile Software, Scrum Development, Test Driven Development. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>