Add to Google
Scaled Agile Framework Big Picture Update
Posted on October 21, 2011 by Dean Leffingwell in Scaled Agile Framework/Big PictureWhile 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…)
Hi Dean,
Catching up a bit on your work and hope to run into you soon again at an LSSC conference or Agile Denver. I like your big picture and it makes sense to me overall. I’m assuming though there is nothing precluding using what I know more as flow based methods in the lower levels.
Take care,
Frank
Hi Frank,
Depends on what you mean by flow.
The Agile Release Train is all about flow at the program level. Short backlogs, limited WIP, decentralized decision planning and decision making, time boxed development, concurrent testing, forced system integration for fast feedback, etc.
At the team level, about 95% of the teams I work with use Scrum, either because they rolled it out ahead of, or with, the train. About half of those of those use solid technical practices (mostly XP serviced) as well. Far few use kanban techniques, but it wouldn’t matter to the Program, so long as those teams participate in planning, and can make commitments to deliverables that others need on a synchronized basis.
Hi Dean,
Thanks for the reply. Yes, I think we’re talking about the same “flow” at the program level. In short, I agree with everything you said (especially re: solid technical practices). My personal experience, while small and not as broad, still suggests it is worth sharing with others here that applying principles of flow at the lower team level as well in your model (diagram) is not precluded. In fact, in some contexts it may help address challenges in meeting planned deliverables and better understand their overall workflow (variations, what is expected); I believe it did in my earlier experience where we used a portfolio approach adapted/influenced very much by your work.
Again, thanks, and I hope to catch up with you again soon in Denver or another conference. I definitely refer others to your work often.
Take care,
Frank