Background: In prior posts, we introduced the almost-real-time case study describing a large-scale agile transformation at John Deere’s ISG. In the last post, we described some of the work that was required to get Deere to the tipping point—the point at which we got the go-agile approval from the leadership team. This post describes the all-in “quickstart” implementation of the first ISG Agile Release Train.
Constitution of the Train
In preparation for training and release planning, the first challenge was to figure out the “domain” of the train; In other words, what teams needed to work together to deliver the end user value? While it seems obvious in hindsight, at the time it wasn’t at all clear what products and teams would constitute the train. In the end, we decide that it would be a big train, with as many as 100-130 practitioners, and it would encompass all the products generally carried under the GreenStar™ brand. Agile Coach, Chad Holdorf recalls,
“While there was a strong pull from parts of the GreenStar™ products to go agile, some were still unsure how this would work. Finally, we all realized that we couldn’t have part of the product on the train and the other parts still operating as is, so we just decided to roll it all together. We decided to include all currently supported products, some web portals and utilities, as well as some future platforms currently in advanced development. Cleverly, we then just decided to call it the ‘GreenStar™ Release Train’, even though not every system element was part of the GreenStar™ solution per se. But, we had to call it something!”
Organizing Scrum Teams and Assigning Responsibilities
Once we knew the domain, the next order of business was to establish the approximately 12-14 teams (Scrum team = 7+/2 people, including devs, testers, product owner and Scrum Master). Again, some were obvious as small teams were already working on some components, but there were new features and new platforms that also needed dedicated resources. Plus all the testers reported into a separate organization, called Product Verification and Validation (PV&V). Chad worked with the line managers to create a spreadsheet “straw dog proposal” that we could at least use as a starting point.
Chad comments:
“This was actually quite difficult. It sounds easy, but when people are already on 2-5 projects at one time, it was a challenge to not put a person on more than one team.” Once we formed teams, we then had to figure out roughly what each teach would be responsible for. This part was eye opening as some teams had many things that they were responsible for, but clearly they could not work on all of it at the same time.”
Susan Morrison, then PV&V manager, commented
“It was also a bit cathartic to think about refactoring the entire organization so that testers would be collocated with developers and likely became part of those teams, but my team leads were all in favor, and it was clearly the right thing to do for the business. So, we just rolled up our sleeves, and started making initial assignments of 1-2 testers per dev team”. Susan continues, “none of us knew exactly how our management roles would evolve, but sometimes you just have to take the plunge and trust the business to do the right thing.”
Picking ScrumMasters
Being that Agile and Scrum were relatively new to the majority of the ISG organization, we needed some people that were familiar with Scrum and planning activities to help ensure the teams were on track to meet their objectives. Many of our Program Managers were assigned the role of Scrum Master to help the teams follow the Scrum process. Because there were so many teams, some Program Managers were the Scrum Master for multiple teams. This created problems during Release Planning because we were all planning at the same time; Program Managers struggled to support all teams. Since then, we have dedicated Scrum Masters for each team.
Picking Product Owners
Given the critical role that the product owner plays (see posts), picking the right people for that role was no trivial task either. Chad comments
“We recognized immediately that finding and empowering Product Owners that could guide the team toward our business goals was a major challenge and a key success factor. Not only was this a new role, but it also created a bit of an organizational and political challenge. A great Product Owner needs to understand the organization’s business goals and the product’s capabilities and technologies. As importantly, the Product Owner needs to love to work daily with developers and testers, and most importantly, can make crisp, on-the-fly decisions that affects the product direction. They have to have the full respect of the developer, too. Picking current business analysts or system requirements folks and just inserting them into this role is’t always a good fit. Instead, we decided to find the skills we needed first and then didn’t hesitate to pull them from any functional area.”
The Greenstar™ Training and Release Planning event
With that behind us, we were ready for the fun part—launching the train. We considered a number of rollout strategies, including incremental, but decided it would be easiest to get everyone on board asap. Further, to avoid dragging it out and potentially suffering either a loss of momentum, or subjecting the teams to different methods or trainers, we decided to do it one time only, all at once, and all in one week. We thought that would minimize disruption and make the move to agile as fast and efficient as possible. Also, there could be no looking back, as the “boats that got us here” were left far, far behind. To this end, we built a training plan as illustrated below:
An All-In Agile Program Quick Start
Of course, it was no trivial feat to get 100+ people trained and transitioned to agile in a week, but it was really, really fun and the teams themselves provided the energy (we provided trainer, facility and food!) Chad made this cool video which gives you a sense for the magnitude and dynamic nature of event:http://www.youtube.com/watch?v=UPMBh-E7ahY.
My partner/agilemaster/Alex Yakyma wasn’t actually there, but it looked a lot like this other one that he pictured for me.
A Special Note on the Role of “Subtle Control” of Self-Organizing Teams
Well, that’s it for this post, describing how we kick-started the first ISG release train.
This was an exercise in semi-self organization of a significant portion of an enterprise, and self-organization is an interesting topic in agile. A few years back, while researching the roots of Scrum/agile in preparation for the writing of Scaling Software Agility, I found this presentation by Jeff Sutherland. In turn, that triggered a vector into a 1986 Harvard Business review article entitled the New, New Product Development Game. This is one of the most interesting things I’ve ever read on concurrent engineering, and product development in general. For me, it’s the Rosetta stone of most things agile, and I highly recommend it to all. In the article, authors Takeuchi and Nonaka note:
“Although project teams are largely on their own, management establishes enough checkpoints to prevent instability, ambiguity and tension from turning into chaos…..
That will be the topic of the next post in this series: “Subtle Control”
Background on John Deere ISG
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 