Mark RichardsOur colleague and SPC Mark Richards from Australia has been continuing his excellent case study of SAFe adoption at a large IT shop, now with Part 3. Program Level Pipeline Management and the Program Kanban. In this post, Mark describes the use of a Visual Kanban system at the Program Level (for a discussion of the Portfolio Kanban example, see Part 2 of the series.) used to track the flow of value and initiatives through the Release Train. Though SAFe doesn’t call out a separate Kanban system there, it can sure make sense for better visualization and status tracking of Epics as they get broken down into Features and are implemented by the ART.

This (eventually) five part case study is loaded with practical tips and extensions (and some exceptions) to SAFe. It’s the deepest and broadest written case study we have to date of the real world challenges and successes enterprises can achieve with the framework. Perhaps Mark will stitch it into a SAFe Guidance article for us someday, but in the meantime, I thought I’d summarize the links here for easier reading.

Part 1: Scaled Agile Framework Applied 1/5- Introduction and Context

Part 2: Scaled Agile Framework Applied 2/5 – Demand Management and the Portfolio Kanban

Part 3: Scaled Agile Framework 3/5 – Program Level Pipeline Management and the Program Kanban

Thanks Mark!

Case Study Miniseries Part 2: Scaled Agile Framework Applied – Demand Management and Portfolio Kanban

Here is the next detailed, extremely illustrative post on that mini-series case study from SPC Mark Richards in Australia. This one covers the setup and use of a visual kanban system (you can actually see through this one) for portfolio management.

Check it out at

Thanks Mark. Well done!


New Case Study Blog Miniseries

My colleague Mark Richards, an SPC in Australia, is starting a blog series documenting his efforts, challenges, and successes in a multi-instance SAFe rollout at a really large software/IT shop in Australia, (who shall remain unnamed for now.)

Here are his comments and the first link.

” I have decided to write a blog series on how the implementation works with the group I’ve been guiding. Only have the intro/context post up so far, but since we’re dealing with many similar problems thought I’d share the starting post with you so you’re on the journey.”    – Mark Richards

Since solid, documented evidence of SAFe rollout at scale is hard to gain in “publishable” format, I’ll try to keep you posted as Mark continues his journey and blog.

Thanks Mark!

SPC Certification Classes Now Available in Q1 and Q2


We’ve just opened up a few new SPC Certification and Training classes for spring. The Feb 5 class in Boulder is sold out, but:

  • Drew and Colin will be doing a certification in Silicon Valley 12-15 March, 2013. Register here:
  • My next class will be in Zurich  at GOTO Zurich,  8-9 April  (Leading SAFe) and 12 April (Implementing and Certification). You can register here. (note: select the three days of training option and then my class  will pop up). I’ll also be doing a keynote on SAFe on April 10.
  • After that, the next class I’ll be delivering will be in Boulder again, 14-17 May, 2013. Register here.
  • After that, I’ll be in Berlin 10-13 June as part of the annual ScrumDays conference. The conference isn’t open yet, but you can pre-register here:

We are in the process of scheduling classes in other regional locations throughout the US this year, but we aren’t opening any of them them until we secure the venue. For planning purposes, we are aiming at something like this:

  • Washington, DC: 16-19 Apr
  • Los Angeles: 18-21 June
  • Boston 9-12 July
  • Atlanta 17-20 Sep
  • Chicago 22-25 Oct
  • Boulder 16-19 Dec (I’ll be doing this one)

But again, none of these latter  classes are certain until we can book the venue. They will be posted here as they become available.

Chapter 2 of Agile Software Requirements Now in German

Chapter 2 of Agile Software Requirements is now available in German, and on-line at: Thanks to Hans-Peter Korn and Symposion Publishing for this fine effort, and for making it available to all.


Registration for Zurich 2012 SAFe SPC Certification is now open

In cooperation with GoTo Zurich 2013, I’ll be delivering a SAFe Program Consultant (SPC) training and certification workshop in Zurich April 8-9,12, 2013. April 8-9 will be the 2-day Leading the Lean|Agile Enterprise with the Scaled Agile Framework workshop. April 12 will be a special 1 -day SPC certification workshop. Due to the compressed schedule, (normally 2-days including the exam), attendees will take the SPC certification exam on-line the week following the workshop.

GOTO Zurich is April 10-11 and I’ll be delivering a keynote sometime during that time. Registration for the conference and SAFe training and certification is open here:

Upcoming SAFe Program Consultant (SPC) Certification Schedule

Just a quick note regarding the upcoming SAFe Program Consultant (SPC) certification schedule. The latest schedule and registration for future events is now hosted on our new SPC membership platform here. You will note that:

  • December 17-20 Boulder class is Sold Out.
  • February 5-8 Boulder. The next available class will also be held in Boulder on February 5-8. Registration for that class is now open here.
  • April 8,9-12 Zurich. This one will be held in cooperation with GOTO Zurich 2013, which is April 10-11. I’ll be giving a keynote at the conference. Registration for the workshop is not yet open.
  • May 14-17, Boulder again. Registration is not yet open.
  • June 10-11, 13. Berlin.  This one will be held in cooperation with Scrum Days 2013, where I will be giving a keynote, though the dates are not finalized.

Also, if you would like to reserve a spot for a session that isn’t yet open, and be notified when it is, email Lynn Watkins <> and she’ll ping you as soon as registration is available.

New Scaled Agile Framework Big Picture 2.0

For anyone who has been following the completion of the Portfolio and Program Level details of the Scaled Agile Framework , you will have noted that we have significantly restructured those areas (mostly the Portfolio) based on both observed and recommended practices. You can see these changes in a number of new Details, including Program Backlog, Portfolio Backlog, Investment Themes and Portfolio Vision. You will also note that we’ve moved the primary focus on Architectural Runway to the Program Level.  The discussion of which was always there, but it appeared  at the Portfolio Level, mostly because I couldn’t figure out how to physically place it in the Program Level. Turns out, all I needed was a real graphic designer and a re-conceptualization/brainstorming process. (thanks Alex and Regina).

Given the magnitude of the change, we’ve been working hard behind the scenes to create a new Big Picture that far better reflects the way the flow of strategy, invetsment themes, and portfolio backlog drive the programs. Now you have it!

It will take some time for the additional refactoring necessary to change the remaining Nav icons, some places where older BP images are included in the details, and probably  a few places where the language is no longer completely consistent.

But there is a far bigger impact on the Training and Certification courseware and SPC  materials, so that is the current priority, especially as I have a class in London next week! Dang these big changes anyway. Oh well, Kaizen!

Refactor Details on the Scaled Agile Framework

Alex Yakyma has been working hard on the Detailed Page for Refactors, which we just published on the Scaled Agile Framework. While this may not seem like a major concern at the Portfolio and Program levels, it sure is a major area of interest and investment for the Teams. and thereby the other levels as well. After all, without Big Up Front Design (which never really got the job done anyway), it’s the teams continuous refactoring of the code base that provides responsiveness to change, endemic quality and increases system longevity. In this article, Alex describes refactor sources, specifying and estimating, splitting, acceptance criteria and demonstrability. Have a look and thanks Alex!

Quick Thoughts on Applying Agile In Fixed-Everything Projects

A number of our clients (well, most of them in one aspect or another) are struggling with the business aspect of how to do agile development when their customers want/need/mandate fixed requirements, fixed cost, fixed schedule ((Fixed Everything (FE)) programs. Of course, if we had a magic agile wand, we’d make that problem go away, but I evidently misplaced  mine someplace.

In the meantime, here’s a  few quick thoughts on the topic that I sent off to one of them just this morning.

“WRT to doing agile in Fixed Everything (fixed-price, fixed requirements, fixed schedule) programs, we know the challenges there. But we all live in the real world. So here are a few tips.
1) Fortunately, Agile teams are better at estimating than non-agile teams, because they have agile work physics and history.  Get the teams and programs agile asap so they know how to break big things (Epics) into smaller ones (Fetaures and then Stories)  and estimate using story points.
2) Base d on current work, the teams and agile release trains will soon know their velocities
3) Some Big Up Front Design (including requirements analysis) is required to come up with a cost and schedule estimate for the FE project. (Yeah, agile teams don’t like to do that, but not everything that can be valuable in life is necessarily something we like to do). Give yourself some guard band (buffer) of course, before you customer freezes it all.
4) Thereafter, once a decision is made as to how much of your existing capacity you can allocate to the new FE project, you can quickly estimate know how long it would take to do XXX story points.
5) However, DO NOT let the fact that you have all the requirements theoretically identified lull your team into batching them all into on giant development effort. In other words, don’t let the FE requirement make you think it’s waterfall development. It isn’t, it’s agile development with an unfortunately fixed objective. Those are two very different things.
6) Use the teams new found technical and agile skills to deliver high quality software in two week sprints and 10 week PSI increments.
7) Insist on customer feedback. Yes, customers do have the right to ask for Fixed Everything, at least in some circumstances (those where they have all the money and all your best agile words haven’t yet tipped them….) , but they do not have the right to go away and not participate as key stakeholders in the development process. If they do, outcomes will be ugly for certain and they don’t want that any more than you do.
8) Then, take small batches from the FE requirements backlog and work them through the system quickly, focusing on the most valuable and riskiest areas first (use WSJF). Build and deliver (or at least insist on feedback) incrementally.
9) Then let the chips fall where they may.
At least you’ll still be an agile development shop, delivering high quality software, incrementally. And that’s all you and your teams can really control. Plus, with this model, by the time you get to the end, there is about a 90% chance that the customer’s target will have moved, and you will have moved along with it. Yes, there will likely be some contract cleanup to work out along the way, but that’s usually far easier with happy customers than unhappy ones.”
Categories: Tin Tức

Leave a Reply

Your email address will not be published. Required fields are marked *