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

RE: [scrumdevelopment] Grass roots upbringing

Expand Messages
  • Matt Yenn
    ... their ... engineers ... The ... but ... budget. ... That should probably read This makes for extreme agility . There really isn t a defined process just
    Message 1 of 6 , Apr 27, 2005
    • 0 Attachment
      >> My company uses a 'just get-it-done' and 'lets not worry about formality'
      >> mentality.  The original owners came from within a company that took
      >> 6-months to send a simple quote because of too much paper pushing.  The
      >> original company ended up closing (go figure). They vowed to never let their
      >> company become bureaucratic!   Hence, the company has one or two engineers
      >> do all of the work for each project from design to documentation to
      >> implementation to testing.  This makes for an extremely agile process.  The
      >> problem is when projects get bigger,i.e. complex, everyone wants agility but
      >> that tends to push the ship date way out and makes the project over budget.
      >
      >In my experience, true agile methods neither increase budget nor
      >push the date
      out. Tell us more about your "agile" process, please.
       
      That should probably read 'This makes for extreme agility'.  There really isn't a defined process just a self generated long task list.  A task list can be changed and reprioritized very easily. Since the teams are 1-2 engineers there can be very little internal documentation.  Works good for most of our projects.       
       
      Large projects seem to always have issues- engineers coming and going within projects - teams sitting around debugging one persons code - marketing needing premature demos that cut into development time etc.  They become very inefficient very fast.
       
      To me it sounded like we needed better project management... But I'd only tried traditional project management a couple of times.  Each time the chart was totally off within a couple of days because of requirements, servicing other projects, poor estimation, etc.  Not only that but, the older engineers always balked at the idea, and they were usually right...  I spent time planning to work which meant I wasn't working.  So back to the task list and just 'get-er-done' attitude...
       
      The other problem with the 1 man show is: knowledge doesn't travel between engineers very well, egos with architectural decisions, code doesn't get reused, customers see different interfaces from the same company etc. It all boils down to the company being very agile but the customers value isn't as high as it should be...  
       
      >> So, in my scenario im not reducing project management formality, I'm
      >>
      fighting to increase it.  Has anyone ever done this with scrum before?
      >> Also, I believe the VP of engineering wants to increase
      formality BUT, he
      >> wants to use traditional
      processes...
      >
      >What kind of formality are you looking for, and what
      do you imagine
      >it will give you that you do not now
      have?

         
      Formality...I guess the goal isn't formality but the ability to handle large(r) projects while being agile with customer requirements and increase the value of the product to the customer.  I see this happing through the use of teams... but in my experience and my company's experience teams mean long meetings, lots internal documentation, hierarchical system design, etc.  I feel the VP is ready to succumb to doing just that to stop the bigger projects from getting out of hand.  But I see this as just as bad as the 1 man show.  I want to try scrum with a couple of the engineers on a smaller project. And maybe not full scrum...more of introducing the concepts slowly so I don't buck the system. 
       
      So I was curious if anyone had started introducing scrum (or other agile processes) with success that way.... Or should I present the idea and try and get approval that way. 
       
      Also is the agile only used in software development or are there examples in other industries?
       
       
      Thanks
      Matt
       
       
       
       
       
       -----Original Message-----
      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com]On Behalf Of Ron Jeffries
      Sent: Wednesday, April 27, 2005 1:25 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Grass roots upbringing

      On Wednesday, April 27, 2005, at 12:42:07 PM, Matt Yenn wrote:

      > My company uses a 'just get-it-done' and 'lets not worry about formality'
      > mentality.  The original owners came from within a company that took
      > 6-months to send a simple quote because of too much paper pushing.  The
      > original company ended up closing (go figure). They vowed to never let their
      > company become bureaucratic!   Hence, the company has one or two engineers
      > do all of the work for each project from design to documentation to
      > implementation to testing.  This makes for an extremely agile process.  The
      > problem is when projects get bigger,ie complex, everyone wants agility but
      > that tends to push the ship date way out and makes the project over budget.

      In my experience, true agile methods neither increase budget nor
      push the date out. Tell us more about your "agile" process, please.

      > So, in my scenerio im not reducing project management formality, I'm
      > fighting to increase it.  Has anyone ever done this with scrum before?
      > Also, I believe the VP of engineering wants to increase formality BUT, he
      > wants to use traditional processes...

      What kind of formality are you looking for, and what do you imagine
      it will give you that you do not now have?

      Ron Jeffries
      www.XProgramming.com
      Replacing an on-site customer with some use cases is about as effective
      as replacing a hug from your Mom with a friendly note.




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


    • Chamberlain, Eric
      Seems like what is needed is not more formality but closer tracking and closer collaboration with the customers. From your description, the problem has turned
      Message 2 of 6 , Apr 27, 2005
      • 0 Attachment
        Seems like what is needed is not more formality but closer tracking and closer collaboration with the customers.
         
        From your description, the problem has turned into a engineer-centric development rather than a customer-centric development ethos.  It has been mentioned before but the prioritization by the customer of the backlog makes sure the important stuff happens earlier.  The time-boxing, with a demo to the customer at the end deals with the development visibility.  In this vein, it is the Product Owner's position as representing the customer that comes to the fore.  The PO has to be respected as a truely representative of the customer and as the one who can effectively set the priorities.
         
        Software is fun but it's not all about us. It's all about delivering quality to the customer.
         
          == Eric C. ==


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Matt Yenn
        Sent: Wednesday, April 27, 2005 12:51 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: RE: [scrumdevelopment] Grass roots upbringing

        >> My company uses a 'just get-it-done' and 'lets not worry about formality'
        >> mentality.  The original owners came from within a company that took
        >> 6-months to send a simple quote because of too much paper pushing.  The
        >> original company ended up closing (go figure). They vowed to never let their
        >> company become bureaucratic!   Hence, the company has one or two engineers
        >> do all of the work for each project from design to documentation to
        >> implementation to testing.  This makes for an extremely agile process.  The
        >> problem is when projects get bigger,i.e. complex, everyone wants agility but
        >> that tends to push the ship date way out and makes the project over budget.
        >
        >In my experience, true agile methods neither increase budget nor
        >push the date
        out. Tell us more about your "agile" process, please.
         
        That should probably read 'This makes for extreme agility'.  There really isn't a defined process just a self generated long task list.  A task list can be changed and reprioritized very easily. Since the teams are 1-2 engineers there can be very little internal documentation.  Works good for most of our projects.       
         
        Large projects seem to always have issues- engineers coming and going within projects - teams sitting around debugging one persons code - marketing needing premature demos that cut into development time etc.  They become very inefficient very fast.
         
        To me it sounded like we needed better project management... But I'd only tried traditional project management a couple of times.  Each time the chart was totally off within a couple of days because of requirements, servicing other projects, poor estimation, etc.  Not only that but, the older engineers always balked at the idea, and they were usually right...  I spent time planning to work which meant I wasn't working.  So back to the task list and just 'get-er-done' attitude...
         
        The other problem with the 1 man show is: knowledge doesn't travel between engineers very well, egos with architectural decisions, code doesn't get reused, customers see different interfaces from the same company etc. It all boils down to the company being very agile but the customers value isn't as high as it should be...  
         
        >> So, in my scenario im not reducing project management formality, I'm
        >>
        fighting to increase it.  Has anyone ever done this with scrum before?
        >> Also, I believe the VP of engineering wants to increase
        formality BUT, he
        >> wants to use traditional
        processes...
        >
        >What kind of formality are you looking for, and what
        do you imagine
        >it will give you that you do not now
        have?

           
        Formality...I guess the goal isn't formality but the ability to handle large(r) projects while being agile with customer requirements and increase the value of the product to the customer.  I see this happing through the use of teams... but in my experience and my company's experience teams mean long meetings, lots internal documentation, hierarchical system design, etc.  I feel the VP is ready to succumb to doing just that to stop the bigger projects from getting out of hand.  But I see this as just as bad as the 1 man show.  I want to try scrum with a couple of the engineers on a smaller project. And maybe not full scrum...more of introducing the concepts slowly so I don't buck the system. 
         
        So I was curious if anyone had started introducing scrum (or other agile processes) with success that way.... Or should I present the idea and try and get approval that way. 
         
        Also is the agile only used in software development or are there examples in other industries?
         
         
        Thanks
        Matt
         
         
         
         
         
         -----Original Message-----
        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com]On Behalf Of Ron Jeffries
        Sent: Wednesday, April 27, 2005 1:25 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: Re: [scrumdevelopment] Grass roots upbringing

        On Wednesday, April 27, 2005, at 12:42:07 PM, Matt Yenn wrote:

        > My company uses a 'just get-it-done' and 'lets not worry about formality'
        > mentality.  The original owners came from within a company that took
        > 6-months to send a simple quote because of too much paper pushing.  The
        > original company ended up closing (go figure). They vowed to never let their
        > company become bureaucratic!   Hence, the company has one or two engineers
        > do all of the work for each project from design to documentation to
        > implementation to testing.  This makes for an extremely agile process.  The
        > problem is when projects get bigger,ie complex, everyone wants agility but
        > that tends to push the ship date way out and makes the project over budget.

        In my experience, true agile methods neither increase budget nor
        push the date out. Tell us more about your "agile" process, please.

        > So, in my scenerio im not reducing project management formality, I'm
        > fighting to increase it.  Has anyone ever done this with scrum before?
        > Also, I believe the VP of engineering wants to increase formality BUT, he
        > wants to use traditional processes...

        What kind of formality are you looking for, and what do you imagine
        it will give you that you do not now have?

        Ron Jeffries
        www.XProgramming.com
        Replacing an on-site customer with some use cases is about as effective
        as replacing a hug from your Mom with a friendly note.




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


      • Ron Jeffries
        ... Well, there s a lot more to being agile than having a long task list. I don t know of any agile method that recommends that the list be self-generated, to
        Message 3 of 6 , Apr 27, 2005
        • 0 Attachment
          On Wednesday, April 27, 2005, at 3:50:49 PM, Matt Yenn wrote:

          >>In my experience, true agile methods neither increase budget nor
          >>push the date out. Tell us more about your "agile" process, please.

          > That should probably read 'This makes for extreme agility'. There really
          > isn't a defined process just a self generated long task list. A task list
          > can be changed and reprioritized very easily. Since the teams are 1-2
          > engineers there can be very little internal documentation. Works good for
          > most of our projects.

          Well, there's a lot more to being agile than having a long task
          list. I don't know of any agile method that recommends that the list
          be self-generated, to begin with. Then there are the practices
          around choosing what to do next, which is business-oriented, not
          done by the techies. Then there is the extensive testing. Then ...

          > Large projects seem to always have issues- engineers coming and going within
          > projects - teams sitting around debugging one persons code - marketing
          > needing premature demos that cut into development time etc. They become
          > very inefficient very fast.

          I would agree that those things are unproductive. I'm not sure what
          traditional project management would have to do with them, though.

          > To me it sounded like we needed better project management... But I'd only
          > tried traditional project management a couple of times. Each time the chart
          > was totally off within a couple of days because of requirements, servicing
          > other projects, poor estimation, etc. Not only that but, the older
          > engineers always balked at the idea, and they were usually right... I spent
          > time planning to work which meant I wasn't working. So back to the task
          > list and just 'get-er-done' attitude...

          The thing is, the traditional project management chart will
          //inevitably// be off within a few days. It's not because people
          aren't working hard or being managed enough. It's that the technique
          does not work for software development.

          It might work for building bridges and tunnels. How did the Big Dig
          do on time and budget?

          > The other problem with the 1 man show is: knowledge doesn't travel between
          > engineers very well, egos with architectural decisions, code doesn't get
          > reused, customers see different interfaces from the same company etc. It all
          > boils down to the company being very agile but the customers value isn't as
          > high as it should be...

          This must be some new definition of agile that I wasn't previously
          familiar with. I believe that the Agile Manifesto begins with
          "Individuals and Interactions". Agile is not, never has been, never
          will be, a one man show, ego driven, multiple interface approach.

          I believe the technical term for the approach you are describing is
          "Chaos", first described by the Software Engineering Institute many
          years ago. The SEI's approach to improving from Chaos is not the
          same as the Agile approach, but we are both definitely opposed to
          Chaos.

          >>> So, in my scenario im not reducing project management formality, I'm
          >>> fighting to increase it. Has anyone ever done this with scrum before?
          >>> Also, I believe the VP of engineering wants to increase formality BUT, he
          >>> wants to use traditional processes...
          >>
          >>What kind of formality are you looking for, and what do you imagine
          >>it will give you that you do not now have?

          > Formality...I guess the goal isn't formality but the ability to handle
          > large(r) projects while being agile with customer requirements and increase
          > the value of the product to the customer. I see this happing through the
          > use of teams... but in my experience and my company's experience teams mean
          > long meetings, lots internal documentation, hierarchical system design, etc.
          > I feel the VP is ready to succumb to doing just that to stop the bigger
          > projects from getting out of hand. But I see this as just as bad as the 1
          > man show. I want to try scrum with a couple of the engineers on a smaller
          > project. And maybe not full scrum...more of introducing the concepts slowly
          > so I don't buck the system.

          Scrum itself is a partial method, in the sense that it needs to be
          backed up by good internal technical practices that support the
          iterative nature of Scrum. Scrum, in most authors' hands, is
          agnostic about what those technical practices need to be. Mike
          Beedle, a Scrum founding thinker, is now talking and writing about
          technical practices that need to be part of Scrum. These practices
          remind me of some of the other Agile methods that are not so
          agnostic about technical practices.

          I would be very very cautious before implementing "part of" Scrum.
          I'm not sure what that would mean. I would be concerned that the new
          process would be unstable.

          > So I was curious if anyone had started introducing scrum (or other agile
          > processes) with success that way.... Or should I present the idea and try
          > and get approval that way.

          If management understands that they have trouble, and are open to
          learning, I would strongly suggest getting some Agile spokesmodel to
          come in, assess your existing process, and do some executive
          briefings on the agile methods and what they mean to management, and
          to the development organizations.

          And I'd suggest getting some expert coaching in the details of doing
          it, or at least taking some courses on the subject.

          > Also is the agile only used in software development or are there examples in
          > other industries?

          Similar ideas are found in so-called "Lean" manufacturing, and Agile
          software methods are likely based on those ideas. There are people
          trying to figure out other agile notions, like "agile project
          management".

          Ron Jeffries
          www.XProgramming.com
          Learn from yesterday, live for today, hope for tomorrow.
          The important thing is to not stop questioning. --Albert Einstein
        • Mike Dwyer
          Let s not confuse sitting around the campfire singing KumBYaa as Agile. Agile, by its very nature, is extremely SELF Disciplined, which means (in my house
          Message 4 of 6 , Apr 27, 2005
          • 0 Attachment
            Let's not confuse sitting around the campfire singing KumBYaa as Agile.

            Agile, by its very nature, is extremely SELF Disciplined, which means (in my
            house anyway) if you don't understand how to manage what you do, or can't
            perform successfully managing yourself in a professional manner,

            Go home.

            Agile, in my mind, is only for people who respect themselves and their work
            enough to never allow either to slip.

            I may argue with my brethren here, but I always listen to what they say.


            Michael F. Dwyer

            Mike.Dwyer1@...



            -----Original Message-----
            From: scrumdevelopment@yahoogroups.com
            [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Matt Yenn
            Sent: Wednesday, April 27, 2005 12:42 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Grass roots upbringing


            Hey all,

            First some background...

            My company uses a 'just get-it-done' and 'lets not worry about formality'
            mentality. The original owners came from within a company that took
            6-months to send a simple quote because of too much paper pushing. The
            original company ended up closing (go figure). They vowed to never let their
            company become bureaucratic! Hence, the company has one or two engineers
            do all of the work for each project from design to documentation to
            implementation to testing. This makes for an extremely agile process. The
            problem is when projects get bigger,ie complex, everyone wants agility but
            that tends to push the ship date way out and makes the project over budget.

            So, in my scenerio im not reducing project management formality, I'm
            fighting to increase it. Has anyone ever done this with scrum before?
            Also, I believe the VP of engineering wants to increase formality BUT, he
            wants to use traditional processes...

            Also has anyone used scrum for none-software types of development... My
            company writes firmware, VHDL Verilog etc., along with hardware development.

            Thanks
            Matt




            To Post a message, send it to: scrumdevelopment@...
            To Unsubscribe, send a blank message to:
            scrumdevelopment-unsubscribe@...
            Yahoo! Groups Links
          Your message has been successfully submitted and would be delivered to recipients shortly.