Introducing DevOps in SAFe

Posted by:

It’s no surprise that the topic of DevOps and the goal of continuous deployment (CD) is of significant interest to the SAFe community. Indeed, at one point, we were going to make a hard shift to describe how CD is starting to work (even in the non-SaaS enterprises where it has been largely pioneered). That will require some expansion of SAFe scope, as deployment increasingly becomes a development concern.

However, it’s also been clear from feedback that many to most SAFe users aren’t SaaS companies, and even for many who are, the move to ever-more-rapid deployment is a process that will happen in steady increments over a substantial period of time. Plus, it’s not like we have solved all the challenges of agile development at scale anyway, and we need to manage the scope and focus of SAFe as well. To that end, we have started this process by configuring SAFe 2.5 with a new icon/team/practice guide in guidance called DevOps, which provides the entry point and initial guidance for this longer-term evolution.

Today, we are announcing the release of the first version of DevOps. Since we are in development of 2.5 and simultaneously supporting 2.1, it is posted on both the guidance pages, and is also linked directly from the icon on the new BP in the SAFe 2.5 staging area.

4

Discussion

  1. Michael Vax  June 27, 2013

    Hi,
    A company that practices a continuous deployment should have mature agile process to support rapid releases.
    In such environment, what value is added by 3 month trains suggested by SAFe?
    Thank you,
    Michael

    (reply)
    • DeanLeffingwell  June 27, 2013

      Michael,
      As per scaledagileframework.com/BP25, the main message is to Develop on Cadence, Deliver on Demand. If a company’s agile processes or dev/release environment supports rapid fire delivery, (like many SaaS companies) then the PSI Cadence is a planning cadence, intended to coordinate multiple, future releases, an opportunity for program level inspect and adapt to address program level problems, and more. For most large enterprises with big traditional systems (infrastructure applications, embedded systems, telecommunication systems etc) rapid fire delivery may not be the appropriate goal,(no one wants to download new software every day to a running combine during harvest season; nor for example, to implement a new applications management system in an environment of 1,000 servers and 400 deployed applications, even every week) then the PSI cadence can also take on a release cadence, which, by historical standards, may be 3-6X faster than prior practices.

      In either case the PSI represents a strategic quantum of time box and value. Time to assess, measure, take improvements actions, adjust resources to the evolving budgets, and even celebrate the larger accomplishments where appropriate.

      And 8-10 week PSI cycles are not release trains. release trains represent continuos flow, with the sprint and pSI cadence being the heartbeat of the larger systems process.

      (reply)
  2. Jessica Katz  July 8, 2013

    Can you please elaborate on the difference between the DevOps team and the System teams?

    (reply)
  3. Gary Hathaway  December 13, 2013

    For DevOps, I view the entire end to end flow as being impacted. Operations will have their own requirements/needs to be able to implement new technology as well as being able to implement any experiments that will test out any hypothesis that a business would want to disprove. As fast as technology disrupts, operations will need to be right in the loop early. do you see an Operations backlog and/or runway being added to the SAFe or would you put that in architecture?

    (reply)

Add a Comment

XSLT by CarLake