Continued Agile Evolution in Product Development

One of the great opportunities that came with our recent investment from OpenView Ventures, is the support that OpenView provides to their portfolio companies.   A couple of weeks ago we were privileged to have Jeff Sutherland (his website) spend a couple of days in our office looking at our Agile processes for improvement opportunities.

Jeff is credited with inventing the Agile software development framework known as Scrum. Scrum is not a complex acronym like many terms in software but actually comes from a Rugby formation that requires team self organization due to the chaotic nature of play.  Balihoo has employed Agile techniques for almost 3 years based on the Scrum framework.  Agile and Scrum are centered on simple concepts but as any designer will tell you simplicity is not always easy.  As a team we went through dozens of iterations to refine, improve or even change based on current internal or external conditions. 

However when you are making changes sub-optimal habits can sometimes creep in, creating derivations that add potentially needless complexity.  For example, a couple of months ago I walked readers on this blog through our sprint capacity and estimation process.  Yes it worked very well, however it wasn’t exactly simple. Having Jeff in the office offered us an opportunity to ground ourselves and do some resetting to reducing some of our current process pain points, increase throughput, decreasing team stress and simply to re-energize the team.

Some our our identified impediments:

• We had increasing levels of churn and change during out sprints due to quality issues and high priority small business needs, which created disruption to the current sprint in terms of planned work and team focus
• Estimation in ideal days was becoming further and further from actual duration, and did not offer us an effective way of measuring increases in team velocity even though it was obvious that the team was getting more efficient
• Slippage in the definition of ‘done’ allowing story points to burn down based on completion of development and not based on well defined and testable AT’s (acceptance tests)
• Increasing number of stakeholders with product requests, often pre-scheduled into upcoming sprints making it difficult to have one single source of truth on business priorities

Here are some of the changes we have made in the past 2 weeks:

• Implemented software (Jira + Greenhopper) to help manage our product pipeline, execution and release process and create one single source of the truth (note:  this process of reviewing software options actually started about a month earlier, and just happened to coincide nicely with the other changes)
• Reduced our sprint cycle from 4 weeks to 2 weeks to address the uncertainty in our business
• Switched to story points over ideal days with ‘reference stories’ to better measure team velocity.  We are using story points for both rough estimates as well as planning estimates and not converting to hours/days once a sprint is underway.  Points are burned down only once the story is tested.
• Formally creating point buckets within a sprint:  60% to new work, 20% for refinement, and 20% for unanticipated changes.  The unanticipated changes bucket is like a token system for the company giving some level of flexibility while maintaining order.  If the tokens are not used the team will pull from the backlog to finish up the sprint.
• Creation of a team impediments list to focus on bigger items that could be acted upon to improve our process and increase team velocity
• Refocus on scrum fundamentals in the planning, estimation and sprint review

As of today we are a couple days from finishing our first two week sprint since doing a reset after Jeff’s visit and things are looking great out of the gates.  The team is excited, and the organization is experiencing greater transparency into current priorities than in our company history.   (Once we have a few sprints under our belt I will present some statistics on the results)

If you have ever worked in a large company with their complicated software development methodologies its easy to see how bloat can creep into the process over time.  Refocusing on simplicity is sometimes difficult but worth the effort in the end.

Also of interest:  A few months back I discussed our use of Agile concepts across the company.  We are now moving on to phase two of this process so stay tuned.