This post is from the Collabnet VersionOne blog and has not been updated since the original publish date.
Bouncing Agile: How Google Analytics is Related to Agile Success
It was a normal day. I was reading articles, blogs, emails, Tweets, stories and a host of other types of information. While perusing an item, there was an interesting link and I clicked into another Web location. When I arrived, the newly presented topic was not what I expected so I navigated away from the site. Little did I know, this interaction was most likely recorded by Google Analytics as a “Bounce.” Google states that, “Analytics helps you analyze visitor traffic and paint a complete picture of your audience and their needs.” Things like Page Views, Average Time on a Page, Entrances and Exits are tracked for behavior. However, the most interesting metric could be the Bounce Rate. “The Bounce Rate is the percentage of single/page sessions (i.e., sessions in which the person left your site from the entrance page without interacting with the page).” In other words, they were attracted to a specific page and when they arrived, they left the site without interaction. The lower the “Bounce Rate,” the longer they interacted with the page and the site. According to Google, “If you could only choose one metric to look at, Bounce Rate might be your best choice.” So how does this relate to agile development and agile success? Similar to a Web page or site interaction, a team with a high “Bounce” rate will not be as productive as one that is stable and has stayed together through more than just a short introduction. When people are added or removed on a regular basis, there is not time to understand the full scope of work or the people involved in it. Medinilla states, “The principle of assigning projects to teams assumes that some team stability is needed. If you are changing team composition every 2 weeks, you are essentially managing a resource pool in disguise. On the other hand, if you are using agile development’s definition of a ‘team, ‘which is more than a group of people commissioned to do the same job, you’ll need some time for the team to ‘glue’ or, as some experts call it, ‘gel together.’” (Medinilla, 2012) It is this unnecessary change, or “Bouncing” that causes confusion, demotivation and poor results in the area of agile success. There are many benefits to making an agile team stable, one of which is learning. Alistair Cockburn (2006) asserts, “Novices don’t stay novices forever. People who are novices on one project become experienced by the end of the same project… This ability to learn along the way helps many projects. Within a single project’s timeframe, the people learn new technology, new problem domain, new process, and how to work with new colleagues. Often an agile team struggles through the first 2 increments, becoming stronger and stronger until successful results at the end are almost a given.” Bouncing from team to team and project to project doesn’t allow enough time to learn technologies, domain knowledge, processes and characteristics of people. To help track the Bounce Rate of your agile team, Ekas & Will (2013) have recommended a metric: “Validate that you have a whole team; track the team membership each iteration, beginning with the first iteration; and review it regularly. Confirm that the whole team starts together and finishes together… if the goal is to have stable, dedicated agile teams, then having an indicator immediately available to confirm that this happens can be a big incentive.“ For example: A team of 5 people starts Iteration 1 with a whole team and completes it with the same 5 people so the Team Bounce Rate is 0%. Iteration 2 starts with 5 but ends with 4 so the Team Bounce Rate is 20% and the Team Bounce Rate trend after 2 iterations is 10%. Compare this trend to velocity or throughput after each cycle for evidence of them being connected. Success with agile development can be measured as a form of bouncing. Both people and process can be affected by it. Just as when a reader will try a certain link and bounce back out before truly understanding the main points of the page, so time is a factor in allowing teams to come together properly. Give your teams a chance to gel. Give them a chance to learn. Give them a chance to be successful and maybe the bounce rate will turn into a jump for joy. References Cockburn, A. (2006). Agile Software Development: The Cooperative Game. Upper Boston, MA: Pearson Education. Ekas, L., & Will, S. (2013). Being Agile: Eleven Breakthrough Techniques to Keep You from “Waterfalling Backward”. Upper Saddle River, NJ: IBM Press. Medinilla, A. (2012). Agile Management: Leadership in an Agile Environment. Heidelberg, Germany: Springer Science & Business Media.