Livestock Improvement Corporation (LIC) is one of the largest integrated herd-improvement organizations in the world. Since 1909, this dairy-farmer-owned cooperative based in Hamilton, New Zealand, has provided services to dairy farmers, including testing and milk analysis, artificial breeding, animal health, farm advisory, herd recording, DNA analysis, farm automation, and farm-mapping systems. Its core purpose is to help farmers become more efficient and profitable by genetically improving their animals and by providing information systems and technology that make it easier to farm.

This is our story of how LIC transitioned from a successful, traditional development process to one with hyper-productive agile teams that produce software faster, better, and cheaper. This story is built from the real-life experience of team members, business sponsors, and product managers; it contains the ups and downs, the theory versus the practical, all accomplished in a commercial environment where the teams had to keep delivering.

The Beginning of the Journey
Initially, all software development at LIC was under the IT department, which catered to the IT needs of all business streams within LIC. In 2007, the executive team decided that enforcing the same principles, processes, methodologies, and technology roadmaps across these diverse business streams did not enable the most efficient, effective, and sustainable delivery framework. The product business owners could not get resources dedicated to their development. There was constant task switching and, hence ,time lines slipped and costs increased; this caused great problems for the business owners as they could not guarantee when their products would be ready for deployment. Additionally, we used to deliver good products but with very little “real business” engagement and buy-in.  Therefore, LIC split development into two departments—IT and the farm systems team. They appointed Jenny (co-author of this article) as head of the farm systems team, which focused on all customer-facing software products. (IT managed the remainder.) Farm systems initially adopted the same principles, practices, and standards as IT, but this did not work within the world of customer-driven commercial product development. 

The approach of producing detailed specifications, building stuff, and then showing the business owner the finished product once completed did not deliver the best results. It became evident that customer product development was better suited to a more iterative lifecycle that enabled quick cycles of collaboration, build, show and tell, etc.

The farm systems group was made up of three teams: business analysts, developers, and software testers. A group of two managers represented (we initially had a traditional organizational structure with a BA manager, test manager, and a development manager) the customer, conducting investigations in the field and providing guidance to the business analysts. The analysts then produced detailed systems-requirements documents for the developers to build and the testers to test from.

The farm systems team had a clearly articulated mission statement: To create a reliable, efficient, and high-quality development capability in order to facilitate fast delivery of high-integrity software technology products for our customers. Supporting this mission statement were clear, strategic goals:

• Keep development capability in house.
• Accelerate time to market for product delivery.
• Be agile and responsive to customer needs.
• Increase quality and reduce cost of product development.
• Leverage existing skills and capabilities in order to reduce rework.
• Create a great place to work.

Although the whole team was committed to these goals and believed that they were attainable, the biggest challenge was how to achieve them.

Identifying the Pain Points
Since its formation in 2007, farm systems had used traditional waterfall development methods. Although we always managed to deliver to the customer, projects were generally completed over time and over budget. This was not working for our customers or for our staff. The traditional waterfall methods were proving too cumbersome for a fast-moving, customer-driven product range.

In order to be responsive to customers’ needs, we needed to do the following:

• Provide product managers with early visibility of what was being developed.
• Engage and work with customers.
• Plan to re-plan by providing customers with the ability to change scope during the development phase without major productivity loss or increased cost.
• Be more responsive to changes in the market or economy.

Subsequent to the release of the latest version of the LIC’s Animal Management System (MINDA) product, the team held a post-implementation review to identify challenges and learning opportunities. We had good metrics and were able to identify what had happened through the development process. By reviewing the requirements work done in the previous twelve months and comparing the resultant product, we identified that 40 percent of the requirements work was wasted. The delivered product had 50 percent of the initial requirements implemented, along with many new features that were not initially planned for.

Table 1 shows the time spent on items that were subsequently de-scoped. Table 2 shows the time that was spent on rework with respect to analysis, testing, and development. Approximately one quarter of the total project budget could have been saved.

Stage	Hours	Rate	Dollars $
Business Analysis	384	$100/hour	$38,400
Development	104	$100/hour	$10,400
Technical writin	212.8	$40/hour	$8,512

Table 1

Stage	Hours	Rate	Dollars $
Development rework	1,420	$100/hour	$142,000
Analysis (document updates)	200	$100/hour	$20,000
Test script updates	240	$90	$21,600

Table 2

In order to address these concerns, we held a two-day facilitated workshop in June 2009 with participants from farm systems, IT, and the project management office. An important part of the workshop was for the team to identify pain points in the current development methodology and how they impacted the successful delivery of software projects.

The following identified pain points covered the whole gamut of communication and waste, which have become synonymous with software development projects:

• Lack of role clarity
• Unclear and changing business needs
• Cumbersome change-management processes
• Impact of multitasking
• Poor estimating, resulting in unrealistic workloads
• Lack of visibility of project status

Addressing the Pain
Prior to the workshop, some of the team had attended an “introduction to agile” training class and Software Education’s Software Development Conference (SDC)in March 2009, including a requirements-by-collaboration workshop by Ellen Gottesdiener. This gave them an understanding of the principles and philosophies behind agile methods.

Part of our workshop involved a presentation on the various agile software development practices, followed by extensive debate among the team members about how (if at all) the team could apply these practices to address the pain points and whether the team was prepared to apply them.

The team identified specific practices that could improve the software development process, including the following:

Daily Standups: Meetings that provide rapid and efficient information sharing from within the team.

Retrospectives: Meetings to discuss what has been going well, what has not gone well, and what are we puzzled by; these retrospectives are key in moving these learnings forward every day.

Showcases: Sharing with our stakeholders progress, which enables early and continuous feedback.

It is important to note here that while management provided support, encouragement, and the leeway to make the changes, the team was responsible for selecting those changes.

What resulted was not a branded agile methodology (for instance, we didn’t adopt Scrum or Dynamic Systems Development Method (DSDM)as our approach), but rather a pragmatic set of practices that fit with the agile philosophy and aligned with LIC’s values and behaviors. Our selected practices (iterative development, requirements as stories, sustainable pace, daily standups, social contracts, retrospectives,co-location, adaptive planning, continuous feedback, frequent small releases, automated testing, continuous integration, test-driven development, refactoring, and pair programming)form the core of LIC’s agile, iterative approach, specifically aimed at creating a more collaborative environment with cross-functional teams, each dedicated to a single work stream along with open communication with the customer representatives. We have drawn from the social, management, and technical practices of a variety of branded agile methods as they reinforce each other and provide us with the improvements we were seeking.

Learning the Practices
Having identified the practices that team members felt would help them improve the software development process, the next step was for everyone to agree upon an implementation approach. After a team discussion, we decided to train everyone in the practices using real LIC projects, reorganize team members into two cross-functional teams, co-locate those teams into a reorganized space, and get them started on two work streams.

Our first step was to provide some structured training on agile for the whole group, including courses in team practices, stories, testing, project management, and programming techniques. To ensure that the team could implement this training in a real-life scenario, they undertook the training using real LIC projects. (We had hoped to select non-critical projects in terms of scope, time, and budget, but this wasn’t possible in our commercial environment.) Farm systems needed to deliver two major projects within the next year: the next release of the MINDA product and a new, pasture-to-plate traceability product. The group formed two cross-functional teams, and the training began.

During the excercises, the two teams worked on identifying the stories for their projects. In a single, one-day, collaborative workshop, they scoped the two projects, identified the user stories, prioritized and estimated the stories, and produced initial release plans for the products. This was an enlightening experience. The teams were totally focused on their individual projects with no task switching, and they had the right people in the room and the necessary tools (flip chart, paper, pens, and wall space) to achieve their goal.

Rob Ford, general manager of the farm systems division, said during day one of the “Requirements as Stories” training course, “We achieved in one day what normally takes us six weeks!”

We had learned a powerful lesson. Given the right people, a dedicated focus, a collaborative approach, the right tools, and the right environment, we could deliver.

Figure 1: The story-writing workshop

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.

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.

One Year Later: The Impact of the New Practices
One year after implementing the agile practices, we have realized some some clear, measurable benefits. For the business sponsor, we have seen visibility and ownership leading to the right product’s being delivered within time, scope, and budget. Release cycles for the core MINDA product have gone from one per year to the ability to release one every two months, which has resulted in greater customer involvement, visibility, and customer satisfaction. The teams are now delivering what the customer wants and providing real team spirit, pride, and ownership.

Collaboration across the whole team has been a key to the success. Business sponsors and product managers are integral members of the team, engaged from the very beginning of the projects and interacting with the rest of the team throughout the project. Product managers attend the daily standups and take ownership and responsibility for providing direction for product development, ensuring that what is built meets the needs of the market.

Product quality is measurably higher, both in terms of marketplace success and more mundane measures of software quality, including defect density and product maintainability. Defects reported in production have dropped substantially, and changes are easier to implement due to the internal quality of the code.

The teams actively take ownership of their own practices, drawing from a menu of techniques and tools that have been identified as working well in the farm systems environment.

Conclusion
The LIC agile transformation has been a cultural change, moving from silo-based streams of work that delivered high-quality products thanks to the heroic efforts of the team to cross-functional, collaborative teams working at a sustainable pace and consistently delivering customer value in a predictive manner. Although the transformation has not been without challenges, the iterative model enables the teams to get rapid feedback from the product management group. Responding to changing business priorities is no longer a stressful change-management exercise, but rather a simple replanning activity at the beginning of the next iteration.

Our business owners have stated that:

• We are more customer driven. We have happier product managers and customers due to early visibility of product builds, which means we can effectively manage feedback and change. We are delivering the right products.
• We are delivering higher-quality products with significantly lower defects, which means greater customer satisfaction as measured by customers’ trust in our products.

• We are all working together to achieve the vision by supporting and learning from each other and having fun while doing it.

The first project to be delivered using the agile methodology ( a farm automation product called Ezheat) caused LIC CEO Mark Dewdney to say, “The change to agile techniques has been transformational. The farm systems group is truly delivering software faster, better, and cheaper.” Cooperation and communication is high, and even the remote team members feel that they are a part of a successful, high-performance team making a positive contribution to their farmer customers’ businesses.

Figure 3. A team workshop including a remote team member