Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Scaled Agile Framework(aka SAFe)

Expand Messages
  • Dan Greening
    If you can get executives to consider agile principles for portfolio management, you can apply Enterprise Scrum to help create and maintain an agile culture.
    Message 1 of 27 , Oct 31, 2012
    • 0 Attachment
      If you can get executives to consider agile principles for portfolio management, you can apply Enterprise Scrum to help create and maintain an agile culture. This fractal extension of Scrum drives home the empirical and value-driven principles of Scrum to the top-levels of the organization. It was applied in Citrix and Tectronix to departments of about 500 developers. It works very well, but requires regular executive education and monitoring to work.

      Citrix drove its concept-to-cash cycle time from about 24 months (ugh) down to about 3 months, using Enterprise Scrum in conjunction with a broad Scrum training program for teams. During the same time, its market share increased and it released some pretty innovative products and features. Correlation does not imply causation, so your mileage may vary.

      See http://evolvebeyond.com/agile-2010-enterprise-scrum/ for a link to a paper and a slide deck on "Enterprise Scrum". I have another paper to be published in 2013 Hawaii International Conference on System Science on "Release Duration and Enterprise Agility". I can't yet make this public, but can share preprints privately on request.

      Dan Greening
      Managing Director, Evolve Beyond LLC
      Email: dgreening@..., Phone: +1 (415) 754-8311, Skypeid: drgreening, Site: http://evolvebeyond.com



      On Tue, Oct 30, 2012 at 9:47 PM, Kurt Häusler <kurt.haeusler@...> wrote:
      My previous company was looking into it. We sponsored an event with Dean, and had an internal workshop on the topic.

      I didn't like it much either. But it turns out you are not supposed to use the whole framework at once. It is apparently to be seen as a packet of different approaches you can pick and choose from to address aspects of "scaling agile". Particularly things that happen outside the normal sprint cycle. And most of them are probably things a good Scrum Master would suggest anyway as being useful in various situations. But in the end it is a compromise. It is for companies that ask questions like "how can we do agile software development with 6 year 300 person projects, synchronising everyones work to maximise utilisation, while not giving employees too much freedom to screw things up, and still giving our huge management structure something to do?".

      I am still not a huge fan because I ask questions like "how can we use agile as part of an approach to improve the company culture, how can we switch from huge risky projects to smaller, more focussed work with smaller teams, how can we give our employees as much freedom as possible".

      It is a hybrid approach for where the more extreme visions of how a truly agile company should work are hard to realise.

      But for a larger organisation wishing to get some benefit from agile software development without having to change to a completely different mindset it is probably a start.

      And for a consulting company it is undoubtably something that will sell to the richest of clients.


      On 30 Oct 2012, at 22:45, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:

      >
      > I think this might be considered by some to be off topic, but since it refers to Scrum (esp at the team level), and uses a lot of terminology similar to Scrum, I think it is on topic for this forum.
      >
      > Has anyone formed an opinion on the "Scaled Agile Framework" ?
      > http://scaledagileframework.com/
      >
      > They also have a certification program with 4 different certs:
      > http://www.scaledagileacademy.com/which-certification/
      >
      > It reminds me a lot of the RUP/Rational type processes, and seems quite heavy in weight, though maybe the target is extremely large companies that need(?) heavy weight processes.  It also "bakes in" hardening iterations -- something I don't like.   It introduces a lot of new terminology: Architectural Epic, Business Epic, Program Backlog, Portfolio Backlog, Team Backlog, System Team, etc.
      >
      > I first started hearing about the SAF at Agile2012, and have seen it and its courses advertised more recently.
      >
      > Anyway, if anyone has any experiences or opinions on this framework, I'd be interested in hearing them.
      >
      > -------
      > Charles Bradley
      > http://www.ScrumCrazy.com
      >
      >
      >



      ------------------------------------

      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

      <*> To visit your group on the web, go to:
          http://groups.yahoo.com/group/scrumdevelopment/

      <*> Your email settings:
          Individual Email | Traditional

      <*> To change settings online go to:
          http://groups.yahoo.com/group/scrumdevelopment/join
          (Yahoo! ID required)

      <*> To change settings via email:
          scrumdevelopment-digest@yahoogroups.com
          scrumdevelopment-fullfeatured@yahoogroups.com

      <*> To unsubscribe from this group, send an email to:
          scrumdevelopment-unsubscribe@yahoogroups.com

      <*> Your use of Yahoo! Groups is subject to:
          http://docs.yahoo.com/info/terms/


    • Jesse Houwing
      Isn t that kind of implicitly caught under people over process? Unless of course you re planning a party ;).
      Message 2 of 27 , Oct 31, 2012
      • 0 Attachment

        Isn't that kind of implicitly caught under people over process?

        Unless of course you're planning a party ;).

        On Oct 31, 2012 6:11 PM, "Adam Sroka" <adam.sroka@...> wrote:


        If I could, I would add another line to the Agile Manifesto that read: 

        "Being effective over employing a large number of people"

        Not that jobs are a bad thing, but bigger teams are consistently less effective in my experience, and process does not mitigate that. 

        On Tue, Oct 30, 2012 at 2:45 PM, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
         

        I think this might be considered by some to be off topic, but since it refers to Scrum (esp at the team level), and uses a lot of terminology similar to Scrum, I think it is on topic for this forum.

        Has anyone formed an opinion on the "Scaled Agile Framework" ?

        They also have a certification program with 4 different certs:
         
        It reminds me a lot of the RUP/Rational type processes, and seems quite heavy in weight, though maybe the target is extremely large companies that need(?) heavy weight processes.  It also "bakes in" hardening iterations -- something I don't like.   It introduces a lot of new terminology: Architectural Epic, Business Epic, Program Backlog, Portfolio Backlog, Team Backlog, System Team, etc.

        I first started hearing about the SAF at Agile2012, and have seen it and its courses advertised more recently.

        Anyway, if anyone has any experiences or opinions on this framework, I'd be interested in hearing them.

        -------
        Charles Bradley
        http://www.ScrumCrazy.com





      • Charles Bradley - Scrum Coach CSP CSM PSM
        Good points Mark L.  My sense though, is that SAFe will get a lot more play/inroads due to it s (relatively better)packaging and who it will be sold to.   
        Message 3 of 27 , Nov 1, 2012
        • 0 Attachment
          Good points Mark L.  My sense though, is that SAFe will get a lot more play/inroads due to it's (relatively better)packaging and who it will be sold to.   
           
          -------
          Charles Bradley
          http://www.ScrumCrazy.com




          From: Mark Levison <mark@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Wednesday, October 31, 2012 7:46 AM
          Subject: Re: [scrumdevelopment] Scaled Agile Framework(aka SAFe)



          Caveat - I think SAFe, Vodde and Larman's approach, Ken's ideas all have merit. In addition I think the question of scaling is less about the mechanics (i.e. how to do this) and far more about changing the cultures/mindset.

          On Wed, Oct 31, 2012 at 12:47 AM, Kurt Häusler <kurt.haeusler@...> wrote:
          My previous company was looking into it. We sponsored an event with Dean, and had an internal workshop on the topic.

          I didn't like it much either. But it turns out you are not supposed to use the whole framework at once. It is apparently to be seen as a packet of different approaches you can pick and choose from to address aspects of "scaling agile". Particularly things that happen outside the normal sprint cycle. And most of them are probably things a good Scrum Master would suggest anyway as being useful in various situations. But in the end it is a compromise. It is for companies that ask questions like "how can we do agile software development with 6 year 300 person projects, synchronising everyones work to maximise utilisation, while not giving employees too much freedom to screw things up, and still giving our huge management structure something to do?".

          In terms of tunable processes we've been down this road before. It was called RUP (Rational Unified Process). Well tuned RUP isn't entirely bad, however most organizations tend to treat RUP as buffet and so it gets tuned heavily.
           
          I am still not a huge fan because I ask questions like "how can we use agile as part of an approach to improve the company culture, how can we switch from huge risky projects to smaller, more focussed work with smaller teams, how can we give our employees as much freedom as possible".

          To my mind these are the right questions. Inside **many** large projects are several small ones screaming to get out.

          I wish Dean well, but am concerned that SAFe will misused to put Agile lipstick on existing poor processes.

          BTW Charles you owe me now :-)

          Cheers
          Mark Levison - human 




        • woynam
          Prior to the introduction of user stories, Ron, did you use any other formal requirements gathering/documenting approach? I m curious if you were using
          Message 4 of 27 , Nov 2, 2012
          • 0 Attachment
            Prior to the introduction of user stories, Ron, did you use any other formal requirements gathering/documenting approach?

            I'm curious if you were using something more heavyweight, and decided that it wasn't getting the job done, or were you using nothing at all, and felt that a bit of structure was needed?

            Did CRC Cards predate user stories, or were they influenced by user stories?

            Mark

            --- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
            >
            > Hi Mark,
            >
            > On Nov 1, 2012, at 5:15 PM, "woynam" <woyna@...> wrote:
            >
            > > Once again, I think user stories was a backlash against overly big use case documents.
            >
            >
            > User stories were invented in XP. They consist of a few words on a card, much conversation, and confirmation in the form of agreed acceptance tests.
            >
            > Alistair Cockburn (pronounced the Scottish way: Coburn), has said that a user story is a two-bit use case, meaning two bits of information rather than many more, and certainly with an ear to the pun.
            >
            > Ron Jeffries
            > www.XProgramming.com
            > If not now, when? -- Rabbi Hillel
            >
          • RonJeffries
            Hi Mark, ... At one point or another, I have done most everything. In view of frequent change, I never leaned much on a lot of formal documentation, as it was
            Message 5 of 27 , Nov 2, 2012
            • 0 Attachment
              Hi Mark,

              On Nov 2, 2012, at 10:04 AM, woynam <woyna@...> wrote:

              Prior to the introduction of user stories, Ron, did you use any other formal requirements gathering/documenting approach?

              At one point or another, I have done most everything. In view of
              frequent change, I never leaned much on a lot of formal documentation,
              as it was obviously a waste of time for what I was doing,

              I'm curious if you were using something more heavyweight, and decided that it wasn't getting the job done, or were you using nothing at all, and felt that a bit of structure was needed?

              Kent Beck introduced stories on C3, the first XP project. We don't
              have a clear recollection of where he got the idea. Their purpose was
              to lighten the weight of the process, simultaneously increasing
              communication. The prior attempts at the product had been unsuccessful
              and it was in large part due to disconnects between the contractor and
              the company, in his view as I recall it.

              Did CRC Cards predate user stories, or were they influenced by user stories?

              CRC cards predate user stories by rather a long time. Kent and Ward
              wrote the original CRC paper and had used CRC a lot, so the use of
              cards was surely part of Kent's style.

              Regards,

              Ron Jeffries
              If it is more than you need, it is waste. -- Andy Seidl

            Your message has been successfully submitted and would be delivered to recipients shortly.