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 




        • Charles Bradley - Scrum Coach CSP CSM PSM
          ... bandwagon without investing the time and money on trying to custom fit it to their real needs. This has been a problem in the industry as long as I ve been
          Message 4 of 27 , Nov 1, 2012
          • 0 Attachment
            > I guess too many pointy-hair types were simply trying to jump on the
            bandwagon without investing the time and money on trying to custom fit it to their real needs.

            This has been a problem in the industry as long as I've been in it (~15 years).  Programmers don't like process(or requirements detailing), and companies don't value these skills enough to invest in process education (hire process experts, training, coaching, etc). 

            I did RUP for a few years, and the teams I was on did it pretty well.  Of the roughly 85 artifacts at the time, we generally got by with a handful or so.

            I'm pretty well convinced that, for the vast majority of the industry, in order to produce software efficiently, they need "process shepherds."  The Scrum Master is one implementation of this(and a step in the right direction IMO), but there are other ways of fulfilling the "process shepherd" pattern/role.  I'm also pretty well convinced that the no team can really *be* Agile unless they have regular and continued access to an Agile process shepherd.  I'm not saying it need be a dedicated full time position in all cases, only that some one or some individuals spend a lot of time "shepherding" effectively.

            If RUP had that kind of process shepherd role as a requirement, I think it would have succeeded more. If RUP had credible certifications like we have in the Scrum world, I think it would have succeeded more.  Having said that, at this time I couldn't care less about RUP.  :-)

            Full circle back to SAFe, and it seems they have learned some lessons from RUP and the Scrum movement wrt packaging, education and certifications.
             
            -------
            Charles Bradley
            http://www.ScrumCrazy.com




            From: woynam <woyna@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Wednesday, October 31, 2012 9:17 AM
            Subject: [scrumdevelopment] Re: Scaled Agile Framework(aka SAFe)


            If some process is good, then more process has to be better, right? ;-)

            Seriously, I was shocked when I talked to people that more-or-less tried to implement RUP right out of the box. We had reasonable success with a very lightweight version, but once you go that far, it's fairly easy to keep going and simply embrace agile.

            I thought it was quite clear that RUP needed to be tailored, but I guess too many pointy-hair types were simply trying to jump on the bandwagon without investing the time and money on trying to custom fit it to their real needs.

            Mark

            --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@...> wrote:
            >
            > On Wed, Oct 31, 2012 at 10:31 AM, woynam <woyna@...> wrote:
            >
            > > **
            > >
            > >
            > >
            > > That's funny, I thought that the biggest problem with RUP is that most
            > > organizations failed to realize that it was a process framework that
            > > *required* tailoring. Instead, they tried to implement RUP in its full
            > > "glory", and would up with a overweight cow.
            > >
            >
            > I think we meant the same thing. It tends be to be far heavier than it
            > needs.
            >
            > Cheers
            > Mark - who finds himself agreeing with Mark.
            >




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

            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/



          • woynam
            In RUP, the process engineer role is responsible for the development of the development case , which specifies the tailoring of RUP performed by the
            Message 5 of 27 , Nov 1, 2012
            • 0 Attachment
              In RUP, the process engineer role is responsible for the development of the "development case", which specifies the tailoring of RUP performed by the organization. An organization could elect to implement the whole framework, or modify it to suit their specific needs.

              To perform the role of process engineer, one would expect the person to have detailed knowledge of RUP, the organization, and software development in general. As such, I would expect this person(s) to be the "shepherd".

              It's quite obvious that the RUP community did not make it clear that success started with a knowledgeable process engineer. If the framework was not suitably tailored, it would likely wind up too big. In my conversations with other companies, I saw heard this a lot.

              That said, I agree that I couldn't care less about RUP at this point in time. :-) However, RUP should serve as a warning about the dangers of over-specifying a process (framework) without stressing the importance of "inspect and adapt".

              To me, the key advantage of agile is that it starts with the *minimum* amount of process, and *only* adds to it if the retrospectives identify a deficiency that can only be fixed by adding more process. Even then, the change must prove itself over the course of a few iterations, otherwise the change should be backed out.

              On the other hand, RUP starts with the *maximum*(1) amount of process, and then attempts to trim it down. Rarely does the process lose enough weight to become effective.

              Mark

              Scary note 1: I once spoke with a consultant that was working with a Fortune 100 company to tailor RUP. They had spent ~5 person years worth of effort *increasing* the size of RUP! I had always thought that RUP was too big, but here was a company that though it needed to be made bigger! Oy.

              --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
              >
              > > I guess too many pointy-hair types were simply trying to jump on the
              > bandwagon without investing the time and money on trying to custom fit
              > it to their real needs.
              >
              > This has been a problem in the industry as long as I've been in it (~15 years).  Programmers don't like process(or requirements detailing), and companies don't value these skills enough to invest in process education (hire process experts, training, coaching, etc). 
              >
              > I did RUP for a few years, and the teams I was on did it pretty well.  Of the roughly 85 artifacts at the time, we generally got by with a handful or so.
              >
              > I'm pretty well convinced that, for the vast majority of the industry, in order to produce software efficiently, they need "process shepherds."  The Scrum Master is one implementation of this(and a step in the right direction IMO), but there are other ways of fulfilling the "process shepherd" pattern/role.  I'm also pretty well convinced that the no team can really *be* Agile unless they have regular and continued access to an Agile process shepherd.  I'm not saying it need be a dedicated full time position in all cases, only that some one or some individuals spend a lot of time "shepherding" effectively.
              >
              > If RUP had that kind of process shepherd role as a requirement, I think it would have succeeded more. If RUP had credible certifications like we have in the Scrum world, I think it would have succeeded more.  Having said that, at this time I couldn't care less about RUP.  :-)
              >
              > Full circle back to SAFe, and it seems they have learned some lessons from RUP and the Scrum movement wrt packaging, education and certifications.
              >
              >  
              > -------
              > Charles Bradley
              > http://www.ScrumCrazy.com
              >
              >
              >
              >
              >
              > >________________________________
              > > From: woynam <woyna@...>
              > >To: scrumdevelopment@yahoogroups.com
              > >Sent: Wednesday, October 31, 2012 9:17 AM
              > >Subject: [scrumdevelopment] Re: Scaled Agile Framework(aka SAFe)
              > >
              > >
              > >If some process is good, then more process has to be better, right? ;-)
              > >
              > >Seriously, I was shocked when I talked to people that more-or-less tried to implement RUP right out of the box. We had reasonable success with a very lightweight version, but once you go that far, it's fairly easy to keep going and simply embrace agile.
              > >
              > >I thought it was quite clear that RUP needed to be tailored, but I guess too many pointy-hair types were simply trying to jump on the bandwagon without investing the time and money on trying to custom fit it to their real needs.
              > >
              > >Mark
              > >
              > >--- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@> wrote:
              > >>
              > >> On Wed, Oct 31, 2012 at 10:31 AM, woynam <woyna@> wrote:
              > >>
              > >> > **
              > >> >
              > >> >
              > >> >
              > >> > That's funny, I thought that the biggest problem with RUP is that most
              > >> > organizations failed to realize that it was a process framework that
              > >> > *required* tailoring. Instead, they tried to implement RUP in its full
              > >> > "glory", and would up with a overweight cow.
              > >> >
              > >>
              > >> I think we meant the same thing. It tends be to be far heavier than it
              > >> needs.
              > >>
              > >> Cheers
              > >> Mark - who finds himself agreeing with Mark.
              > >>
              > >
              > >
              > >
              > >
              > >------------------------------------
              > >
              > >To Post a message, send it to:  scrumdevelopment@...
              > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
              > >
              > >
              > >
              > >
              > >
              > >
              >
            • George Dinwiddie
              Mark, ... Aye! http://blog.gdinwiddie.com/2012/08/08/bad-scrum-but-pretty-good-rup/ - George -- ... * George Dinwiddie *
              Message 6 of 27 , Nov 1, 2012
              • 0 Attachment
                Mark,

                On 11/1/12 4:10 PM, woynam wrote:
                > To me, the key advantage of agile is that it starts with the
                > *minimum* amount of process, and *only* adds to it if the
                > retrospectives identify a deficiency that can only be fixed by adding
                > more process. Even then, the change must prove itself over the course
                > of a few iterations, otherwise the change should be backed out.
                >
                > On the other hand, RUP starts with the *maximum*(1) amount of
                > process, and then attempts to trim it down. Rarely does the process
                > lose enough weight to become effective.

                Aye! http://blog.gdinwiddie.com/2012/08/08/bad-scrum-but-pretty-good-rup/

                - George

                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              • Stephen Bobick
                I still find the core concepts of RUP are quite useful and have value: - iterative and incremental - architecture-centric - use-case driven There is also a lot
                Message 7 of 27 , Nov 1, 2012
                • 0 Attachment
                  I still find the core concepts of RUP are quite useful and have value:

                  - iterative and incremental
                  - architecture-centric
                  - use-case driven

                  There is also a lot of emphasis on maintaining a "risk" list that is periodically revisited and reevaluated.

                  It seems to me that in Scrum and XP implementations there is a lot of deemphasizing the value of architecture - it is poo-poo'd as either an exercise leading to BUFD or YAGNI.  I feel architecture is often overlooked nowadays and this has a penalty.  Many folks also prefer user stories to use cases these days, but I still find value in the latter for certain projects and environments.

                  -- Stephen



                  On Thu, Nov 1, 2012 at 1:10 PM, woynam <woyna@...> wrote:
                   


                  In RUP, the process engineer role is responsible for the development of the "development case", which specifies the tailoring of RUP performed by the organization. An organization could elect to implement the whole framework, or modify it to suit their specific needs.

                  To perform the role of process engineer, one would expect the person to have detailed knowledge of RUP, the organization, and software development in general. As such, I would expect this person(s) to be the "shepherd".

                  It's quite obvious that the RUP community did not make it clear that success started with a knowledgeable process engineer. If the framework was not suitably tailored, it would likely wind up too big. In my conversations with other companies, I saw heard this a lot.

                  That said, I agree that I couldn't care less about RUP at this point in time. :-) However, RUP should serve as a warning about the dangers of over-specifying a process (framework) without stressing the importance of "inspect and adapt".

                  To me, the key advantage of agile is that it starts with the *minimum* amount of process, and *only* adds to it if the retrospectives identify a deficiency that can only be fixed by adding more process. Even then, the change must prove itself over the course of a few iterations, otherwise the change should be backed out.

                  On the other hand, RUP starts with the *maximum*(1) amount of process, and then attempts to trim it down. Rarely does the process lose enough weight to become effective.

                  Mark

                  Scary note 1: I once spoke with a consultant that was working with a Fortune 100 company to tailor RUP. They had spent ~5 person years worth of effort *increasing* the size of RUP! I had always thought that RUP was too big, but here was a company that though it needed to be made bigger! Oy.

                  --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                  >
                  > > I guess too many pointy-hair types were simply trying to jump on the
                  > bandwagon without investing the time and money on trying to custom fit
                  > it to their real needs.
                  >
                  > This has been a problem in the industry as long as I've been in it (~15 years).  Programmers don't like process(or requirements detailing), and companies don't value these skills enough to invest in process education (hire process experts, training, coaching, etc). 
                  >
                  > I did RUP for a few years, and the teams I was on did it pretty well.  Of the roughly 85 artifacts at the time, we generally got by with a handful or so.
                  >
                  > I'm pretty well convinced that, for the vast majority of the industry, in order to produce software efficiently, they need "process shepherds."  The Scrum Master is one implementation of this(and a step in the right direction IMO), but there are other ways of fulfilling the "process shepherd" pattern/role.  I'm also pretty well convinced that the no team can really *be* Agile unless they have regular and continued access to an Agile process shepherd.  I'm not saying it need be a dedicated full time position in all cases, only that some one or some individuals spend a lot of time "shepherding" effectively.
                  >
                  > If RUP had that kind of process shepherd role as a requirement, I think it would have succeeded more. If RUP had credible certifications like we have in the Scrum world, I think it would have succeeded more.  Having said that, at this time I couldn't care less about RUP.  :-)
                  >
                  > Full circle back to SAFe, and it seems they have learned some lessons from RUP and the Scrum movement wrt packaging, education and certifications.
                  >
                  >  
                  > -------
                  > Charles Bradley
                  > http://www.ScrumCrazy.com
                  >
                  >
                  >
                  >
                  >
                  > >________________________________
                  > > From: woynam <woyna@...>
                  > >To: scrumdevelopment@yahoogroups.com
                  > >Sent: Wednesday, October 31, 2012 9:17 AM
                  > >Subject: [scrumdevelopment] Re: Scaled Agile Framework(aka SAFe)
                  > >
                  > >
                  > >If some process is good, then more process has to be better, right? ;-)
                  > >
                  > >Seriously, I was shocked when I talked to people that more-or-less tried to implement RUP right out of the box. We had reasonable success with a very lightweight version, but once you go that far, it's fairly easy to keep going and simply embrace agile.
                  > >
                  > >I thought it was quite clear that RUP needed to be tailored, but I guess too many pointy-hair types were simply trying to jump on the bandwagon without investing the time and money on trying to custom fit it to their real needs.
                  > >
                  > >Mark
                  > >
                  > >--- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@> wrote:
                  > >>
                  > >> On Wed, Oct 31, 2012 at 10:31 AM, woynam <woyna@> wrote:
                  > >>
                  > >> > **
                  > >> >
                  > >> >
                  > >> >
                  > >> > That's funny, I thought that the biggest problem with RUP is that most
                  > >> > organizations failed to realize that it was a process framework that
                  > >> > *required* tailoring. Instead, they tried to implement RUP in its full
                  > >> > "glory", and would up with a overweight cow.
                  > >> >
                  > >>
                  > >> I think we meant the same thing. It tends be to be far heavier than it
                  > >> needs.
                  > >>
                  > >> Cheers
                  > >> Mark - who finds himself agreeing with Mark.
                  > >>
                  > >
                  > >
                  > >
                  > >
                  > >------------------------------------
                  > >
                  > >To Post a message, send it to:  scrumdevelopment@...
                  > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  >


                • woynam
                  Nice. RUP doesn t specify the length of an iteration. We started with 3 month iterations, but of course you don t find out that you ve built the wrong thing
                  Message 8 of 27 , Nov 1, 2012
                  • 0 Attachment
                    Nice. RUP doesn't specify the length of an iteration. We started with 3 month iterations, but of course you don't find out that you've built the wrong thing until 3 months later.

                    The solution is to reduce the length of the iteration. Once it's down to 4 weeks, then 2 weeks, then 1 week lengths, it becomes rather clear then something has got to go. This is when you start to jettison the unnecessary documents and time-wasting gates.

                    So, tell the company to start reducing the iteration lengths, and they just might discover agile.

                    Another thing to look at is the version history on the documents and models. We finally tossed RUP when we were pressed to get a major release out in a reasonably short period of time. Once we successfully deployed the release, I went back and looked at the hundreds of documents that we had maintained over the previous two years. Funny, but not a single document had been updated, but somehow we managed to deploy a well-received release. Hmmmm. How was that possible? Simple. We only thought the documents were necessary. It turns out that having real conversations, whether in-person or via email, was sufficient to capture the needs of the release.

                    In addition, if you asked a team member what the software was doing, they sure the heck didn't pull up the use case document or the UML diagram. They looked at the code, i.e. "the ground truth". Documents lie. Models lie. The code doesn't lie (including executable test). We're all basically aware that "the code is the design".

                    Mark

                    --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
                    >
                    > Mark,
                    >
                    > On 11/1/12 4:10 PM, woynam wrote:
                    > > To me, the key advantage of agile is that it starts with the
                    > > *minimum* amount of process, and *only* adds to it if the
                    > > retrospectives identify a deficiency that can only be fixed by adding
                    > > more process. Even then, the change must prove itself over the course
                    > > of a few iterations, otherwise the change should be backed out.
                    > >
                    > > On the other hand, RUP starts with the *maximum*(1) amount of
                    > > process, and then attempts to trim it down. Rarely does the process
                    > > lose enough weight to become effective.
                    >
                    > Aye! http://blog.gdinwiddie.com/2012/08/08/bad-scrum-but-pretty-good-rup/
                    >
                    > - George
                    >
                    > --
                    > ----------------------------------------------------------------------
                    > * George Dinwiddie * http://blog.gdinwiddie.com
                    > Software Development http://www.idiacomputing.com
                    > Consultant and Coach http://www.agilemaryland.org
                    > ----------------------------------------------------------------------
                    >
                  • woynam
                    Agile also stresses iterative and incremental development. The key is that the iteration is short. If you re working in 30 day or less chunks, the process has
                    Message 9 of 27 , Nov 1, 2012
                    • 0 Attachment
                      Agile also stresses iterative and incremental development. The key is that the iteration is short. If you're working in 30 day or less chunks, the process has to be lightweight to succeed. It forces the team to be more focused on the product and engineering practices, and less on the process artifacts.

                      I think many would say that agile is architecture centric. They key is that is focuses on the *minimum* amount of architecture, allowing to to grow as needed.

                      Once again, I think user stories was a backlash against overly big use case documents. There was nothing wrong about using a user-centric approach to gathering requirements. This was a big change for the industry. However, once people start going overboard, they start to lose their value. Agile attempts to correct that by focusing the team on the conversation, rather than the document. It's still user-centric, but, much lighter weight.

                      Mark


                      --- In scrumdevelopment@yahoogroups.com, Stephen Bobick <sbobick2@...> wrote:
                      >
                      > I still find the core concepts of RUP are quite useful and have value:
                      >
                      > - iterative and incremental
                      > - architecture-centric
                      > - use-case driven
                      >
                      > There is also a lot of emphasis on maintaining a "risk" list that is
                      > periodically revisited and reevaluated.
                      >
                      > It seems to me that in Scrum and XP implementations there is a lot of
                      > deemphasizing the value of architecture - it is poo-poo'd as either an
                      > exercise leading to BUFD or YAGNI. I feel architecture is often overlooked
                      > nowadays and this has a penalty. Many folks also prefer user stories to
                      > use cases these days, but I still find value in the latter for certain
                      > projects and environments.
                      >
                      > -- Stephen
                      >
                      >
                      >
                      > On Thu, Nov 1, 2012 at 1:10 PM, woynam <woyna@...> wrote:
                      >
                      > > **
                      > >
                      > >
                      > >
                      > > In RUP, the process engineer role is responsible for the development of
                      > > the "development case", which specifies the tailoring of RUP performed by
                      > > the organization. An organization could elect to implement the whole
                      > > framework, or modify it to suit their specific needs.
                      > >
                      > > To perform the role of process engineer, one would expect the person to
                      > > have detailed knowledge of RUP, the organization, and software development
                      > > in general. As such, I would expect this person(s) to be the "shepherd".
                      > >
                      > > It's quite obvious that the RUP community did not make it clear that
                      > > success started with a knowledgeable process engineer. If the framework was
                      > > not suitably tailored, it would likely wind up too big. In my conversations
                      > > with other companies, I saw heard this a lot.
                      > >
                      > > That said, I agree that I couldn't care less about RUP at this point in
                      > > time. :-) However, RUP should serve as a warning about the dangers of
                      > > over-specifying a process (framework) without stressing the importance of
                      > > "inspect and adapt".
                      > >
                      > > To me, the key advantage of agile is that it starts with the *minimum*
                      > > amount of process, and *only* adds to it if the retrospectives identify a
                      > > deficiency that can only be fixed by adding more process. Even then, the
                      > > change must prove itself over the course of a few iterations, otherwise the
                      > > change should be backed out.
                      > >
                      > > On the other hand, RUP starts with the *maximum*(1) amount of process, and
                      > > then attempts to trim it down. Rarely does the process lose enough weight
                      > > to become effective.
                      > >
                      > > Mark
                      > >
                      > > Scary note 1: I once spoke with a consultant that was working with a
                      > > Fortune 100 company to tailor RUP. They had spent ~5 person years worth of
                      > > effort *increasing* the size of RUP! I had always thought that RUP was too
                      > > big, but here was a company that though it needed to be made bigger! Oy.
                      > >
                      > > --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach
                      > > CSP CSM PSM I <chuck-lists2@> wrote:
                      > > >
                      > > > > I guess too many pointy-hair types were simply trying to jump on the
                      > > > bandwagon without investing the time and money on trying to custom fit
                      > > > it to their real needs.
                      > > >
                      > > > This has been a problem in the industry as long as I've been in it (~15
                      > > years). Programmers don't like process(or requirements detailing), and
                      > > companies don't value these skills enough to invest in process education
                      > > (hire process experts, training, coaching, etc).
                      > > >
                      > > > I did RUP for a few years, and the teams I was on did it pretty well.
                      > > Of the roughly 85 artifacts at the time, we generally got by with a handful
                      > > or so.
                      > > >
                      > > > I'm pretty well convinced that, for the vast majority of the industry,
                      > > in order to produce software efficiently, they need "process shepherds."
                      > > The Scrum Master is one implementation of this(and a step in the right
                      > > direction IMO), but there are other ways of fulfilling the "process
                      > > shepherd" pattern/role. I'm also pretty well convinced that the no team
                      > > can really *be* Agile unless they have regular and continued access to an
                      > > Agile process shepherd. I'm not saying it need be a dedicated full time
                      > > position in all cases, only that some one or some individuals spend a lot
                      > > of time "shepherding" effectively.
                      > > >
                      > > > If RUP had that kind of process shepherd role as a requirement, I think
                      > > it would have succeeded more. If RUP had credible certifications like we
                      > > have in the Scrum world, I think it would have succeeded more. Having said
                      > > that, at this time I couldn't care less about RUP. :-)
                      > > >
                      > > > Full circle back to SAFe, and it seems they have learned some lessons
                      > > from RUP and the Scrum movement wrt packaging, education and certifications.
                      > > >
                      > > >
                      > > > -------
                      > > > Charles Bradley
                      > > > http://www.ScrumCrazy.com
                      > > >
                      > > >
                      > > >
                      > > >
                      > > >
                      > > > >________________________________
                      > > > > From: woynam <woyna@>
                      > > > >To: scrumdevelopment@yahoogroups.com
                      > > > >Sent: Wednesday, October 31, 2012 9:17 AM
                      > > > >Subject: [scrumdevelopment] Re: Scaled Agile Framework(aka SAFe)
                      > > > >
                      > > > >
                      > > > >If some process is good, then more process has to be better, right? ;-)
                      > > > >
                      > > > >Seriously, I was shocked when I talked to people that more-or-less
                      > > tried to implement RUP right out of the box. We had reasonable success with
                      > > a very lightweight version, but once you go that far, it's fairly easy to
                      > > keep going and simply embrace agile.
                      > > > >
                      > > > >I thought it was quite clear that RUP needed to be tailored, but I
                      > > guess too many pointy-hair types were simply trying to jump on the
                      > > bandwagon without investing the time and money on trying to custom fit it
                      > > to their real needs.
                      > > > >
                      > > > >Mark
                      > > > >
                      > > > >--- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@> wrote:
                      > > > >>
                      > > > >> On Wed, Oct 31, 2012 at 10:31 AM, woynam <woyna@> wrote:
                      > > > >>
                      > > > >> > **
                      > > > >> >
                      > > > >> >
                      > > > >> >
                      > > > >> > That's funny, I thought that the biggest problem with RUP is that
                      > > most
                      > > > >> > organizations failed to realize that it was a process framework that
                      > > > >> > *required* tailoring. Instead, they tried to implement RUP in its
                      > > full
                      > > > >> > "glory", and would up with a overweight cow.
                      > > > >> >
                      > > > >>
                      > > > >> I think we meant the same thing. It tends be to be far heavier than it
                      > > > >> needs.
                      > > > >>
                      > > > >> Cheers
                      > > > >> Mark - who finds himself agreeing with Mark.
                      > > > >>
                      > > > >
                      > > > >
                      > > > >
                      > > > >
                      > > > >------------------------------------
                      > > > >
                      > > > >To Post a message, send it to: scrumdevelopment@
                      > > > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@!
                      > > Groups Links
                      > > > >
                      > > > >
                      > > > >
                      > > > >
                      > > > >
                      > > > >
                      > > >
                      > >
                      > >
                      > >
                      >
                    • Stephen Bobick
                      Comments in line. ... Of course. ... I ve seen folks take it to an extreme (pun intended) in the name of agile - throwing out too much consideration of
                      Message 10 of 27 , Nov 1, 2012
                      • 0 Attachment
                        Comments in line.

                        On Thu, Nov 1, 2012 at 2:15 PM, woynam <woyna@...> wrote:
                         


                        Agile also stresses iterative and incremental development. The key is that the iteration is short. If you're working in 30 day or less chunks, the process has to be lightweight to succeed. It forces the team to be more focused on the product and engineering practices, and less on the process artifacts.


                        Of course.
                         


                        I think many would say that agile is architecture centric. They key is that is focuses on the *minimum* amount of architecture, allowing to to grow as needed.


                        I've seen folks take it to an extreme (pun intended) in the name of "agile" - throwing out too much consideration of architecture and paying later.


                        Once again, I think user stories was a backlash against overly big use case documents. There was nothing wrong about using a user-centric approach to gathering requirements. This was a big change for the industry. However, once people start going overboard, they start to lose their value. Agile attempts to correct that by focusing the team on the conversation, rather than the document. It's still user-centric, but, much lighter weight.

                        Scrum does not specify using one or the other and Scrum is Agile.  I think Use Cases can fit very will into an Agile environment. They can, of course, also be abused and be a negative.  I see pros and cons to User Stories as well.

                        Anyways, I am just throwing in a few ideas about RUP as that is where this thread has headed.  This is a Scrum discussion list of course, so all of us here have some vested interested in applying Scrum, and I don't think anyone is saying to resurrect the monolith(s) of the past.  :-)

                        -- S

                         


                        Mark



                        --- In scrumdevelopment@yahoogroups.com, Stephen Bobick <sbobick2@...> wrote:
                        >
                        > I still find the core concepts of RUP are quite useful and have value:
                        >
                        > - iterative and incremental
                        > - architecture-centric
                        > - use-case driven
                        >
                        > There is also a lot of emphasis on maintaining a "risk" list that is
                        > periodically revisited and reevaluated.
                        >
                        > It seems to me that in Scrum and XP implementations there is a lot of
                        > deemphasizing the value of architecture - it is poo-poo'd as either an
                        > exercise leading to BUFD or YAGNI. I feel architecture is often overlooked
                        > nowadays and this has a penalty. Many folks also prefer user stories to
                        > use cases these days, but I still find value in the latter for certain
                        > projects and environments.
                        >
                        > -- Stephen
                        >
                        >
                        >
                        > On Thu, Nov 1, 2012 at 1:10 PM, woynam <woyna@...> wrote:
                        >
                        > > **

                        > >
                        > >
                        > >
                        > > In RUP, the process engineer role is responsible for the development of
                        > > the "development case", which specifies the tailoring of RUP performed by
                        > > the organization. An organization could elect to implement the whole
                        > > framework, or modify it to suit their specific needs.
                        > >
                        > > To perform the role of process engineer, one would expect the person to
                        > > have detailed knowledge of RUP, the organization, and software development
                        > > in general. As such, I would expect this person(s) to be the "shepherd".
                        > >
                        > > It's quite obvious that the RUP community did not make it clear that
                        > > success started with a knowledgeable process engineer. If the framework was
                        > > not suitably tailored, it would likely wind up too big. In my conversations
                        > > with other companies, I saw heard this a lot.
                        > >
                        > > That said, I agree that I couldn't care less about RUP at this point in
                        > > time. :-) However, RUP should serve as a warning about the dangers of
                        > > over-specifying a process (framework) without stressing the importance of
                        > > "inspect and adapt".
                        > >
                        > > To me, the key advantage of agile is that it starts with the *minimum*
                        > > amount of process, and *only* adds to it if the retrospectives identify a
                        > > deficiency that can only be fixed by adding more process. Even then, the
                        > > change must prove itself over the course of a few iterations, otherwise the
                        > > change should be backed out.
                        > >
                        > > On the other hand, RUP starts with the *maximum*(1) amount of process, and
                        > > then attempts to trim it down. Rarely does the process lose enough weight
                        > > to become effective.
                        > >
                        > > Mark
                        > >
                        > > Scary note 1: I once spoke with a consultant that was working with a
                        > > Fortune 100 company to tailor RUP. They had spent ~5 person years worth of
                        > > effort *increasing* the size of RUP! I had always thought that RUP was too
                        > > big, but here was a company that though it needed to be made bigger! Oy.
                        > >
                        > > --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach
                        > > CSP CSM PSM I <chuck-lists2@> wrote:
                        > > >
                        > > > > I guess too many pointy-hair types were simply trying to jump on the
                        > > > bandwagon without investing the time and money on trying to custom fit
                        > > > it to their real needs.
                        > > >
                        > > > This has been a problem in the industry as long as I've been in it (~15
                        > > years). Programmers don't like process(or requirements detailing), and
                        > > companies don't value these skills enough to invest in process education
                        > > (hire process experts, training, coaching, etc).
                        > > >
                        > > > I did RUP for a few years, and the teams I was on did it pretty well.
                        > > Of the roughly 85 artifacts at the time, we generally got by with a handful
                        > > or so.
                        > > >
                        > > > I'm pretty well convinced that, for the vast majority of the industry,
                        > > in order to produce software efficiently, they need "process shepherds."
                        > > The Scrum Master is one implementation of this(and a step in the right
                        > > direction IMO), but there are other ways of fulfilling the "process
                        > > shepherd" pattern/role. I'm also pretty well convinced that the no team
                        > > can really *be* Agile unless they have regular and continued access to an
                        > > Agile process shepherd. I'm not saying it need be a dedicated full time
                        > > position in all cases, only that some one or some individuals spend a lot
                        > > of time "shepherding" effectively.
                        > > >
                        > > > If RUP had that kind of process shepherd role as a requirement, I think
                        > > it would have succeeded more. If RUP had credible certifications like we
                        > > have in the Scrum world, I think it would have succeeded more. Having said
                        > > that, at this time I couldn't care less about RUP. :-)
                        > > >
                        > > > Full circle back to SAFe, and it seems they have learned some lessons
                        > > from RUP and the Scrum movement wrt packaging, education and certifications.
                        > > >
                        > > >
                        > > > -------
                        > > > Charles Bradley
                        > > > http://www.ScrumCrazy.com
                        > > >
                        > > >
                        > > >
                        > > >
                        > > >
                        > > > >________________________________
                        > > > > From: woynam <woyna@>
                        > > > >To: scrumdevelopment@yahoogroups.com
                        > > > >Sent: Wednesday, October 31, 2012 9:17 AM
                        > > > >Subject: [scrumdevelopment] Re: Scaled Agile Framework(aka SAFe)
                        > > > >
                        > > > >
                        > > > >If some process is good, then more process has to be better, right? ;-)
                        > > > >
                        > > > >Seriously, I was shocked when I talked to people that more-or-less
                        > > tried to implement RUP right out of the box. We had reasonable success with
                        > > a very lightweight version, but once you go that far, it's fairly easy to
                        > > keep going and simply embrace agile.
                        > > > >
                        > > > >I thought it was quite clear that RUP needed to be tailored, but I
                        > > guess too many pointy-hair types were simply trying to jump on the
                        > > bandwagon without investing the time and money on trying to custom fit it
                        > > to their real needs.
                        > > > >
                        > > > >Mark
                        > > > >
                        > > > >--- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@> wrote:
                        > > > >>
                        > > > >> On Wed, Oct 31, 2012 at 10:31 AM, woynam <woyna@> wrote:
                        > > > >>
                        > > > >> > **
                        > > > >> >
                        > > > >> >
                        > > > >> >
                        > > > >> > That's funny, I thought that the biggest problem with RUP is that
                        > > most
                        > > > >> > organizations failed to realize that it was a process framework that
                        > > > >> > *required* tailoring. Instead, they tried to implement RUP in its
                        > > full
                        > > > >> > "glory", and would up with a overweight cow.
                        > > > >> >
                        > > > >>
                        > > > >> I think we meant the same thing. It tends be to be far heavier than it
                        > > > >> needs.
                        > > > >>
                        > > > >> Cheers
                        > > > >> Mark - who finds himself agreeing with Mark.
                        > > > >>
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > >------------------------------------
                        > > > >
                        > > > >To Post a message, send it to: scrumdevelopment@
                        > > > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@!
                        > > Groups Links
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > >
                        > >
                        > >
                        > >
                        >


                      • George Dinwiddie
                        Mark, ... Agree with all that. ... It s a little more complicated than telling. It s actually two branches of a large organization plus one large contractor.
                        Message 11 of 27 , Nov 1, 2012
                        • 0 Attachment
                          Mark,

                          On 11/1/12 5:07 PM, woynam wrote:
                          >
                          > Nice. RUP doesn't specify the length of an iteration. We started with
                          > 3 month iterations, but of course you don't find out that you've
                          > built the wrong thing until 3 months later.
                          >
                          > The solution is to reduce the length of the iteration. Once it's down
                          > to 4 weeks, then 2 weeks, then 1 week lengths, it becomes rather
                          > clear then something has got to go. This is when you start to
                          > jettison the unnecessary documents and time-wasting gates.

                          Agree with all that.

                          > So, tell the company to start reducing the iteration lengths, and
                          > they just might discover agile.

                          It's a little more complicated than "telling." It's actually two
                          branches of a large organization plus one large contractor. There are
                          those who want to reduce the iteration length, and those who say it's
                          impossible. The large number of people involved will likely make that
                          change take awhile. I have to have patience.

                          > Another thing to look at is the version history on the documents and
                          > models. We finally tossed RUP when we were pressed to get a major
                          > release out in a reasonably short period of time. Once we
                          > successfully deployed the release, I went back and looked at the
                          > hundreds of documents that we had maintained over the previous two
                          > years. Funny, but not a single document had been updated, but somehow
                          > we managed to deploy a well-received release. Hmmmm. How was that
                          > possible? Simple. We only thought the documents were necessary. It
                          > turns out that having real conversations, whether in-person or via
                          > email, was sufficient to capture the needs of the release.

                          In this case, the documents are considered deliverables by the contract,
                          so are being updated. Dunno how accurate they are, but they're being
                          updated.

                          They're not, of course, being used to communicate between developers.

                          > In addition, if you asked a team member what the software was doing,
                          > they sure the heck didn't pull up the use case document or the UML
                          > diagram. They looked at the code, i.e. "the ground truth". Documents
                          > lie. Models lie. The code doesn't lie (including executable test).
                          > We're all basically aware that "the code is the design".

                          Those that code, are. Those that watch those that code, not always.

                          - George

                          --
                          ----------------------------------------------------------------------
                          * George Dinwiddie * http://blog.gdinwiddie.com
                          Software Development http://www.idiacomputing.com
                          Consultant and Coach http://www.agilemaryland.org
                          ----------------------------------------------------------------------
                        • RonJeffries
                          Hi Mark, ... 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
                          Message 12 of 27 , Nov 1, 2012
                          • 0 Attachment
                            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.
                            If not now, when? -- Rabbi Hillel

                          • 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 13 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 14 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.