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

RE: [scrumdevelopment] Scaling Scrum

Expand Messages
  • John Keane
    Hi all, I guess the thing that I don t understand about the functions that you mention is why can t that be handled w/n the main sprints? What is the need for
    Message 1 of 80 , Feb 1, 2005
    • 0 Attachment

      Hi all,

      I guess the thing that I don’t understand about the functions that you mention is why can’t that be handled w/n the main sprints? What is the need for a separate QA function? I would think that you would want to have the QA group as tightly integrated into the main sprints as possible.  We have been doing SCRUM and haven’t gotten there completely but that is the drum that I am beating w/ my team.  I manage our team of QA engineers here and we are going in an entirely different direction from an independent QA function.  I think it is a testimony to SCRUM how well it functions in almost any environment; however I am trying to move my team to more of an xp model with the QA function closer to the construction task.  I would love to say that we are completely there, but that isn’t the case today.  The way we currently solve it is that we have the main sprints and we tack on a release sprint at the end.  The intent of this release sprint is to move the code from dev to out Production Test environment.  This is as much for IT as it is QA, but the intent is that most of the new functionality is already tested before we enter the release sprint.  In the final phase we handle the regression and environment related testing.  In the future, I really want us to be developing a large suite of automated tests ala xp and using the regression period for only exploratory testing.  I think the tools that we can use to get there is XP, so we are going to prototype it on one team in the coming months.

       

      John Keane

      Development Manager

      Phone: (206) 816-8248

      Mobile: (206) 853-4605

      E-Mail: john.keane@...

      MS IM: jfkeane1025@...

       

      atlas DMT™
      "Hailed by many online ad professionals as having
      the best ad server out there." -Media Magazine

      Sign up to get the latest digital marketing research at:
      www.atlasdmt.com/contact/signUp.asp

       


      From: Charles Prakash Dasari [mailto:cdasari@...]
      Sent: Sunday, January 30, 2005 9:44 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Scaling Scrum

       

      I am smelling some non-Agile points in your list below... at least (b,
      c, d, g, h). Am I the only one?


      On Mon, 31 Jan 2005 10:07:17 +0530, Balaji C.R <balajicr@...> wrote:
      > Hi all:
      > Jeff is correct. Separate QA team can take on the following Responsibilities
      > a) Metrics collection and updates
      > b) Task tracking  and escalate any hidden issues (could be future Risks)
      > c) Forecast future effort overrun / schedule slippage
      > d) Mandate Risk analysis and mitigation
      > e) Tracking Product metrics
      > f) Defect tracking and reporting
      > g) Selecting the right tools and technique (Tools evaluation and Reporting)
      > h) Planning and conducting RCA
      >
      > Regards
      > Balaji.C.R
      >
      > -----Original Message-----
      > From: Jeff Sutherland [mailto:jeff.sutherland@...]
      > Sent: Saturday, January 29, 2005 4:45 AM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: Re: [scrumdevelopment] Scaling Scrum
      >
      >
      >
      > The independent QA question is an interesting one. Recently, I was
      > asked to come up with a way to present Gantt charts to our Metascrum,
      > which meets once and week and includes the senior management team,
      > product owners, development leads, and install and support leads. Here
      > the release decisions are made.
      >
      > I spent a lot of time trying to automate Gantt charts using Microsoft
      > Project as a front end, despite the fact the one of the main goals of
      > the first Scrum was to drive a silver stake through the heart of the
      > Gantt chart and Microsoft project.
      >
      > It turns out that a Gantt chart is a good decision making tool for
      > management. It's just that they are always wrong by the end of the day
      > they were created. So my goal was to deliver a real time Gantt chart
      > that automatically reflected reality every time it was looked at.
      > There would be no human involvement in creatiing the Gantt chart. To
      > make a long story short, Microsoft Project has an inadquate import
      > capability but Excel does a reasonable job.
      >
      > The first Gantt charts created automatically showed the delivery dates
      > of the next two releases. They were absolutedly not what management
      > wanted. The problem was clear in the Gantt chart. QA has took many
      > tasks and needed to be offloaded.
      >
      > Since we run overlapping Sprints and every Sprint results in a release
      > of production code (another long story), the management decision was
      > to give every Sprint its own small QA team. We had to increase the
      > size of QA and they took some space of their own and opened it up so
      > there are typically four or five QA teams testing four or five
      > overlapping Sprints that are always in progress. This is what I meant
      > by independent QA, and probably should have used other terminology.
      >
      > So the real time Gantt chart was very effective at getting management
      > decisions made and it resolved the release problems and eliminated
      > most of the QA bottlenecks. QA is part of development and the leaders
      > are at every Scrum of Scrums meeting.
      >
      >
      > On Fri, 28 Jan 2005 15:00:06 -0800, David Roberts <droberts@...>
      > wrote:
      > >
      > >
      > >
      > > Could you elaborate on independent QA please?
      > >
      > >
      > >
      > >
      > > David Roberts
      > >
      > > InnovaSystems
      > >
      > >
      > >
      > >  ________________________________
      > >
      > >
      > > From: Jeff Sutherland [mailto:jeff.sutherland@...]
      > >  Sent: Friday, January 28, 2005 2:43 PM
      > >  To: John Keane
      > >  Cc: scrumdevelopment@yahoogroups.com; Tim.Hagemann.ext@...
      > >  Subject: Re: [scrumdevelopment] Scaling Scrum
      > >
      > >
      > >
      > >
      > > The Scrum of Scrums meeting timing and composition depends on the
      > >  product(s) being delivered. At PatientKeeper we have a tightly
      > >  integrated product. There are two handheld device teams, a web team, a
      > >  clinical repository team, a server team, and other people who work
      > >  with partners who are able to integrate applications into our product.
      > >
      > >  Everthing must work together all at once and we have a high velocity
      > >  team having delivered 50 production releases in 2004. The most
      > >  important daily meeting is the Scrum of Scrums. If a patient
      > >  medication is incorrect on a handheld device, for example, it could be
      > >  life threatening and it could be the result of a failure on the PDA,
      > >  communication with the PDA, server processing, or the integration of
      > >  the server with a third party backend, or the feed of information from
      > >  a third party backend into our forward staging clinical repository, or
      > >  a failure of the third party backend, or communications between any of
      > >  these pieces.
      > >
      > >  Every build is a build of all pieces and we build multiple times a day
      > >  and test against multiple third party backends. Every release is a
      > >  certified set of pieces with independent QA. This forces the Scrum
      > >  teams to be coupled at the hip at a daily meeting which is the first
      > >  meeting of the day for everyone. In fact, everyone attends, and they
      > >  report by teams.
      > >
      > >  At IDX, we had software components that were much more independent and
      > >  the Scrum of Scrums usually met once a week, depending on product
      > >  line. Only ScrumMasters met.
      > >
      > >  Jeff Sutherland
      > >
      > >
      > >  On Fri, 28 Jan 2005 07:40:00 -0800, John Keane <john.keane@...>
      > > wrote:
      > >  >
      > >  >
      > >  >
      > >  > Hi all,
      > >  >  We have a scrum of scrum, but in a lot of ways it is more a status
      > > update
      > >  > v. driven by a shared backlog.  The idea of the shared backlog appeals
      > to
      > > me
      > >  > but I have a few questions on the mechanics:
      > >  >
      > >  > 1)       Does the team do Planning/Review type meetings or is it more a
      > >  > standing meeting that doesn't operate in sprints?
      > >  >
      > >  > 2)       In the case of a small group of scrum leaders (we have 9
      > scrums
      > >  > running currently), should you just have the standing meeting time and
      > >  > people's role changes as items that they own move on and off the shared
      > >  > backlog?
      > >  >
      > >  > 3)       What frequency do you meet for the scrum of scrums? I am not
      > >  > looking for the "Whenever make sense" answer just wondering how most
      > > people
      > >  > do it.
      > >  >
      > >  >
      > >  >
      > >  > Thanks in advance for everyone's time.
      > >  >
      > >  >
      > >  >
      > >  >
      > >  > John Keane
      > >
      > >
      > >  To Post a message, send it to:   scrumdevelopment@...
      > >  To Unsubscribe, send a blank message to:
      > > scrumdevelopment-unsubscribe@...
      > >
      > >
      > >
      > >
      > >
      > >
      > >  To Post a message, send it to:   scrumdevelopment@...
      > >  To Unsubscribe, send a blank message to:
      > > scrumdevelopment-unsubscribe@...
      > >
      > >
      > >  ________________________________
      > >  Yahoo! Groups Links
      > >
      > > To visit your group on the web, go to:
      > > http://groups.yahoo.com/group/scrumdevelopment/
      > >
      > > To unsubscribe from this group, send an email to:
      > > scrumdevelopment-unsubscribe@yahoogroups.com
      > >
      > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      >
      >
      > --
      > Jeff Sutherland, Ph.D.
      > CTO PatientKeeper Inc.
      > Certified ScrumMaster Practitioner and Inventor of the Agile Scrum Process
      > Microsoft Business Framework Advisory Council
      > Object Management Group/HL7 Liaison Committee
      > Co-Chair, HL7 Orders and Observations Technical Committee
      > Co-Investigator, Operating Room of the Future, Univ. of Maryland Medical
      > System
      > 617-947-7400 mobile
      > jeff.sutherland@...


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



    • kschwaber
      Jeff Sutherland and I are concerned. Many organizations are now trying to scale Scrum to larger projects and to entire organizational units, reaping the
      Message 80 of 80 , Oct 30, 2014
      • 0 Attachment

        Jeff Sutherland and I are concerned. Many organizations are now trying to scale Scrum to larger projects and to entire organizational units, reaping the benefits they have seen in smaller Scrum initiatives. 


        Unfortunately, there isn't a lot of guidance on how to do this. This has given rise to IBM's methodological response to DevOps, and to commercial one-size-fits all methodologies like SAFe and DAD. 


        To read more about how we intend to fill this need in a manner consonant with the Agile Manifesto and the principles of Scrum, I refer you to a blog I wrote at Scaling Scrum.

         

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