Introducing the Scaled Agile Framework™

Over the last few years, I’ve worked extensively with a number of other professionals (including Drew Jemilo, Colin O’Neill, Alex Yakyma, Mauricio Zamora) in the implementation of a number of large enterprise lean|agile transformations. This collaboration has resulted in many back and forth discussions around implementation of the Scaled Agile Framework™. To date, this framework has been elaborated primarily in my books Agile Software Requirements, Scaling Software Agility, and blog).

Recently, we decided to formalize our collaboration with the intent of making the framework public-facing and more readily available to a larger audience, and we have also committed to developing certain extensions and enhancements to the framework that have presented themselves as the marketplace, agile enterprise maturity, and our thinking and experiences have evolved. To that end, we will offer the Scaled Agile Framework (SAF) as a “proven, publicly available, framework for applying Lean|Agile practices at enterprise scale, presented in a structured, interactive, web format.”

I am extremely happy to announce that this initiative has been formalized and we are now “in development!” Over the last 3 days, Drew, Colin, Mauricio, and Alex have been camped out with me here in Boulder, Colorado, USA for our first Release Planning session (see Alex’s fun post on the topic).

SAF Collaborators - (from left to right) Colin O’Neill, Alex Yakyma, Dean Leffingwell, Drew Jemilo, Mauricio Zamora, in front of the Flatirons, Boulder, Colorado, October 21, 2011.

One of our first orders of business was to establish our identity as a group (About Us), agree on a common purpose (Our Purpose), determine the position statement (Product Position Statement) for the framework, and define a Roadmap for the first few releases. We accomplished these objectives in our first face-to-face sprint; the results are highlighted below and more information can be found at scaledagileframework.com. For now, the website is just an “Anticipate” landing page with a few auxiliary pages. The roadmap posted there illustrates that the first planned public release will be December 21, 2011. (As agilists, we will, of course, make that date).

Feel free to subscribe on the Scaled Agile Framework site (or here) and watch the work in process unfold over the next few months.

And of course, comments are always welcome.

Regards,

— Dean

–Dean Leffingwell
Chief Methodologist, SAF Framework

— Mauricio, Drew, Colin, and Alex
Principal Contributors, SAF Framework

===========================================================================

Purpose

Through our collaboration, we hope the Scaled Agile Framework (SAF, pronounced “safe”) will:

  • Enhance the competitiveness, productivity, and delivered quality of the software industry worldwide
  • Help provide the business benefits of software agility to all software enterprises
  • Increase motivation, empowerment, and humanity to software development practitioners everywhere

And we surely hope to build good business value along the way!

 Scaled Agile Framework Position Statement

FOR software developers, practitioners, managers, executives, coaches, consultants, trainers, and agile working group team members

WHO are involved in planning and implementing Agile software development philosophies, principles, and practices at enterprise scale

The Scaled Agile Framework (SAF) is a proven, publicly available, framework for applying Lean|Agile practices at enterprise scale, presented in a structured and interactive web format.

UNLIKE proprietary methods promoted by product and consulting firms, or practices described in dozens of books

SAF is a synthesized, holistic, integrated, and summarized framework available to everyone in a readily accessible public-facing web site, including supporting resources.

Advertisements

Scaled Agile Framework Big Picture Update

While meeting with my co-conspirators over the last few weeks (Drew, Alex, Colin, Mo….more on that later), we made some revisions to the Big Picture graphic. (Note: updated again Nov 4, 2011).

The new version is below (“V23”). (It’s actually about 100, but who’s counting; well, I am now).

Version 23 of the Big Picture

Changes include:

1) the Agile Release Train was always assumed at the Program level, but never specifically highlighted; it is now!

2) we’ve added a new Icon to stand for “Inspect and Adapt”, which is the program level demo, review, and problem solving workshop we recommend to be conducted at PSI borders. We’ll be adding content guidance for that level of demo/retro at some point.

3) we’ve tightened the “story to task breakout callout” by eliminating the old “1 to many” arrows, as they just took some visual attention, but didn’t provide sufficient value for their space allocation.

4) we’ve provided more specific callouts for iteration level Plan, Demo and Retro (was just Demo and retro)

5) an assortment of minor alignment and style issues

6) added a version number to the lower left corner (Should have done the about 100 revs ago…)

John Deere ISG Case Study Post #3: All Aboard the GreenStar™ Release Train

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/

New Scaled Agile Framework Big Picture Technical Practices Icon

We’ve just updated the Scaled Agile Framework Big Picture to include the following new icon:

Define Build Test Agile Technical Practices Icon

The latest version of the Big Picture now appears as follows:

Latest Version of the Scaled Agile Framework Big Picture

This icon is intended to represent the agile technical practices and related software engineering skills that each Define/Build/Test agile team must master to drive the code quality to the highest possible levels. (higher quality=higher end user satisfaction and higher overall velocity).

I’ve assumed these practices in general in Scaling Software Agility and Agile Software Requirements. In SSA, I focused chapters specifically on the big two- Continuous Integration and Concurrent Testing (TDD and ATDD was a bridge to far when I wrote SSA). I refer you to that work for my discussion on the criticality of these practices in scaling agile. (If you try to scale crap, you just get a bigger pile of crap).

As I’ve described, most of the basic, team-level agile project organizational and project management practices that I have described in the framework were brought to us by Scrum. After all, Scrum has largely won the market wars for team-level agile adoption at present. (And that’s for good reason; it’s simple (on the surface) and it really works. I’m a huge fan of Scrum.)

However, most of these more technical agile software engineering practices were introduced, or at least better codified, within XP. The figure below highlights these.

I don’t see as much initial XP rollout in the market as I did 3-4 years ago; and dang, that’s too bad, because if the team doesn’t substantially improve code quality, then they can’t be very agile and the programs and enterprises won’t be very agile either. (But I do see an increased focus on these practices as a second phase rollout in the more experienced Scrum shops. Spontaneous pairing abounds!)

I’ve added this icon, in part,  because one of my colleagues, Alex Yakyma, (www.yakyma.com) has committed to blogging on some of these practices, as he spends a lot of time with developers in the enterprise setting.

As that content becomes available, I’ll post it here. In addition, as I mentioned before, a few of us (announcement forthcoming) are also committed to building a lightweight, interactive web site for the Scaled Agile Framework that will aggregate a practice overview in one navigable format, all based on the Big Picture.

I’ll announce it when there is something useful to announce, probably in the November time frame.

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: