BT

Your Tractor Was Built With Agile

by Christopher Goldsbury on Mar 17, 2012 |

 InfoQ interviewed John Deere's agile ninja, Chad Holdorf, on their recent agile transformation at the Intelligent Solutoins Group. 

 

InfoQ: How did the move to agile software development come about at John Deere ISG? Did some specific event trigger this or was it just a gradual recognition of the benefits?

Chad: John Deere started experimenting with Scrum with a few teams in 2007. By early 2010 we had about 10 teams practicing scrum and many more teams wanting to learn. In September of 2010, we had a product launch planned for January 2011, and we realized there was no way were going to be able to deliver critical new functionality without a substantial change in the way we were working. So we broke down the functional barriers, organized into agile teams, introduced scrum+ to 150+ people over one week, and went “all-in” with agile on that program.  

InfoQ: What flavor of agile are you implementing? Scrum? XP? Some hybrid approach? Why did Deere choose this flavor?

Chad: Many companies use a 3 or 4 letter acronym to describe a process or product. We introduced SADM, or Scaled Agile Delivery Methodology to provide guidelines to a common agile way of working within ISG. SADM combines Scrum, the Scaled Agile Framework, XP and Lean principals into one holistic process. 

InfoQ: Was Deere's adoption of agility an IT only movement, or does the business participate and support it? In other words...did John Deere become agile or just the Intelligent Solutions Group inside Deere?

Chad: Agile is spreading quickly to all parts of John Deere. By no means is all of John Deere practicing Agile, but more and more units continue to implement agile practices. Today John Deere has over 1,500 people practicing Agile. 

InfoQ: Agile adoption can present a cultural change for an organization. How did John Deere manage this change?

Chad: I originally underestimated the cultural change that we were undertaking. Most everyone’s roles and activities were affected. But we were patient. We continually evangelized the new process and the business benefits we expected it to deliver. Plus agile is generally very well received by the development teams themselves, and since they write and test all the code, that part was fairly easy. In the end, every enterprise must make its way to whatever new processes deliver the best quality, productivity, time to market and employee engagement, or they will simply fail to thrive. At Deere, we’ve been changing for over 150 years. Not changing is generally not an option.

InfoQ: What made John Deere adopt a big bang approach to agile adoption vs gradual adoption?

Chad: John Deere’s products are tightly integrated into a much larger system that consists of complex and sophisticated machines. If we were to do a gradual adoption, the integration of products developed by different methods would have been painful and virtually impossible to coordinate. Even then, our adoption was somewhat gradual as we implemented in large chunks of 100 people at a time over 3-6 months.

InfoQ: What does your agile estimating process look like?

Chad: We use story point estimates across the entire organization, but those are team based metrics, rather then organizational, measures. We will be moving to feature throughput as a better measure of velocity and program process.

 

InfoQ: How does outsourcing and offshoring fit into your agile implementation?

Chad: We have two Deere offshore locations that also adopted the same process. We are purposefully all on the same sprint schedules, making coordination a lot easier. As for outsourcing, we are working with our suppliers to train them on our agile practices, thereby making it easier communicate and coordinate with them too.

 

InfoQ: How does John Deere handle conflicts between product owners?

Chad: We have a ping pong table in our office and we tell them to settle it there. J. In all honestly, everyone wants more than what is possible. We have to make trade-offs constantly, and we try to focus simply on what will provide the most value to all of John Deere’s customers.  

InfoQ: How well does agility fit with all your software products? Are some a better fit than others?

Chad: Well, it’s easier to implement agile on our web properties than it is to apply it to combines, sprayers and tractors, but everyone has the same process and the same mentality - which is to produce high value, quality software quickly, software that delights our customers. 

InfoQ: What recommendations would you give others who are looking at implementing agile software development? 

Chad: There is never a good time for significant change, and sometimes its seems easier to continue to do what you have always been doing. But, but the world is changing rapidly, and our customers and our market demands that we change too. Start with a few agile teams and then inspect and adopt. Then when the “pull” from the organization is strong, move fast and never look back.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

My tractor? by Morgoth Melkor

I don't own one.

Thank You InfoQ by Chad Holdorf

Thanks Chris / InfoQ for publishing this article. Enjoyed talking to you about John Deere ISG’s Agile adoption. I’m a big fan of the InfoQ website as it provides tons of great info that helped me find the Agile info I needed to help our organization get started. If your company is contemplating going “all-in” on Agile, take a look at these first year metrics and ask if your company would like the same.
Field Issue Resolution Time DOWN 42%
Warranty Expenses DOWN 50%
Time to Production DOWN 20%
First to Market UP 20%
And my favorite Employee Engagement UP 9.8%

To read more about our transformation, check out this link.
scalingsoftwareagilityblog.com/john-deeres-isg-...

Feature Throughput by Jeff Maher

One of the answers from JD says that they will be moving to feature throughput for estimations rather than story points. What does that look like? (Tried to Google for 'agile "feature throughput"', which circled me back to this article :-) ).

Re: Feature Throughput by Chad Holdorf

In traditional Scrum teams can measure the speed (cycle) and rate (throughput) at which stories go through the system. We are just using one level above a story (collection of stories) and look at the cycle time and throughput of features. It's not perfect but helps with planning. It's also better then using velocity. If you look at this picture, scaledagileframework.com/ you can see the items above stories are called features. If that is still confusing I could do a quick blog on it with some pictures.

Cycle example - www.rallydev.com/help/team-measurements?basehost=https://rally1.rallydev.com#cycle
Throughput example - www.rallydev.com/help/team-measurements?basehost=https://rally1.rallydev.com#through

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT