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

Scaled Agile Framework(aka SAFe)

Expand Messages
  • Charles Bradley - Scrum Coach CSP CSM PSM
    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,
    Message 1 of 27 , Oct 30, 2012
      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


    • Kurt Häusler
      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
      Message 2 of 27 , Oct 30, 2012
        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
        >
        >
        >
      • srinivas chillara
        Hello Scrummers , I ve had taken a more than passing glance at this (SAFe) and it certainly has merits. The two things in favour are: 1. It actually introduces
        Message 3 of 27 , Oct 30, 2012
          Hello Scrummers ,
          I've had taken a more than passing glance at this (SAFe) and it certainly has merits.
          The two things in favour are:
          1. It actually introduces sprints into the general scheme of things. Large companies with hundreds of people in projects and programmes needs to weaned away from waterfall structures of six month cycles. And it is very clear in focusing on delivering working software at end of sprints.
          2. Most (I'd say over 90%+) managers in such s/w dev orgs can't get their heads around how this whole newfangled approach works. They simply cannot connect what they understand (whatever little) from a standard Scrum course/workshop to what they currently have in their project groups. They need some anchoring big picture on how things can be implemented. I think this is a very useful contribution.

          On the other hand there are people like us (on this group) who may see only marginal value in SAFe since we understand the pillars of Scrum/Lean well and have less need for it. Howevver on reflection I remember what a struggle it was to explain to a group of managers how a single team's Scrum practices could be extended to a large project group, let alone a whole business unit. The question of culture, is very important but a very daunting one to grapple with for big organisations, unless the leadership is absolutely committed. In these days of 'maximising shareholder returns' I'd say for large companies there is a very long way to go. Not always, not necessarily but this is how it is, even though it should not be.

          And again it is worth remembering that final performance depends as much (rather more) on people as on processes/tools etc. Many of these organisation routinely see only 'resources' to be deployed.

          As for what Kurt says "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." 

          I'd put it unequivocally as ' But for a larger org... ......it is almost certainly a good start'. I see the ditching of waterfall and the move to shorter iterations as the main benefit (not to be sneered at). Similar story with SAFe certification (as we've een with CSM/CSPO/CSP et al ...) it is just a good start. Unfortunately, the overwhelming majority views the gaining of a certification as an end in itself!

          What of culture change? Ah but that's another story. Is it something of a lost opportunity? very possibly, but I don't feel qualified to write more about this aspect. 

          cheers
          Srinivas
          www.ceezone.net 
          http://ceezone.wordpress.com




          From: Kurt Häusler <kurt.haeusler@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Wednesday, 31 October 2012 10:17 AM
          Subject: Re: [scrumdevelopment] Scaled Agile Framework(aka SAFe)

          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/



        • srinivas
          Hello All (Am retyping since Yahoo seems to have eaten my reply) I ve take a reasonably detailed look at this (SAFe) and use it to some extent. There is very
          Message 4 of 27 , Oct 31, 2012
            Hello All (Am retyping since Yahoo seems to have eaten my reply)

            I've take a reasonably detailed look at this (SAFe) and use it to some extent. There is very significant merit here.

            Two points in favour are:

            1. It focuses on having (relatively much shorter) sprints at the end of which software ('done') needs to be delivered. This weans large orgs away from a viscous waterfall and it's structure of six month cycles.

            2. Most managers (about 90%) in large organisations can't get their head around how Scrum practices can be extended to entire project group, let alone a whole business unit. They need some reference 'big picture' to be handed down.

            As I reflect how difficult it was to explain to traditional managers how Scrum can be used for large groups, I'd put what Kurt says "But for a larger organisation wishing to get some benefit" more unequivocally "It is almost surely a good place to start". (Putting words in your mouth Kurt, sorry)

            Mainly I see it as a means to break the waterfall habits and delivery structure (a benefit not to be sneered at). I'd even say that this is very important in the medium term.

            Cheers
            Srinivas
            http://ceezone.wordpress.com
            www.ceezone.net

            PS: About culture change? this is another story, a real Pandora's box wrapped up in a fog of confusion.

            On a related note, I keep hearing 'Organisation agile transformation' bandied about by various consulting companies. I'm deeply skeptical. I really wonder how many people are qualified/able to overhaul a large organisation's culture. It can be done in small teams/groups. as a coach/consultant over six years seen it partially and helped in such initiatives. Though even in such cases it is a very significant improvement, but hardly a 'transformation' (transformation has a sense of finality). But for large groups (100+) I take such claims with a bag of salt. I don't think any process will achieve it. Also, in our community we have not yet had a lot of meaningful discussion on change management.







            --- In scrumdevelopment@yahoogroups.com, 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
            > >
            > >
            > >
            >
          • Kurt Häusler
            ... It is an interesting and important topic. This cultural change is necessary to get any significant benefit from agile software development. I don t think
            Message 5 of 27 , Oct 31, 2012
              > PS: About culture change? this is another story, a real Pandora's box wrapped up in a fog of confusion.
              >
              > On a related note, I keep hearing 'Organisation agile transformation' bandied about by various consulting companies. I'm deeply skeptical. I really wonder how many people are qualified/able to overhaul a large organisation's culture. It can be done in small teams/groups. as a coach/consultant over six years seen it partially and helped in such initiatives. Though even in such cases it is a very significant improvement, but hardly a 'transformation' (transformation has a sense of finality). But for large groups (100+) I take such claims with a bag of salt. I don't think any process will achieve it. Also, in our community we have not yet had a lot of meaningful discussion on change management.

              It is an interesting and important topic. This cultural change is
              necessary to get any significant benefit from agile software
              development. I don't think the Scrum community really addresses the
              topic that well either. The walled garden means Scrum Teams can work
              fairly well as an agile island, fully embodying the type of culture
              the agile values hint at, even if the rest of the organization is a
              centrally controlled machine running on fear and mistrust. The idea of
              ScrumMasters being responsible for changing this around has some
              merit, but I don't know how successful it is as a strategy, especially
              in larger companies or companies where software is not the main
              product.

              You are right culture cannot be changed directly. But you can change
              the management system which can help steer culture in a certain
              direction. And even more importantly, individual managers can change
              they way they think and make decisions. That is basically what it
              comes down to.

              The SAFe seems to be a way to make Scrum work almost as good as
              expected in an organization determined not to allow its culture to
              evolve.

              Interesting communities I have found discussing such topics are the
              Rightshifting community, and The Stoos Network. But it is hardly new
              either. It is roughly what people like Deming, Drucker and Ackoff have
              been talking about for decades.
            • srinivas chillara
              True, true. I agree with almost all you ve said.  But w.r.t  This cultural change is necessary to get any significant benefit from agile
              Message 6 of 27 , Oct 31, 2012
                True, true. I agree with almost all you've said. 
                But w.r.t "This cultural change is necessary to get any significant benefit from agile software development." 
                The only point I stress is: Do not underestimate the benefit of simply breaking a three to six month waterfall cycle and having a deliveries and feedback opportunities every two weeks (even if it is a series of 2 week mini-waterfalls). Most large orgs having a legacy, don't know how to do this. 

                In other words the structural improvement itself is a very worthwhile goal, even as we, for the present, duck the question of cultural change (which BTW is even more frightening for many).
                And this maybe what orgs are doing, ducking the question, and not deliberately resisting a culture change. In fact in many places even this structural change is vigorously resisted. And to be fair to Dean, he does discuss change in thinking of leadership. How effectively this is done I don't know.

                yes, you are right about what so many Gurus say regarding the need for changing to an evolved culture. But I came to know of this only in the last couple of years or so, how far ahead thought leaders are of the masses. 

                cheers
                Srinivas
                http://ceezone.wordpress.com



                It is an interesting and important topic. This cultural change is
                necessary to get any significant benefit from agile software
                development. I don't think the Scrum community really addresses the
                topic that well either. The walled garden means Scrum Teams can work
                fairly well as an agile island, fully embodying the type of culture
                the agile values hint at, even if the rest of the organization is a
                centrally controlled machine running on fear and mistrust. The idea of
                ScrumMasters being responsible for changing this around has some
                merit, but I don't know how successful it is as a strategy, especially
                in larger companies or companies where software is not the main
                product.

                You are right culture cannot be changed directly. But you can change
                the management system which can help steer culture in a certain
                direction. And even more importantly, individual managers can change
                they way they think and make decisions. That is basically what it
                comes down to.

                The SAFe seems to be a way to make Scrum work almost as good as
                expected in an organization determined not to allow its culture to
                evolve.

                Interesting communities I have found discussing such topics are the
                Rightshifting community, and The Stoos Network. But it is hardly new
                either. It is roughly what people like Deming, Drucker and Ackoff have
                been talking about for decades.


              • Mark Levison
                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.
                Message 7 of 27 , Oct 31, 2012
                  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 
                • banshee858
                  ... I ve heard a presentation on this topic and it concerns me since it plays into exactly into many weaknesses of large organizations and institutionalizes
                  Message 8 of 27 , Oct 31, 2012
                    >
                    > 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've heard a presentation on this topic and it concerns me since it plays into exactly into many weaknesses of large organizations and institutionalizes them into "best practice". I am not saying the ideas are terrible, but they make me worried. There has got to be a better way to scale than what is described here.

                    Also, the idea of a hardening Sprint makes me shudder. A hardening Sprint is a bridge practice on the way to continuous delivery. I recommend Teams that have never done Scrum to reserve time at the end of a release to close out loose ends and give a little slack in the schedule. As a longterm practice, a hardening Sprint is just an excuse to be sloppy technically and encourages poor communication between the Teams.

                    Carlton
                  • woynam
                    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*
                    Message 9 of 27 , Oct 31, 2012
                      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.

                      Mark

                      --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@...> wrote:
                      >
                      > 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
                      >
                    • Mark Levison
                      ... 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.
                      Message 10 of 27 , Oct 31, 2012
                        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. 
                      • woynam
                        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
                        Message 11 of 27 , Oct 31, 2012
                          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.
                          >
                        • 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 12 of 27 , Oct 31, 2012
                            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/


                          • Adam Sroka
                            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,
                            Message 13 of 27 , Oct 31, 2012
                              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



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

                                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





                              • Michael James
                                ... Yeah. The best process can do is protect one effective team from the rest of the mess. --mj http://ScrumTrainingSeries.com
                                Message 15 of 27 , Oct 31, 2012
                                  On Oct 31, 2012, at 10:00 AM, Adam Sroka <adam.sroka@...> wrote:

                                  "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. 

                                  Yeah.  The best process can do is protect one effective team from the rest of the mess.

                                  --mj
                                • 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 16 of 27 , Nov 1 10:00 AM
                                    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 17 of 27 , Nov 1 10:10 AM
                                      > 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 18 of 27 , Nov 1 1:10 PM
                                        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 19 of 27 , Nov 1 1:35 PM
                                          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 20 of 27 , Nov 1 1:54 PM
                                            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 21 of 27 , Nov 1 2:07 PM
                                              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 22 of 27 , Nov 1 2:15 PM
                                                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 23 of 27 , Nov 1 2:21 PM
                                                  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 24 of 27 , Nov 1 2:37 PM
                                                    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 25 of 27 , Nov 1 3:27 PM
                                                      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 26 of 27 , Nov 2 7:04 AM
                                                        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 27 of 27 , Nov 2 11:29 AM
                                                          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.