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

22765Re: [scrumdevelopment] Scrum "D" and Lean

Expand Messages
  • Robin Dymond
    Jul 31, 2007
    • 0 Attachment
      Thanks Mike.
       
      It is a very interesting case study. I think the experience points out the weakness that I have been thinking and posting (occasionally) about for a while - "the mystical omniscient enterprise product owner." I worked hard to find the "right person" for the PO who new the processes inside out. In fact we ended up getting another one from a different area as well to ensure another group's needs were visible. The customer team members were well intentioned and smart. What none of us (IT) realized was how broken the operations process was. A critical issue was also picking the tool based on features that were in the next release (that was very late). This broke the principle of deciding as late as responsibly possible. But part of the agenda was to go COTS. If we had gone with a set based approach we might have had a different outcome because we would have been able to get closer to the customer requirements more quickly with a custom application.
       
      Interestingly, we had process engineers on the IT project team, and they were ineffective at moving the needle in this area. However on the lean project they were key players, and IT less effective.
       
      My perspective has been changed by lean. If IT is an accelerator, it is only as effective as the processes and operations surrounding it. This is a very different perspective than what I have seen in the enterprise COTS space, where people are re-designing processes around the app.
       
      Also interesting is that the lean project required as much change management as any large Agile project I have seen. Lots of behaviors need to change along the way.
       
      cheers,
      Robin Dymond.
       
      On 7/31/07, mike.dwyer1@... <mike.dwyer1@...> wrote:

      Robin
      First Good job. you ran hard -  hit a wall and found out where the edge of the envelope is.  Now move the edge, that is the great part of Scrum, inspect and adapt.
       
      Second, it sounds like the business community was on the ball.  They fired the 'single chokeable throat' twice, dumped a frame work that was not working in their environment and found one that would.
       
      Finally, have you held a retro on this?  have you figured out that the organization you are working in does not have enough self discipline at the level you are trying to work at to support the Scrum frames you employed?  have you talked with the 6 sigma people to see what they did with the Root Cause information? did any of this information surprise you?  Why?  What can you learn from their root cause process that will make Scrum better.
       
       
      --
      Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life


      The greatest oak was once a little nut who held its ground. ~Author Unknown
       
       
      -------------- Original message --------------
      From: Bas Vodde < basv@...>

      > Why you didn't make the customer the product owner?
      >
      > Bas
      >
      > Robin Dymond wrote:
      > >
      > >
      > > So, there was this project. We used scrum. We used a new COTS tool. We
      > > started the work based on our expert product owner's direction. We
      > > demonstrated the software to our product owner, she was OK with it.
      > > After 3 iterations we piloted it with customers, and they hated it. This
      > > was the first big clue we did not take. The business stakeholders
      > > decided to change the product owner, and so she became a key
      > > stakeholder, and the visonary became the product owner. But the
      > > visionary didn't want to show any more software to the customers until
      > &gt ; it was just right, and the COTS tool's much anticipated config features
      > > were completed and shipped by the vendor. So we no longer showed
      > > features to the customers, only the visionary, who did not know the
      > > work. In the spring the project was cancelled. The project was replaced
      > > by a Lean process redesign and implementation initiative. This Lean
      > > process redesign effort has been very successful so far. It is fixing
      > > problems that were out of reach of the team, and the product owners. It
      > > is addressing the ROOT CAUSE of the problems in the business area. The
      > > COTS vaporware arrived too late, but more importantly, the
      > > implementation was based on a faulty premise, that the product owner
      > > would and could know what to do. The team spent hundreds of hours
      > > automating a business process that was full of hand-offs, waiting, over
      > > pr oduction, highly manual, etc.
      > >
      > > To me this is a vivid personal experience of how Agile methods can
      > > really fail to deliver what the business needed. IT set out to solve the
      > > wrong problem, and the smart, engaged business leaders did not know
      > > enough to recognize that. If you are doing enterprise software for
      > > business automation, then Lean is just as important as Scrum to ensure
      > > you have the right processes, the right backlog and the right business
      > > agenda for technology to accelerate.
      > >
      > > Regards,
      > > Robin Dymond.
      > > www.innovel.net
      > >
      > > On 7/30/07, *Ken Schwaber* < ken.schwaber @verizon.net
      > > > wrote:
      > >
      > > Scrum is a very simple process for managing complex work. It has
      > > many areas in which it is quiet , such as engineering practices,
      > > planning and estimating approaches, risk management, and others
      > > because these are situational, dependent on who is using Scrum when.
      > > People will fill in these blanks and come up with a process or
      > > approach that helps them accomplish their results best, keeping in
      > > mind that Scrum will keep pointing out when they are deficient so
      > > they can continually improve their concocted process. To say there
      > > is a Scrum "A", "B", "C" or otherwise is to say that there are
      > > multiple foundations on which to build, when the base Scrum –
      > > described in the literature – is more than adequate. I believe that
      > > thinking this way will help us avoid the babble of OO in its early
      > > years, and also people who "modify" Scrum to remove its most
      > > important elements.
      > >
      > >
      > >
      > > As for the connection between Lean and Scrum: you and others know
      > > lean. You look at Scrum and you can see lean in it. You use lean
      > > words and thinking to describe what you see. Great. However, Scrum
      > > isn't based on lean, it just exemplifies some of it as you see it.
      > >
      > >
      > >
      > > Ken
      > >
      > >
      > >
      > > ------------------------------------------------------------------------
      > >
      > > *From:* scrumdevelopment@yahoogroups.com
      > >
      > > [mailto:scrumdevelopment@yahoogroup s.com
      > > ] *On Behalf Of *Alan Shalloway
      > > *Sent:* Monday, July 30, 2007 1:47 PM
      > > *To:* scrumdevelopment@yahoogroups.com
      > >
      > > *Subject:* [scrumdevelopment] Re: Scrum Evolution: Type A, B, and C
      > > Sprints
      > >
      > >
      > >
      > > --- In scrumdevelopment@yahoogroups.com
      > > , "Ken Schwaber"
      > > wrote:
      > > >
      > > > There is only one Scrum,
      > >
      > > Ken:
      > > I am not sure how to interpret this. Are you saying that it is all
      > > Scrum regardless of where it is applying or that there is only one
      > > Scrum as defined by some person or body. Please explain more fully.
      > > Thanks,
      > >
      > > Alan Shalloway
      > > CEO, Net Objectives
      > > Gold Sponsor Agile 2007
      > >
      > >
      > >
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      > <* gt; 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:
      > mailto: scrumdevelopment-digest@yahoogroups.com
      > mailto:scrumdevelop ment-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/
      >
      / html>


    • Show all 11 messages in this topic