Re: Questions re Scrum, please help.
- --- In email@example.com, Bas Vodde <basv@...> wrote:
> In practice, people tend to execute scrum in an annoying mentalmodel
> called "project". The thing with "project" is that it tends tohave a
> definite start, end, goal and thus some kind of content.(otherwise it
> wouldn't be "project" anymore). IMHO this often leads to extrafeatures
> and much other waste. It often leads to product owners to continuewith
> stuff in the product backlog because it "is part of the project".Hi Bas:
Very nice point.
> Related: in lean production, I wouldn't call eliminatingoverproduction
> a principle though. Eliminating waste is and overproduction isIt's a
> identified as the mother of all waste. Same with minimizing WIP.
> result of removing the waste.You are correct, I should not have called those principles. They
are more results you want to achieve. I incorrectly called them
principles because one of the most pragmatic advice I have seen work
for people is to give them a goal and then see how the team is doing
for achieving the goal. Sometimes this is easy, but more often
there are impediments to the goal. Seeing the difference between
where they are and what they want helps them see the impediment and
remove it. Otherwise they sometimes just think - this is as good as
I can do. I think of principles as things to follow and doing what
I just described is a "thing to follow" (but not a principle).
In this case, I was thinking part of our Scrum retrospection should
always be to see if we delivered some code that wasn't needed or
code that superceded prior code (making the earlier code
unnecessary). In an ideal world this shouldn't happen. But I have
seen teams not quite recognize the need for a full-time available
product owner make some customer decisions themselves on the basis
that the customer wasn't available. I've also seen developers put
in extra features with the claim - "well I was in there anyway and
it didn't cost anything" (forgetting the several times more price
they are going to pay in maintenance). In both cases, seeing that
they have wasted their time may eventually convince them that
following the Scrum practice of the product owner deciding the
priorities is a good idea. One of my favorite quotes is from Jeff
"The task then is to refine the code base to better meet customer
need. If that is not clear, the programmers should not write a line
of code. Every line of code costs money to write and more money to
support. It is better for the developers to be surfing than writing
code that won't be needed. If they write code that ultimately is not
used, I will be paying for that code for the life of the system,
which is typically longer than my professional life. If they went
surfing, they would have fun, and I would have a less expensive
system and fewer headaches to maintain."
Few programmers truly embrace this.
This makes me realize the difference between an agile transition and
an agile transformation. When I first started coaching teams in
Scrum it was something they wanted to do. It was more of a
transition. It was often very small teams and isolated at that.
Getting them to apply Scrum practices was relatively straight
forward and easy. As we now are transforming companies to agile
with Scrum I would say the task is different. Most of the
difficulty is actually getting people to understand why they should
be doing what they should be doing. People only do things that:
1) make them right
2) are in their best interest
Aligning the teams with management in order to transform the
enterprise requires unifying principles.
CEO, Net Objectives