Rob Pinna and I go way (and I mean way, way) back. I was interesed to see his perspective on the Scaled Agile Framework that he just published in a recent blog post. I thought he did a pretty good job of summarizing, but you can judge for yourself here.

We were working at the Team Level, where we had some early, older descriptions, prior to the fuller evolution of SAFe. On review, this caused us to capitulate to the need to create a new, and more expressive, SAFe ScrumXP graphic (which we euphemistically call the “Little Picture”), which describes activities and artifacts at the team level, and which appears in the Figure below.

This graphic also communicates some upcoming BP release 2.5 artifacts, including separate Team and Program PSI objectives, the Quality Icon, and a new representation of the teams backlog (as it is identified during Release Planning). This new graphic will play a significant role in SAFe proper, as well as Scaled Agile’s Leading SAFe and SAFe Scrum XP courseware.

Then, based in part on the broader context we communicate in this graphic, we rewrote, or at least significantly updated, SIX articles:

• Team Backlog. Now with the new graphic, better illustrating the program’s (ART) context
• Iterations. Now including estimating, velocity, and normalized story point estimating.
• Team Planning, Team Demo, Team Retro and System Demo

Honestly, we had hoped to work further on the next release in the past two weeks, but sometimes you have to take the time to stabilize your code base before you put additional weight on it. Otherwise you can’t really scale.

I admit to having some frustrations with the amount of rework we felt compelled to do, and it must have been obvious to those around me, for when I came into my office the next day, the following sticky was on my door.

(Thanks Alex!)

You can see some of the new BP 2.5 content published in the most recent posts of Value Stream, Business Owners, and Sprint Goals.

On our SAFe product backlog has been the need to change the D|B|T Icon to a Q and relabel it “Code Quality”, and to then redo the navs etc. from the odd little subdomain we created under D|B|T. We’ve done that now, and the current DBT icon now navigates to a better summary and new description of what we mean by Code Quality. As you all know, you can’t scale crappy code, so we think that this will be an area of ongoing emphasis in SAFe. Not only do we feel the need to further detail some of the XP practices, but Agile architecture, Agile Modeling, Acceptance Test-Driven Development, and Test Automation are also moving us all forward, so we’ll provide some additional content there as well.

With this addition, we have clarified the three recommended formats for system description (requirements) as follows:

User Stories: User voice form: As a 〈user role〉 I can 〈activity〉 so that 〈business value〉

Features: Features and Benefits Matrix

Epics: Epic Value Statement format

In this way, SAFe provides some visual and conceptual entropy between these like, and yet unlike, most important abstractions we use to describe what value we are delivering to the enterprise and its customers.

In our SPC and SA trainings however, we always introduce the larger topic of understanding and analyzing the enterprises value streams (each of which is a long-lived series of system definition, development and deployment process steps used to build and deploy systems that provide a continuous flow of value to the business, customer or end user). As we are currently working on the development of the next release of SAFe and a new Big Picture, we have been incorporating value streams as first class citizens of the model, as you can see illustrated in the draft graphic.

In the meantime, we have just posted a new guidance article on Value Streams, so that you don’t have to wait for the next release to get this increment of value. That’s part of our commitment to delivering value incrementally, and illustrates yet again, that if you want to deliver value incrementally, you need an architecture which supports that purpose!

In Part 5, Mark summarizes some key findings, and most importantly publishes some quantitative results. After all, in the end, that’s all we really care about. In order not to keep you in suspense, here’s the high level summary of business benefits:

• Average delivery cycle time down from 12 months to 3 months
• Frequency of delivery increased from quarterly to fortnightly
• Cost to deliver down 50%
• 100% of projects delivered on time and on budget
• Happy project sponsors (NPS 29)
• Happy teams (Team NPS 43)

Wow! And those are great Net Promoter scores.

Yeah, implementing SAFe is hard, but it’s always good to be reminded of why we do it. Thanks Mark!

It’s actually a webinar in two parts. On Wednesday, May 22 at 12 noon EDT, VersionOne will be describing how their product specifically supports SAFe, with particular focus on the Program execution and Portfolio planning.

This two-part series should provide the guidance you need to help successfully deploy SAFe and tool it with VersionOne. You can register here:  http://pm.versionone.com/AgileLIVE-SAFe2.html

In this post, Mark focuses on the practices they put in place to track features as they move through sprints and onto delivery.  He highlights what is essentially a logical, and always-current, extension of the Program Board that is typically developed during Release Planning. Though supported by more in-depth tooling with Rally, this board is the primary visual tracking and communication mechanism fro tracking features as they move form the backlog, into the sprints, an on to delivery.

(Important Note: in this case study, they don’t actually time box the work into PSIs; it’s a more continuous, rolling-wave look at about the next 10 weeks of work. It has some advantages over PSI planning, in that its more continuous flow and features don’t have to be forced to be split into PSI cycles, simply it’s a more Continuous Delivery (or at least continuous development flow) model. But it has some significant disadvantages and some restricted contexts too, many of which are compensated for with alternative cadence and synchronization practices as Mark describes in Post 3.)

In this fourth post, Mark describes the Feature board and how some of the other SAFe practices are implemented without the PSI construct, including

• Visualization
• Communication
• Cadence
• Continuous Improvement

It’s an interesting post, and more importantly, a real in-depth case study, which highlights some implementation exceptions to SAFe as we describe it, but it works because it still follows the underlying lean and agile practices that SAFe is based on, illustrating, yet again, that the right principles trump practices every time.

And, of course, you can expect to hear more from us about Continuous Delivery in the near future. (But that doesn’t necessarily mean the end of PSIs….)

In the context of SAFe however, there is no such option, as sprint goals are an essential part of maintaining alignment, transparency and program execution, three of the four Core Values of SAFe. In addition, sprint goals provide a simple protocol for communication with management, (which can even be automated via simple tooling). This helps keeps management informed, thereby empowering both management and the teams to go on about their business without unnecessary reporting, status checking or communication overhead.

In the next release of the Big Picture (V2.5; likely in April or May), sprint goals will appear as first class citizens (icons) on the Big Picture. But for now, we have developed this Sprint Goals Guidance article so teams and programs can see how to use sprint goals more effectively and thereby achieve better program outcomes.