My London SPC (SAFe Program Consultant) certification class in October is sold out, but there is one more class available this year in Europe. That is the Tallinn, Estonia class, held in conjunction with Topconf:
“Topconf Tallinn is a premier software conference designed for Developers, Product owners / managers, Architects, Project Managers, Methods- and Process-Experts.”
This will be a contiguous, accelerated 3-day SPC certification to be held on Nov 4-6. You can register here:
Hope to see you in Tallinn!
It’s not to late to register for the upcoming Lean Systems Society Reactor conference in Boulder, Colorado Sep 11-12. The Lean Systems Society is an initiative I feel strongly about. This is simply group of people whose interest is in helping industry, government and society at large better build large and complex systems based on the principles of Lean thinking. They have no commercial or propriety agenda.
From the conference website:
Who’s Invited: Everyone who considers themselves part of the Lean Systems community. We are also actively seeking C-level and director level personnel of large organizations to bring their point of view and to be exposed to a wide variety of Lean and Systems-Thinking perspectives. We are keeping the costs very low so offer no early-enrollment discount (it’s already built in), but ask for everyone who can register early to do so, to help the LSS with mitigating its risks on the conference.
The Lean Systems Society (LSS), or “the Society” for short, is a non-profit organization whose purpose is to improve the world by improving its systems. The Credo of the Society further describes this purpose. Our community nurtures and applies many forms of systems thinking in numerous domains and across five continents. The Lean paradigm, with its cognition-driven “people-first” worldview, remains at its core.
I had the opportunity to do a webinar for Cisco that focused on addressing the complexity of building enterprise-class software systems, and how SAFe addressed some of that complexity.
I know that many of you have these challenges, and this is an interesting perspective on SAFe, so I’m providing it here as well.
Here is my near term schedule for SAFe certification and public speaking events:
- June 10-11 & 13 , SAFe Certification in Berlin (Sold Out)
- June 12: Keynote: Berlin ScrumDay Keynote 1:00 PM June 12. (http://www.scrum-day.de)
- June 15: Keynote: DARE conference in Antwerp, Belgium
- July 10: Keynote: Scaling Agile Leadership Summit in Atlanta with Rally Software
- July 30-Aug 2: SAFe SPC Certification in Boulder, CO (seats available)
- August 6, (2 PM) Talk: Agile 2013 in Nashville. Be Agile. Scale Up. Stay Lean. (I’ll be at the conference most of that week)
- September 24-27, 2013: SAFe SPC Certification with Al Shalloway in Seattle, WA. (seats available)
- October 7-8&11: SAFe SPC Certification in London, UK. (event not yet open for registration)
- October 10: Keynote: Agile Business London
- November 4-5&8: SAFe SPC Certification in Tallin, Estonia
- November 11: Keynote: Helsinki Agile Conference (event not yet open)
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.
Our colleague and SPC, Mark Richards from Australia has just concluded his case study of SAFe adoption at a large IT shop down under, now with Part 5: Conclusion. (for more on this and other case studies, check out Case Studies on SAFe).
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!
I’ll be guest hosting an upcoming free SAFe webinar “Accelerating Enterprise Agile Adoption with the Scaled Agile Framework®” with VersionOne on May 13 at 12 noon EDT. I’ll provide a general overview of the features and benefits of the Scaled Agile Framework, and how you can apply it to accelerate value delivery in all of your most important value streams.
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
Our 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 4: In-play Work and the Program Level Feature Wall. (for more on this and other case studies, check out Case Studies on SAFe).
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 on the program.
(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 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
- 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.