Agile Iteration. Agile Release Train. Agile Fractal.

As I’ve described at length in Agile Software Requirements, Scaling Software Agility and this blog, the Agile Release Train can provide tremendous benefits to the larger agile software enterprise. I, and many others, routinely apply it to: 1)   Align agile teams to a common mission 2)   Institutionalize program-level, product development flow.

However, being a man of oft-too-many-words, I struggle sometimes to describe the Agile Release Train in the simplest possible terms. A while back, I mentioned the release train as a fractal above the sprint/iteration. (A fractal is a geometric shape that can be split into parts, each a reduced size copy of the whole). Maybe that’s the best way to think about the release train. Let’s try it.

There is no debate that an agile iteration/sprint has a common and simple pattern: 1. Plan. 2. Commit. 3. Execute. 4. Demo. 5. Adapt (retrospect). It looks like this: The release train has more teams and longer iterations (uber sprints, composed of multiple, aligned team sprints)  but the pattern is exactly the same, it’s just that it is at the next level of program scale. It looks like this:

Does that simplify things a bit?

Agile Software Requirements is Now Available in Native Kindle Format

Well, after more emails than I care to think about, and after being tempted to give up on the entire concept, Agile Software Requirements: Lean Requirements Practices for Team, Programs, and the Enterprise is now (again) available in native Kindle format from Amazon.

Order native Kindle format from Amazon

Thanks to Chris Guzikowski, the Addison-Wesley team and Amazon for finally making this happen.

Of course, it is also available in Ebook format from InformIT.

 

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

Expanded Services Offering

As I’ve noted on this blog before, I often provide enterprise-level training and consulting services to the larger software enterprise. But since they are big enterprises, training and consulting has to be scaled as well, so I always work with others, too. Recently, I’ve added two partners to my team, Mauricio Zamora and Alex Yakyma. We’ve described some of our packaged service offerings  here.

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.