Livestock Improvement Goes Agile

[article]

Putting the Practices to Work
Prior to beginning training, we reorganized the workspace. Instead of sitting in silo-functional groups, teams now set up in two areas. Each team is a cross-functional group consisting of business analysts, developers, testers, and product managers who represent the customer voice.

The group agreed on a different way of working and this saw the role of the product manager heavily involved in product development. Incorporation of product managers into the agile teams is significant, as they previously were part of a different group working under the marketing department. Co-located with the team, they can answer questions and provide close-to-immediate feedback. The product managers spend about half of their time with the teams and the other half in the field where they work on understanding customers’ needs and training roadshows, which is  when the product manager goes out into the community and trains our customers on the products.

Each team has an iteration manager who provides leadership and guidance, facilitates workshops, tracks progress, and leads the daily standup. The iteration manager is responsible for removing obstacles, like a lack of availability of subject matter experts, and providing resources such as  new hardware, software, or other tools that  assist in development)to help the teams be successful.

Our teams typically work in two-week iterations. They don’t begin and end on Fridays or Mondays, because it’s more likely that someone will be away from the office during these days. One team starts on Tuesday, two teams start on Wednesday, and one team starts on Thursdays. Since the teams are independent, it’s fine that the teams start their iterations on different days.

One problem that teams identified fairly early was that they are required to provide support for the existing products while working on new projects. Teams use story cards to track work through the iterations, and velocity charts in the team spaces show progress. The mix of support for existing and new projects resulted in their being unable to meet their planned velocity during an iteration. But, this support work won’t go away.

Storywall

Figure 2: Team Awesome’s Storywall

So, the team reorganized the story wall into project work and support work, with a horizontal line dividing the two sections. Once the team receives support tasks, they add them to the backlog and prioritize them along with project work during the next iteration planning meeting. There is no maintenance team, as our products have been developed in many different technologies and languages, and it’s unrealistic to expect a small team to have this diversity of skill sets.

The velocity estimates now take into account the average time spent on “below-the-line” work and are back on track in relation to actual velocity delivered. Because the story wall shows all the work that is not project related, the business customers understand why the delivery rate has slowed down. This simple change reduced tension and increased communication both within and outside of the teams.

The developers are incrementally moving towards continuous integration by building more unit tests and integrating their code at multiple time during the day. They use test-driven development for new work and some pair-programming. They have not quite reached the point of continuous build, but their understanding of the tools and techniques improves with experience.

Testing is integrated into the iteration process through identifying tests during story elaboration. This includes using behavior-driven development structures to present detailed requirements in the form of customer tests. Currently, most testing is manual, but we are building more and more automated tests.

About the author

Jenny Saunders's picture Jenny Saunders

Jenny Saunders has worked in the IT industry for a variety of organizations and varying disciplines over the last twenty-three years. Eighteen of those years have been in the UK working for the banking sector, automation industry, electronics retail industry and the Metropolitan Police. For the last five years she has been based in Hamilton, New Zealand working for Livestock Improvement Corporation; managing the Farm Systems Software Development Group, who are responsible for delivering, maintaining and supporting their customer facing software technology products.

About the author

Shane Hastie's picture Shane Hastie

Shane Hastie (@shanehastie) is the Chief Knowledge Engineer and Agile Practice Lead for Software Education (www.softed.com) a training and consulting company working in New Zealand & Australia. Since first using XP in 2000 Shane's been passionate about helping organisations and teams adopt Agile practices. Shane is a key member of Software Education's Agile Practice, offering training, consulting, mentoring and support for organisations and teams working to improve their project outcomes. In August 2011 he was elected to the board of the Agile Alliance (www.agilealliance.org).  Shane is a news editor for InfoQ (http://www.infoq.com/author/Shane-Hastie) and he blogs on the Software Education Trainers Blog (http://blog.softed.com/)

 

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03