Update and Coming Webinar on the Scaled Agile Framework

As I announced in a previous blog entry , the Scaled Agile Framework further elaborates and refines the scaling practices described in my books Agile Software Requirements and Scaling Software Agility, as well as this blog.

As I work with my colleagues to elaborate and extend the framework and make it publicly available as a structured, interactive website, we’ve begun introducing it in different forums. Next week, Drew Jemilo will be presenting a webinar introduction to the framework as part of the European Agile Knowledge Hub webinar series. For details, see below

WHAT: The Scaled Agile Framework (SAF): Applying Lean-Agile to the Enterprise

WHEN: Tuesday, November 22nd, 2011, 9:00 PM – 10:00 PM CET

(I’ve translated times for you since the Agile Knowledge Hub is attended by professionals from around the world:)

9:00 PM – 10:00 PM CET (Berlin)
8:00 PM – 9:00 PM GMT (London)
2:00 PM – 3:00 PM CST (Chicago)
6:00 PM – 7:00 PM BRST (Rio de Janeiro)

You can read about the session on the Knowledge Hub Blog and sign up via GoTo Meeting.

Meanwhile, we are still on track for a private beta release of the framework in early December and our general release in late February.

You can find out more http://www.scaledagileframework.com. You can also sign up for news updates by entering your email address in the lower right of the home page there.

Advertisements

Upcoming Public Lean|Agile Leadership Workshops in Australia

As I’ve noted on this blog before, delivering my two-day Lean|Agile Leadership workshop to managers and executives is one of the most fun things I get to do. Even more importantly, it has a major benefit in preparing leaders, managers and executives to lead, rather than follow, this critical business transformation. After all, no enterprise can be leaner than its executives thinking.

Most of these workshops are delivered at a client’s site. However, I do have two public workshops scheduled in Sydney (February 7&8) and Melbourne (Feb 14&15),  Australia in February 2012. You can register for these workshops through Agile University here:

Agile Release Train: Develop Synchronously, Release Whenever.

The software development paradigm called the Agile Release Train (introduced in Scaling Software Agility and better elaborated in Agile Software Requirements) is being put to effective use in a number of larger agile, software enterprises. It is often put in place between six months and a year after the team-level agile transformation. (That’s when the entropy and local optimization of all that team-level empowerment can become an impediment of its own).

As I’ve described, the loftier goals of the ART are to “align teams to a common mission” and “institutionalize product development flow.” What that translates to is “get all the teams pulling in the same direction and keep them there” and “implement development practices based on synchronization and cadence (uber-sprinting) that bring the same agile content management and continuous system integration discipline to the program as you have done with the teams”.

While conceptually, it’s not that complex a process, there are a number of misconceptions about the train that require clarification.

The first is the behavior implied by the name Agile Release Train. As illustrated in the Scaled Agile Framework Big Picture graphic below, development occurs on a fixed cadence of about 8-12 weeks (often 4 dev sprints plus a hardening sprint if applicable).

Each larger interval results in a product or full system release, or Potentially Shippable Increment. (Note: of course, our goal is to have  PSI’s every darn day, but in the larger program, that’s not a practical reality). Though the PSI cadence is highlighted, the intent is that teams are free to release software at any time the market demands it, or whenever it benefits the enterprise to do so. However, since the name is “Release Train”, and the cadence and the Scaled Agile Framework Graphic are overloaded, some assume that you can and must release only on the fixed time boundaries. That can create some unwarranted resistance to adoption of the train. Comments like “we can’t adopt ART because our customers don’t want releases that often” or “we can’t adopt the train because we have to release more often than the train cadence” are not uncommon.

But you can and should synchronize development. Since this is a common misunderstanding about the train, I typically use the graphic below to illustrate the conceptual firewall between development cadence and release cycles.

To summarize from the graphic:

1)   Development occurs in constant length intervals, each characterized by a plan-commit-execute-demo-retrospect model with forced asset synchronization at the two-week sprint cadence synch points.

but

2)   Any team, or the entire program,is free to release any product, component, or system to anyone whenever they want, subject only to the program/enterprises release quality and governance criteria.

In other words, Develop Synchronously, Release Whenever!

Next post: The Agile Release Train as an agile practice fractal above the teams.

Can Your Enterprise Be Leaner than Your Executives?

In my Agile 2001 presentation (Five Keys to Building the Lean|Agile Enterprise), one of the keys I described is the question/statement to the effect of whether or not your enterprise can be leaner than the thinking of those executives and managers who pilot the ship. Although I was rushed during the presentation time (my continuing scope management challenge), I received a few interesting questions on the topic, so I though I’d post that snippet here. It’s not quite self explanatory, but it gives you the gist of the idea along with a few suggestions for what you might be able to do about it.

Lean Thinking executives.pptx

Podcast: Building the Lean|Agile Enterprise

While I was thinking about my then-upcoming presentation entitled Five Keys to Building the Lean Agile Enterprise for Agile 2011, I was contacted by Joe Dager, owner of Business901, about doing a podcast on essentially the same topic. Joe did an excellent job of interviewing me and framing the discussion in pragmatic terms that are directly relevant to most every leader, manager and executive contemplating, or in the  midst of, a substantial Lean|Agile enterprise software transformation. A reader just pointed me to the podcast which is posted here. (The title, Lean Agile Software Train Description, is a little different, but the content is even broader than the Agile 2011 presentation.)

This is a pretty far ranging discussion, and on review, I thing it does a fair job of covering a number of critical topics, including:

➵Not Everything is a User Story: Scalable Agile Requirements
➵Think Agile Programs, Not Just Agile Teams: The Agile Release Train and Program Kickstart
➵Enterprise Systems Require Intentional Architecture: Rearchitecting with Flow
➵Portfolio Management Must be Agile Too: Addressing Legacy Mindsets and the Agile PMO
➵Your Enterprise Can Be No Leaner Than the Executives Thinking: Lean Education and The Big Picture

as well as a discussion of lessons learned in a number of larger scale transformations.

John Deere ISG Case Study: Reaching the Tipping Point

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/

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 http://www.scaledagiledelivery.com . 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: www.johndeere.com/careers/

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.

http://www.scaledagiledelivery.com/2011/07/01/how-to-track-customer-releases/

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.