Scaled Agile Framework Big Picture Update

The Scaled Agile Framework collaborators, (Colin, Drew, Matthew, Alex (via Skype) and I) had another JAD session here in Boulder over the last three days. As per our Roadmap and schedule, the website went live at (scaledagileframework.com). However, we’ve had to scope-manage our efforts quite a bit (seems as if we all have day jobs), and have now committed to getting the newly-defined abstract pages in place asap (but not the detail pages). The abstracts are complete now for the Team level; other levels to follow.

We’ll formally announce the Framework around the first of the year, we hope to get all the abstracts in place before then.

And of course, the big Picture evolved for the umpteenth time. Here is the latest:

Changes:

new logo and redesign, new icons
added the Release Train Engineer icon.
added a Shared resource icon. (just posted that abstract here)

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.

Scaled Agile Framework – Hardening Iteration?

Things done well and with care, exempt themselves from fear.
— William Shakespeare

The hardening iteration in the Big Picture (and as I’ve described at length in Agile Software Requirements) has always been a source of fear, comfort, concern, (sometimes even loathing), and occasionally, all of the above combined. Emails in the form of “that isn’t agile, teams will use it as an excuse to defer technical debt”, and “big-company dummy, don’t you know you should be shippable every day”, and “of course you have to have it, when else can you do the final field testing we can’t do in our environment” and “anyone who doesn’t think you need a hardening sprint has never worked on a really big software program” have found their ways into my inbox since the Big Picture was published. In any case, since the framework is nothing if not pragmatic, let’s consider the hardening sprint from three aspects.

Stuff you must do, and probably can do only in hardening
Stuff you should be doing earlier, but have to do in a hardening sprint for now
Stuff you absolutely should have done earlier, and for which you are using the hardening sprint as a waterfall crutch

Let’s look at each of these individually.

Stuff you can probably only do in hardening

In many environments, there are a number of things that must be done, and can only be done (efficiently) during hardening. To name five:

Final exploratory and field testing
Validate solution against release, quality, and standards governance, and any marketing/sales/deployment/operations requirements
Develop deployment, installation documents
Create release deployment package
Create release communications

In addition, in high assurance environments, you’ll probably also have to finalize and “sign” product requirements and software specifications, and also finalize traceability artifacts and other documentation of quality as required by regulatory requirements or internal Quality Management Systems.

Stuff you should be doing earlier

In addition, especially in the first year or so of transition to agile, the hardening sprint may be used legitimately for a number of other things. These may include:

Final cross-component integration and/or integration with third party or customer components
Final, integrated, system level testing
Final System Quality requirements testing (testing nonfunctional requirements (NFRs) such as performance, reliability, accuracy, load, scalability, etc.)
Finalize localization across all required languages
Finalize user documentation

Stuff you absolutely should have done earlier

And finally (and hopefully only for those just transitioning to agile) , five examples of some of the stuff “you know better than to defer to the hardening sprint (don’t you?).”

Final system integration
Elimination of P1, P2 defects that remain
Automate remaining manual test scripts
Deferred regression testing
Update user documentation

Hardening Sprint Cadence and Summary

When it comes to cadence and length of the hardening sprints, while the Big Picture appears to indicate periodic hardening sprints just prior to program level PSI/release boundaries, the reality is a lot more flexible and (a little more complicated). But let’s state it clearly:

Agile Teams can place hardening sprints anywhere, if and when, they are needed.

So long as you are not “doing the stuff you should have done earlier,” and you are continually lightening the stuff in the “should be doing earlier” pile, then you are increasingly agile and on the right track.

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.

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…)

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.

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.

The Big Picture is now the Scaled Agile Framework

OK, additional feedback drives me to make yet-another-minor-change to the Big Picture (sorry!). I’ve renamed it (hopefully for the last time) to be the “Scaled Agile Framework” (SAF for short). I’ve also tweaked the product owner and scrum master icons for better graphic discrimination. The latest is below:

: Scaled Agile Framework Big Picture

Also, a number of us will be working to further elaborate this framework in web form over the next few months. If you are scaling agile in your enterprise, you might want to stay tuned to this blog for a while, as we’ll be pushing quite a bit more content out this fall.

Agile Portfolio Planning and Business Epic Kanban System Overview

My colleague and “agile ninja”, Chad Holdorf, has been working with agile at enterprise scale for some time now. He has adopted the Big Picture from my Agile Software Requirements book, which he describes as a “Scaled Agile Delivery Model” (I like that name a lot; I might even adopt it). Recently, he has been working at the portfolio levels of the enterprise to effect lean and agile thinking there too, and to provide a systematic way of moving projects from the portfolio (enterprise backlog) into development via a set of Agile Release Trains. He’s using the enterprise backlog model I described on my blog and the paradigm of the business epic kanban system , which I describe in Chapter 23 – Investment Themes, Epics and Portfolio Planning, of ASR. He has just published a short video/blog post that summarizes this system brilliantly. Check it out at: http://www.scaledagiledelivery.com/2011/04/22/agile-portfolio-planning/.

In addition, as agile tooling is a necessary condition for success at enterprise scale, he’s been collaborating with Catherine Connor at Rally (as have I) on the development of their new portfolio planning tool called “Stratus”. Here’s what Rally says about Stratus:

“Rally is previewing Project Stratus, a new application that elevates Agile planning and tracking to roadmap and portfolio levels. Based on collaboration with Rally customers, Project Stratus focuses at the PMO level on:

Keeping development aligned with strategic business priorities
Visualizing and managing projects and large features across the entire value stream
Analyzing the roadmap to optimize delivery of value while minimizing risk
Strengthening feedback loops between the PMO and development teams”

Now ideally, any method (with tooling) that really supported enterprise-level, agile portfolio planning would accomplish a number of objectives:

make the backlog of potential and current portfolio projects visible
provide wip limits so as to keep the full system in maximum productive flow
provide a persistent, single version of the truth in the enterprise (avoid dueling spreadsheets/tools)
provide visibility for how current development activities correlate to the enterprises current investment themes
provide a capacity-based, systematic way of driving new epics into development

I think you’ll see from Chad’s video, that this system has the potential to accomplish all these objectives.

One last comment: Great job Chad and Catherine! This is clearly “new knowledge” that can help most every agile enterprise.

The Agile Enterprise Big Picture Graphic (revised,again).

During the course of finalizing the Agile Software Requirements book, the Agile Enterprise Big Picture graphic has undergone some minor changes and has been revised for the umpteenth time. The blog series/category on the Big Picture is here, (but the book does a better job of describing it in a more systematic and incremental way).

Update: April 25, 2011:

I’ve even decided to change the name with a bit of “co-branding” (Thanks to Chad Holdorf at http://www.scaledagiledelivery.com)
The latest version of the graphic is below: