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

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

Expand Messages
  • Stephen Bobick
    Nov 1, 2012
    • 0 Attachment
      Comments in line.

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


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


      Of course.
       


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


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


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

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

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

      -- S

       


      Mark



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

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


    • Show all 27 messages in this topic