22760RE: [scrumdevelopment] Scrum "D" and Lean
- Jul 31, 2007
This is more a problem of the business thinking that IT can solve its problems. The idea of the Product Owner is someone responsible for the ROI of the project. Your PO was interested in getting the work done (old definition of success) rather than providing value. I’m working with an organization to scale its business. It’s product backlog has a large number of process redesigns and then automation. Otherwise you are just automating junk.
From: email@example.com [mailto: firstname.lastname@example.org ] On Behalf Of Robin Dymond
Sent: Tuesday, July 31, 2007 12:19 AM
Subject: Re: [scrumdevelopment] Scrum "D" and Lean
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 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 production, 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.
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.
From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelopment@ yahoogroups. 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"
<ken.schwaber@ ...> wrote:
> There is only one Scrum,
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.
CEO, Net Objectives
Gold Sponsor Agile 2007
- << Previous post in topic Next post in topic >>