Guest Post: Knowledge Flow in the Scaled Agile Delivery Model

My colleague, (and partner in a number of agile rollouts), Alex Yakyma from Kyiv, Ukraine, has been opining on how the Agile Release Train and the Scaled Agile Delivery Model in general, helps drive knowledge acquisition, accumulation, and flow in the agile enterprise. He just put up a new post, Knowledge Flow in the Scaled Agile Delivery Model, which describes Nonaka and Konno’s Socialization, Externalization, Combination, and Internalization (SECI) model for the acquisition of new knowledge. We’ve seen this “ba” (*the Zen of Scrum, see note below) drive teams to higher and higher levels of performance, and we see it in some agile programs (release trains) too.

I think you’ll find the article interesting, but fair warning, there will be some thinking involved. (But that’s usually required for new knowledge acquisition).

*Note: “Ba” is the energy and knowledge acquisition power of agile teams, or as Jeff Sutherland puts it, “BA is the zen of Scrum”. Ba can be described as follows:


Concurrent US-India Release Planning Agenda

Many of our larger software enterprises (perhaps MOST) do substantial development within the continental United States and also have a significant offshore development presence, most likely in India (or China or both and more). So it is a very common pattern that some large group of developers here, and a large group in India, must collaborate on building larger scale systems of systems in the model of the Agile Release Train and Scaled Agile Delivery Model.

While face to face planning is by far preferred, this is simply not practical in these cases, as the enterprise must entertain a budget and overhead of flying, say 100 developers, halfway around the world, putting them in relatively expense hotels, renting cars etc etc etc. It’s a great notion, but it simply doesn’t scale. So there is a need for concurrent, real time face-to-face-like release planning that does not encounter those costs. Everyone plans together, but they plan from their respective locations. However, even with adequate video, audio and text-based real time communications, the time zone differences (typically 9.5-10.5 hours) really exacerbate the planning challenge. After all, which team wants to plan at midnight? Since neither do, some enterprises have developed a joint, concurrent planning model that mitigates the time zone problem, albeit by sharing some of the pain of awkward working hours.

An example is below:

Note 1: This agenda assumes a 10.5 our time distance between the US and Inida locations.
Note 2: all agenda items in white background are joint, shared, real-time sessions with remote communications. All agenda items with a grey background or non-overlapping sessions (regions work independently).

Day 1 US

Day 2 US

Day 3 US

Day 1 India

Day 2 India

Day 3 India

Special note: I’ve never been happy with this six page agenda format. While it works well for the participants in the individual locations, as a planner or anyone else who needs the gestalt of the whole operation, it’s hard to piece the whole thing together. If any reader can come up with a condensed, legible, moderately aesthetically pleasing, three page version, pretty printable (for review and poster sized printouts in the sessions) where you can see everything at a glance, I’ll publish it here and thank the contributor profusely!

(Hint: probably need to do it in excel in a four column spread, with 24 rows, one per hour of day, and blackout shading for respective locations during sleep time.)

Agile Meets Big Iron: Agile Transformation at John Deere ISG

John Deere’s Intelligent Solutions Group (ISG) has recently announced that they are in the midst of a large-scale agile transformation that affects hundreds of software practitioners worldwide. This is a particularly interesting agile transformation for a number of reasons (many of which have been used as excuses by other enterprises as to why NOT to go agile), including:

  1. It’s BIG and they took an “all in” approach. Many hundreds of developers were immediately impacted.
  2. It’s distributed. Affecting teams in the US, Europe and India.
  3. Systems are embedded, real time and complex.  ISG builds solutions that consist of displays, receivers, guidance systems and more for BIG hardware, including tractors, sprayers and combines.  They also build telecommunication systems, websites and portals.
  4.  Delivery dates are fixed. New vehicles leave the factory every year, and they leave on time. The software has to be extremely high quality, and it must be ready on time, too. (No easy pushes to a web site for corrections, here)

Here’s a few pictures, just to give you some context on building software for things that really can “go bump in the night” (daytime too).

John Deere Tractor with GPS guidance system. Reprinted by permission of John Deere.

GreenstarTM 2630 Display, developed and produced by ISG. Reprinted by permission of John Deere.

Chad Holdorf, Scaled Agile Coach at ISG, has started blogging about his experiences at . He has already put a number of interesting posts, all relevant to large-scale development, and many showing advanced agile practices at scale.

A Case Study

I’ll be blogging about this transformation too, in a lightweight “case study” form. The next post in the series, tentatively entitled “Reaching the Tipping Point”, should be available in about a week. Follow on posts will focus mostly on the major rollout activities and how they successfully addressed the larger challenges, challenges that (most) all large enterprises face when they head down this path.

A Special Thanks to John Deere

Rarely in our industry do we get chance to describe a real transformation, in real time, in a real company, so we are very appreciative of John Deere for allowing us to describe their experiences in this format. And we take pride in Deere’s courage to drive technological innovation in a business that was founded in 1837! Our hope is that these experiences might encourage others to follow down this path, and receive the many benefits – including the improvements, in morale, job satisfaction, and yes, just plain fun – that every agile enterprise can experience.

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, check out:

Tracking Large Scale Customer Releases

A few days back, my colleague, Chad Holdorf, published a video blog post illustrating one way to track enterprise-scale releases (using Rally tooling in this case). The post is here.

They’ll be more on Chad’s work in an upcoming post about John Deere’s implementation of agile at enterprise scale. That should make an interesting case study, which Deere has graciously allowed us to publish as a work in process.