Appendix. John Deere Case Study

John Deere, a global leader in agricultural and construction heavy equipment headquartered in Moline, Illinois, may not be the first company that comes to mind when you think about Agile software development. Many are surprised to learn that John Deere has a large software development organization, called Intelligent Solutions Group (ISG), whose mission is to deliver innovative solutions that radically improve their customers’ productivity, efficiency, yield, and, ultimately, profitability as they build and feed the world. This includes global positioning system (GPS) software displays for the tractors and the Web tools that allow their customers to manage the data that is collected from the tractor for precision agriculture (see Figure A.1).

Figure A.1 Farmer using the ISG GPS

Like any company that has withstood the test of time, John Deere values innovation, one of their core values, and supports creative solutions to business and technological problems. In 2010, John Deere was facing a challenge that many technology companies were facing—they needed a way to deliver increased value to their customers more quickly. The Waterfall methodology they were using limited their ability to develop and deliver solutions that customers demanded; their response was to become an Agile software development organization. We caught up with three of their leaders to garner some insight about their transformation.

• Tony Thelen—Director, Solutions Infrastructure, Intelligent Solutions Group

• Rob Roling—Development Team Lead

• Joyce Harris—Product Owner

Interviewer: What led to the decision to go Agile?

Thelen: The realization that we needed to improve performance of our operations, particularly in regard to customer focus and responsiveness, quality, innovation, and employee engagement. We researched opportunities to improve and spoke with many in the industry to land on our final recommendation to move to an Agile software development structure.

Roling: Our need to deliver smaller features more often.

Interviewer: Was your movement to Agile a bottom-up movement or more of a top-down dictate?

Thelen: The business requirements to improve were driven from the top down; however, the solution of Agile being the manner to do this was bottom-up.

Roling: A few teams were given the option to try it and had success. Then other teams requested the opportunity to try it and it grew from there. It was a bottom-up movement with top-level support.

Interviewer: What was your biggest challenge as a leader rolling out Agile in a large organization?

Thelen: Managing expectations and ensuring we had the right skills and expertise to guide us through this journey. Thankfully, we had a few key individuals in the right positions to help us make these decisions and see the implementation all the way through.

Interviewer: Were all teams included, or was it a rolling implementation?

Thelen: We decided to ensure we had 100% of our operations converted inside a six-month window in order to achieve optimum impact and to help people engage the new process.

Roling: It was a rolling implementation.

Interviewer: Are all divisions of ISG doing Agile development? If so, has it worked better for some departments than others?

Thelen: All divisions of ISG are working in an Agile methodology, some more strict than others, but the protocols to what is Agile are applied everywhere. Depending on the nature of the projects being undertaken, we have seen some areas do better than others. Those projects that are very wide and far-reaching in scope have struggled to maintain expectations, but those that had a more narrow or short-term scope have generally fared much better.

Roling: I believe all ISG groups are doing Agile. It works better for web site development than vehicle display development. The vehicle displays are a component of John Deere equipment like tractors and combines. The software approval process for components on our equipment does take more time.

Interviewer: What form of Agile was chosen? How was that decision made? Do you have a variety, for example, Scrum, Kanban, XP?

Thelen: We do XP and TDD as a practice, but have used the Agile methodology to organize our people and our work streams. This was based on discussion with an industry Agile coach.

Roling: We started with basic Scrum and XP. Kanban has been adopted by a few teams lately and has been very successful.

Interviewer: What was the degree of executive sponsorship?

Thelen: We had full support of a senior vice president, president, and eventually the CEO to continue down this path.

Roling: ISG leadership bought into Agile early and promoted it.

Interviewer: How much did you rely on outside coaching to make the transition to Agile? Did you hire full-time Agile consultants? For how long?

Thelen: We relied on an external coach for a year to help us manage this transition, and have used this same coach to come in one year later to fine-tune our operations.

Roling: External coaching was a key to our success. It is important to have a mix of Agile coaches and XP coaches. We have had full-time Agile consultants for over two years.

Interviewer: What training programs do you have in place? How have those changed through the course of the implementation?

Thelen: We currently have two areas active in training—first are classes that introduce Agile concepts to employees, and secondly we sponsor attendance at industry conferences and in some cases hold summit meetings with key companies who are dealing with Agile at scale.

Interviewer: What roles were considered important initially? Has that changed as your implementation progressed?

Thelen: Many roles changed, as all had to adjust to a team-driven environment—all played key roles in supporting this change and supporting each other as the organization adapted.

Roling: Scrum masters were important initially. Most of our product owners also do the Scrum master role now. Initially we treated them separately.

Interviewer: How did you decide on the makeup of the original Scrum teams? Did you assign people to teams, or did you let individuals decide which team they would work on?

Roling: We assigned people to teams based on who they were currently working with already. We assigned many systems engineers as product owners.

Interviewer: Did you assign Scrum teams to a specific function, or can a Scrum team handle multiple functional areas?

Thelen: We assigned various product groups to Scrum teams supported by functional areas of expertise—marketing, engineering, program management, etc.

Roling: Scrum teams are typically skilled in a specific code base, and they can handle multiple features within that code base.

