In an earlier post, we introduced the Agile transformation occurring at John Deere’s Intelligent Systems Group. In this post, we’ll describe some of the challenges and activities we encountered to get the development and management teams to the “agile tipping point” – the point at which we got the final green light for an “all in” Agile transformation.
Background: Earlier Pilots at ISG
In 2006, a few teams at ISG started experimenting with Agile development. Chad Holdorf and Steve Harty were two of the early adopters. Chad described it this way: “I remember being asked one day by Mano Mannoochahr, ISG Manager of Global Solutions Engineering, if I knew anything about Agile or Scrum. I replied ‘nope’.” Mano said, “Well then, it’s time you learned. I’d like you to lead the desktop teams (North America and India) and use Scrum.”
When asked about the change vector, Mano noted “the primary reason was to introduce the discipline of Agile –I just didn’t think our current process was producing the highest possible code quality. Plus with all the issues and product opportunities we were facing, we needed to increase the productivity of teams and the quality at the same time. Scrum gave us a way to get the whole team engaged more effectively towards that goal.”
Steve Harty, ISG Program Manager & (and now) Release Train Manager, commented: “We knew we needed to increase our speed to market while keeping our budget and resources static. Moving our team to Scrum was scary, challenging, and liberating, all at the same time. Scrum was ‘our little secret’ that helped move our delivery time timeframe from 12-18 months to 2-4 weeks. Plus, our engineering teams were happier and customer satisfaction went up.”
Based on this positive experience, an ISG Agile Transformation Team was formed to develop a plan to move forward with a much larger, and far more impactful, rollout. Of course, as they did so many, many questions from important stakeholders started to appear. For example:
1) Is this an undisciplined process wherein we will lose control of requirements, system behavior and worse, the entire project?
2) If we collocate testers with devs, what happens to the independent quality assurance function? Without requirements, how will we even know what we are supposed to test?
3) What will engineering and test managers do if the teams are empowered and self-organizing?
4) How will the factories react to our Agile plans? What about our continued need for long-term commitments to support new vehicle rollouts?
5) What do architects do in agile? What happens to our architecture?
6) Will software capitalization change, and if so, how?
7) Will this even work with our Enterprise Product Delivery Process (stage-gated governance model)?
8) What is all this write-the-test-first stuff anyway? That seems kinda stupid. And, are we going to have to do pair programming? What if we don’t want to?
9) How do 10-20-30 or more Agile teams coordinate their activities? How can great solutions possibly emerge from all this potential entropy?
10) How and who gets trained and what will the costs be to accomplish that? Who has the budget?
11) How will long range portfolio planning work when the teams can change anything at any time?
12) Who will serve as ScrumMasters and what is a ScrumMaster anyway?
13) This Product Owner thing, who could we possibly empower to make such key decisions that affect our future?
14) Will we suffer a loss of productivity during the transition? (“we can’t afford to go backwards now, not even one day….”)
15) Does management really support this?
16) ……(editors note: we could do a whole post on this, but I tend to write too much anyway)………..
Clearly, there were more possible objections and objectors than we might have imagined. This was starting to look like a losing round of “agile objection whack-a-mole”. So working collaboratively, we organized our ongoing work in four threads.
#1 – Get management onboard and up to speed fast
As this was not “our first country fair”, we knew that we would never succeed without active support (and drive!) from middle and top management. So, in addition to a series of ad hoc informational meetings, we decided to educate them more formally as quickly as possible. After all, these are our leaders, so we resolved that they should lead, not follow, the transformation. (Note to a Scrum team: managers may be “chickens” to you, but to an enterprise, they are “pigs”, and big pigs indeed. Ignore them at your peril.) To this end, most managers participated in a two-day Lean|Agile Leadership Workshop we hosted. Workshop modules included Lean Thinking, Agile Orientation, Experiencing Scrum, Scaling Agile, Agile Technical Practices, and a final half day on Lean|Agile Leadership. This was a very successful series of trainings. We reached virtually all the managers in the R&D organization, as well as key stakeholders in marketing, product validation, factories, etc., in just a few short months. With that background, and an understanding of the potential business benefits, most of them came on board fairly quickly.
Lean|Agile Leadership Workshop. Reprinted with Permission of John Deere.
#2 – Establish groundswell and pull from the Dev Teams
Agile was developed by and for software developers and testers, but that doesn’t mean that all those who have never experienced Agile know what it is or necessarily think they want to do it. To that end, we did a significant amount of socializing with the team leads and first line development managers, looking, not only for support, but for a program that was ready to take the plunge. This was not a particularly difficult challenge, and it culminated at Agile 2010 over a dinner meeting, where we had the opportunity to discuss the challenges and opportunities face to face with a number of the Agile Transformation team members and various team leads.
Andy Beck, ISG Development Lead, Machine Controls, led the charge: “I always thought that Agile could be a great process, but until the conference, I had difficulty seeing how we could transform the John Deere waterfall methodology. After just a few days at the conference and that evening meal, the lights came on and the way was clear. I knew that we needed to make a change in the culture at ISG and Agile had the potential to make a huge impact…if we could just get it started. Well then, might as well start with my teams.”
#3 – All In
Because ISG’s displays contain many millions of lines of code that had 200+ developers and tester working on it, we couldn’t only have half of the people on board. Joel Hergenreter, ISG Manager of Product Validation and Verification, noted, “Because our system was not well componentized, it would be difficult to implement Agile with a portion of our teams. First, the merge strategy: how do we plan and continuously integrate if some teams are Agile and others are not in a tightly coupled system? Second, once we implemented Agile on a few teams, others would want to jump on board quickly due to the strong cultural desire to deliver high quality products faster. It would be impossible to say who wanted to make these types of improvements. We also knew that we would need more than Scrum to scale agile across the enterprise, so we adopted Dean Leffingwell’s Scaled Agile Delivery Model, which consists of a series of release “trains” operating on a common cadence.”
GreenstarTM 2630 Display, developed and produced by ISG. Reprinted with permission of John Deere.
Holdorf notes: “Once we agreed to add everyone to the train, we began drafting initial teams of 7 +/-2 that would work together until the 2630 launched. You wouldn’t believe how hard it was to just put people on ONE team and have then focus on ONE thing. People were so multiplexed it was painful and nearly impossible to understand the current situation or even write it all down, but we knew we needed teams to focus if we wanted to be successful”.
# 4- Establish a training plan and budget
Chad continues, “Because we were training so many people so quickly, we decided to train them all at once. I remember Dean asking me, ‘well, how big a room do you have, Chad? We’ll just stick ‘em all in it and just do it’. We have a really big all employee room at ISG, so the game was on. Of course, we had to put together a budget for trainers and coaches, and that was not trivial, but at least we now had a plan to budget against (though I admit to being quite nervous about the scope and impact of even the initial training)”.
The Final Go Ahead
Eventually, we had enough support from all the key stakeholders, and a budget, so we were ready to forward. However, one small problem remained – we needed a program. One program – a display, controllers, guidance and documentation systems, and related software projects largely branded under the GreenstarTM label –was an obvious candidate. Plus, that’s where we had established the most pull from Andy and other development managers and teams. However, therein, another problem appeared – that program was in the throes of a waterfall-end-game-prerelease-firefight, with an immovable goal of a January 15 product launch. It was then September of 2010. Could we launch such a major transformation at the tail end of a waterfall program? Will we make it worse? NO? Are we sure? Do the potential benefits outweigh the real risks? Or should we simply wait until next year?
With the courage of its newfound Agile convictions, ISG eventually concluded to simply go, and GO now, on the Greenstar program. At that time, with the support of his peers, Larry Clemens, (Manager, Program Management), stepped up and signaled the final go ahead. Clemens noted the angst present during the deliberation and how he came to the “GO” decision: “There comes a time in all major change initiatives when you have to stop piloting and just make the change within the organization. We don’t have any programs that are not critical to experiment with, so these are never easy decisions. But the longer you wait, the later you receive the benefits”.
Summary
Now we had our program, a budget, a method, consultants and trainers, dev teams, a really big room, and a lot of (perhaps not unanimous?) management support. Now, it was our time to execute. How hard can that be? Hmmmm.
Next post: The All Aboard the GreenstarTM Release Train
Background on John Deere ISG
From the company’s job posting website:
John Deere Intelligent Solutions Group plays a key role for Deere & Company in designing and delivering the technology needed by their customers to help them meet the challenge of growing more food and building much-needed infrastructure – challenges that must be met as the world’s population is expected to grow to 9 billion people by 2050. They’re a great place to work, too. With technology that utilizes satellite-based global-positioning, John Deere Intelligent Solutions Group designs displays and receivers, guidance systems, field and crop management, and information and logistics systems their customers rely on. They leverage Agile project methods to deliver the most advanced innovations to their products. They foster a creative environment where employees feel empowered to put their best ideas forward and forge their own career path.” (And yes, they have ping pong and foosball tables. Maybe a future post about office environment changes).
Jobs at John Deere ISG
Like every successful software business, Deere is always looking for talented people. If you are interested in a new career, building software with agility, and more importantly, helping address the challenges of feeding the world, contact Arneda Shelton and check out: www.johndeere.com/careers/
Scaling Software Agility 