Interviewer: What were the cultural impacts of your adoption? Was there anything that was easier or harder than anticipated?

Thelen: Moving to a team-based structure was a difficult transition for many of our middle management layers—in some cases areas that were significantly reduced or eliminated altogether. The culture of ownership at the team level produced significant increases in employee engagement, innovation, and quality improvements. Having the appropriate level of metrics to measure our progress was and continues to be a difficult area.

Roling: Daily stand-up meetings [see Figure A.2] promoted more communication and transparency among Scrum team members. Team members started using paired programming to work out designs and debug defects. As team members worked together, they started tearing down cube walls and moving toward the collaborative workspace we have now.

Figure A.2 John Deere team during a daily stand-up meeting

Harris: Within my project group, adoption was a mixture of relief and victory. We had several folks who had experience with Agile elsewhere and a few teams who were being Agile before it was sanctioned by the enterprise. The feelings could be likened to underground freedom fighters that, once the tide has turned, can now fight openly for their cause. And, as in any revolution, there were some that resisted change and hung onto the old ways.

Easier: Management support for the adoption of XP practices such as pair programming.

Harder: Priority alignment across trains; what is #1 for solutions is #4 for displays, and the feature needs work done in both areas to provide value to the user. We knew it was going to be hard, but it has been harder even than we had imagined.

Interviewer: How have you had to adapt your management style for Agile?

Roling: Agile allowed me to empower my team, which has improved employee engagement.

Interviewer: Are you deploying code faster? more accurately? How do you measure the success of your implementation?

Thelen: We have been able to demonstrate step function improvements in quality, innovation, speed to market, and employee engagement. In some of these areas, we have demonstrated far beyond our expectations. With these successes, we have also been provided more opportunities that we are able to address in a timely manner, which has led to a need to better manage expectations of the enterprise as well as closely monitor our own internal commitments in portfolio management.

Roling: We are deploying code much faster and with higher quality. I measure success by how quickly we can release features to customers. We have a ways to go on releasing faster. Our next challenge is to get the rest of our organization to deliver at the same speed. For example, our marketing department continues bundling our features together and releasing them in large groups to minimize training overhead. We need to find a way to get our features out as they are developed instead of putting them on the shelf until we have a large bundle ready to go.

Interviewer: How do you collect user stories? What tools do you use?

Harris: There are a variety of methods to gather stories, depending on the size and scope. We have a formal process for gathering customer needs that marketing owns; Out of that, broad strategies are generated. Out of that come epics, features, and stories. These are created in a series of workshops with many stakeholders to refine the broad strategies. I participate in some workshops but once it gets to the feature level, I truly own it and work with the development team, user experience, and architecture to further break down and refine it into user stories (see Figure A.3).

Figure A.3 John Deere team participates in a card-sorting activity

Interviewer: What was the hardest part of the transition as a product owner?

Harris: Balancing between the voice of the customer and the realistic development challenges; having all the responsibility for how the features should be but none of the authority to make decisions to get things done (for example, getting people’s time from other trains).

Interviewer: How are you measured as a product owner?

Harris: That’s a very good question. I don’t have a good answer. Different POs have different skill sets, so expectations are different for each. I am a senior software developer and have broad experience with our products and system, as well as relevant domain knowledge, so I operate on a level above a typical product owner with a single Scrum team, more of a systems engineer. We referred to it as “uber product owner.” I still have my primary Scrum team to provide detailed story direction, but I had a cluster of sister teams to coordinate interactions between components of the system.

Interviewer: Has your “go to market” strategy changed at all due to Agile? Are you communicating with the marketplace differently?

Thelen: We are adapting over time to new and more innovative ways to move value to the market—including in some cases daily and weekly delivery of value. As our capabilities evolve, there will be continued need to adapt and adjust the “go to market” strategy accordingly.

Interviewer: Has the move to Agile increased customer satisfaction with your products?

Thelen: Customer satisfaction has been primarily impacted through higher quality, faster speed to response on field issues, and in some cases more finely tuned features that meet customer needs by engaging customers earlier in the design process.

Roling: Our customers have noticed that we respond to defects faster, but we haven’t released new features at a high frequency yet.

Harris: The product that my team developed was well received in the marketplace, and the actual rollout to production was a huge nonevent because we did incremental development and were able to act upon customer feedback prior to release. In the past, that feedback would’ve had to be scheduled and approved by higher levels of management, so it essentially never happened.

Interviewer: How much interaction do you have with customers?

Harris: I function more as a proxy product owner. The marketing product manager has frequent interaction with real customers. I make customer visits once or twice a year. However, since our domain is agriculture and I live in Iowa and come from a farming family, my informal interactions with customers are quite frequent.

Interviewer: What is the biggest benefit you have seen from using the Agile development methodology?

Harris: The ability to react more quickly to change. It is a lot easier to kill off bad ideas and mistaken assumptions.

• What role did executive sponsorship play in their transition?

• What impact did Agile methods have on their culture?

• How did Agile change their product outcomes?

• Is their definition of a product owner the same or different from what you have seen or experienced in other Agile organizations? How so?