RE: RE: Customer involvement and process improvement

> -----Original Message-----
> From: J. B. Rainsberger [mailto:[email protected]]
> Sent: Monday, December 30, 2002 8:27 PM
> To: [email protected]
> Subject: [XC] RE: Customer involvement and process improvement
> 
> 
> One of the goals of frequent/small releases is to get 
> feedback on the appropriateness and correctness of the 
> currently-running software. It is assumed that the customer 
> will provide that feedback, whether directly or indirectly, 
> because they are the expert when it comes to answering the 
> question, "Is this the feature we need?" This is another case 
> where we are confident that they would benefit from even a 
> little more effort, but where they tend (for whatever reason) 
> to underestimate that benefit. So if we had more feedback: 
> (1) the programmers would feel the benefit by having 
> increased confidence that they are doing the right thing and 
> correctly; (2) the customers would feel the benefit by being 
> better able to steer the project; (3) the company would feel 
> the benefit by minimizing time spent building the wrong 
> thing, or building the unimportant thing, even if it is built well.

Incremental delivery is something I would advise as well but I have seen and
still see some problems because you need a customer that is willing and able
to constantly adopt, adapt and apply.  What I mean is that it is not so
obvious that your customer is up to dealing with a new release/increment
every 2 weeks for a very long period of time.  In the particular context
that I am working in, there are seasonal effects which imply the the
customer has little or no resources to assign to "evaluate" new increments
during particular periods and those are the summer period from end of june
until early september (holidays reduce available resources + our business is
holiday related and peaks in the same season), and there are big changes in
airspace/route structure definitions in the low season ( october/november +
january/february ) which means there is lots of data input to be done.
Given this cyclical (annual) recurring patterns, we don't have a lot of
freedom to tell the user when he/she should be looking at the increments we
would like to deliver.

This is not to say we should organise ourselves better, it is just a word of
caution against some over-optimism that may exist about incremental
delivery.

We also see some burnout effects appearing when users are
evaluating/validating the software over and over again.  The attention
sometimes starts to wane.  You get a "not an increment again" kind of
reaction.  It depends also on the kind of changes that are introduced.
Lateral changes (changes that impact many functions) cause a lot of "effort"
to be spent.  Even though the software change may seem trivial, when it
affects many functions that the user has to deal with, all these functions
have to be revalidated.  We've had a couple of those.

So, a story that has a transversal/lateral effect may be small in terms of
programming effort but big in terms of revalidation.

If I would take an extreme example of this, the change may be purely
configurational, e.g. changing a timing parameter, but the effect on the
user/operator could be dramatic (e.g. number of rejected flight plans
doubles).

In complex systems the effects of incremental delivery may be that the user
gets a lot more work to do for little added value (at least from the user
point of view).  Trade-offs have to be made.

So the point of evaluating whether "Is this the feature we need" may not be
conclusive in complex or distributed systems.  But it can limit the
uncertainty about a feature up to a level.

What I also have some trouble with is that XP seems to treat features as if
they were functionally independent.  I've got a lot of trouble with that
concept.  E.g. take adding a new "object" to a database.  Most likely this
object will have associations and corresponding business validation rules
coming along with it that provide syntactical and semantical correctness
(not to forget database integrity).  Adding a story that requires a new
object, or even a new attribute, may seem like a "small incremental issue"
but I've seen otherwise.  For the sake of business continuity it may be wise
to couple a few of these changes together to allow a complete and thorough
"validation" as it will make this validation more efficient and effective.

I still don't see how XP addresses the needs of dependency management
between different stories.

> 
> Another goal of frequent/small releases is for the 
> programmers to get periodic feedback on the accuracy of their 
> estimates, through iteration retrospection and iteration 
> planning. It has been shown that estimating smaller units of 
> work more often leads to more accurate estimation on the 
> whole: sporadic errors tend to cancel out and systematic 
> errors tend to be uncovered more quickly. The risk of not 
> knowing our real progress is mitigated by computing our 
> velocity often. We need to release the software in order to 
> do this, otherwise there is no (external) motivation to 
> ensure that features are 100% correct. This avoids the 
> all-too-common "90% syndrome", where every feature is 90% 
> complete and nothing really works. So the programmers feel 
> benefit by finishing features completely along the way, 
> rather than tying up many loose ends near the end -- 
> something they won't be good at, since they'll have forgot 
> the details of what the feature needed to do. The project 
> planners feel bene!
> fit by having more information earlier about the progress of 
> the project *and* that information will be empirical, not 
> depending on some programmer's hunch. I have learned to trust 
> the numbers, even if I think I can go faster.

But you don't necessarily need customers for this.  You can imagine a set-up
of independent testers/quality control people that do the same thing.  This
alleviates also the problem of burning-out the customer by making frequent
releases during peak periods.  I think most organisation are trying to make
their operational/production organisation lean and mean but this leaness
means that resources are usually stretched already.  Experienced, qualified,
and motivated 'testers' may better suit these needs.  The advantage is that
they can provide the numbers you are looking for even faster.

In our particular context, such independent test teams are composed with
software people and operators jointly and operator participation will change
in function of operational capacity requirements.

There are also other ways to measure what one has achieved like in earned
value based measurements (perhaps also in balanced scorecards).
Reliance on a "customer" may also be wrong because not all customers can
represent the whole of the business process and may not be "objective"
enough (whatever that means in terms of quality assessment anyway) all of
the time.  Earned value and balanced scorecards are not that dependant on
human "state of being" and that's why I would say they are more objective.

> 
[snip]

> >> that the customer needs to know up front what's expected, 
> and either
> >> they're willing to commit (we can do XP) or they are not 
> (we can't).
> >We
> >> admit that without a customer*, the project is dead in the 
> water, XP
> >or
> >> not.
> >
> >[>] Oh I'm not sure this is the case. If XP requires a fully 
> cognizant
> >XP customer, the population is now very small for the XP 
> practices. What
> >about customer that move in and out of XP? Have needs not 
> supported by
> >XP? Etc.
> 
> I don't understand how a customer moves in and out of XP -- 
> can you clarify what you mean here?

I could imagine that the customers may not always be able to be a perfect XP
customer.  Is always available when the operational capacity requirements
allow, is not when it doesn't.  I think it is still beneficial to involve
such customers if it is the best one can get.

> 
> As for needs not supported by XP, can you name a few of those 
> needs? The XP practices largely deal with managing the 
> programming aspect of a software project as well as building 
> the software itself. For "other needs" not directly related 
> to these aspects programming team, the XP practices were not 
> intended to handle those needs, anyhow. Still, XP is more 
> than the practices -- it's a philosophy, an approach that can 
> be used in daily life, let alone to address those needs you mention.

And there are many other approaches that can be used in daily life jointly
or seperately with XP approaches.  I don't think there is a "one approach
covers all needs" hero.  Improvement doesn't stop with introducing XP or
doesn't even have to start with it.
> 
> >[>] Sure. First I'd start with asking and answering some questions. 
> >
> >For the ongoing feedback to have value, we'll need to define the
> >improvement goal. Schedule, budget, requirements, quality, other
> >intangible attributes. For what purpose is the feedback 
> being provided
> >and solicited?
> 
> See my comments above. There is more, but we can explore that 
> as we go.

I think we also better define the context because I see the "comments above"
as easy to apply in some contexts but not so easy as it may seem in other.
> 
> >How will we know when the ongoing feedback is producing
> >results?
> 
> One way to know is to compare the XP project's progress to 
> historical results. I won't claim that this will indicate 
> that ongoing feedback *alone* is responsible, but we 
> recognize that it's generally impossible to attribute 
> improvement to such an individual aspect of the team's 
> operation, so we don't worry about that too much.

If everything changes as fast as XP claims (embrace change) than what value
does comparing with historical results have?  What is the goal of this
comparison, what does XP want to measure?  After long discussions with many
people on different mailing lists I still have trouble to understand what
kind of measurements XP is promoting (apart from velocity that is and
running 100% of the tests successfully all of the time).
> 
> >What results are we after?
> 
> We would like to minimize the time it takes for a requested 
> feature to be available to deliver into production, 
> concentrating on making *valuable* features (as defined by 
> the business) available more quickly.

Should the word minimise not be replaced by optimise?
I think there is a minimum beyond which efficiency and effectiveness of
incremental delivery deterioriate.  This minimum will depend on context but
I would like to insist that such a minimum exists.  If this minimum did not
exist, why wouldn't we deliver increments to the users 3 times a day?
> 
> >Once the results goal is defined,
> >how will we plan each cycle of the feedback process to move 
> us forward?
> 
> Every two or three weeks, we will give the business an 
> opportunity to do two things: evaluate how well the 
> programmers implemented and delivered the recently-requested 
> features and decide which features are the most important 
> ones to implement next. We'll meet for half a day, 
> demonstrate the features we have completed, provide a working 
> copy for the business to evaluate on their own time, then 
> review the remaining features, estimate their cost and let 
> the business use that information to decide what to do next.

I think the process has value but I don't know if the timing should not be a
function rather than a constant of 2/3 weeks.

Could you perhaps also explain what "on their own time" means?  How flexible
are you on this?
> 
> <snip />
> >[>] In our Balanced Scorecard we have a role called "performance
> >advocate." This person is assigned to be the advocate of the process
> >improvement portion of the BSC. This may be the approach 
> that could work
> >for you. 
> >
> >I would suggest though (as we have learned) that the "problem" be
> >defined before the solution is provided. XP looking for 
> problems is no
> >different than a hammer looking for nails to hit.
> 
> "XP" does not do that. XP is a response to felt needs. XP 
> solves problems so engrained in the software development 
> industry, that I fear that the community has got used to the 
> problems and no longer regards them as problems. In that 
> case, what can we do?

I think we are starting to talk about process improvement here.  From the
few things I've read there seem to be other alternatives regarding treating
the inherent problems of software development.  I've just started reading
about PSP and TSP and I am favourably impressed.

Whether XP actually solves the problems?  I don't know.  Perhaps it has a
way of addressing the symptoms but perhaps the problems are inherently
human.  After all, without humans, who would make the mistakes that causes
the defects in the software?  How does one make sure that the defects are
removed as efficiently and effectively as possible?  XP certainly addresses
a couple of defect detection/removal strategies, but there are strategies
that have shown their usefulness which are not addressed by XP or not in the
same way.

> 
> >So type of "gap"
> >analysis for the "product" may be the starting point. 
> Getting by-in that
> >a gap analysis is needed is the first step in isolating the 
> "felt need."
> 
> So you need to convince other people that you have a problem 
> instead of just saying, "I have a problem?" Oy. Maybe I misunderstand.

Perhaps we have to consider magnitudes of scale here.  Perhaps it is not
about me and you but about us and them.

If we say "I have a problem" it may not sound very well.  If we say
"Houston, we have a problem" it may get people involved.

I try to solve the problems I have and own.  Sometimes I have a problem
which I don't own so I cannot solve it.  I guess you understand where this
leads to.
> 
> >Once the gaps have been identified, "owning" those gaps is 
> necessary. We
> >have that problem all the time and rightly reject improvement for
> >improvement sake. "I know that process suck, but it'll continue to do
> >that because there is not bookable savings to fix it..."
> 
> So because you don't know exactly how much you'll gain from 
> changing how you do things, you don't stop doing actively and 
> obviously stupid things? That just sounds silly. It's the 
> kind of thing that immediately sounds wrong.

I don't know if this what was meant.  It can be misunderstood.  I think we
have to distinguish the problems we own from the problems owned by someone
else.  We can suffer from problems that are inherent to the organisation
(e.g. high ceremony) but we cannot solve them because they are in the nature
of it and they are required by the external world.  It's not about levels of
silliness, it is about levels of ownership.

Anyway, what I experience as a problem may be there because it has business
value.  I.e. removing the problem may have a negative business value.

To the extreme I see my having to work to earn money as a problem but I
guess I'm stuck with it unless I win the lottery, inherit, or steal ;-)
> 
> >Once the "bookable savings" or "measurable improvements" are 
> identified,
> >THEN a process improvement process can start.
> 
> I get the feeling that this approach assumes that those on 
> the front line aren't capable of making good decisions about 
> how to improve the process at the lower levels. It looks like 
> a centralized decision-making approach that is, I think quite 
> plainly, doomed to failure, because the decision makers don't 
> understand the problems.

But does one at the bottom see all the problems (and understand them) of the
decision makers?  There are different problems depending on different scopes
and different perspectives.  Seeing the multi-facetted reality from
different perspectives is a big challenge.  It is easy to make changes at
the bottom level but not oversee the consequences at a different level and
vice versa.  I doubt it that many people can see end-to-end.  The software
may have become the business (in that there is not business if the software
doesn't run) but to me this still doesn't mean that every developer can see
the consequences of the changes he thinks are "so easy to make".
> 
> Alistair Cockburn's talk about the importance of 
> microtechniques applies here. Most process improvements are 
> not overhauls, but a longer series of small changes that try 
> to take advantage of short- and medium-term trends to 
> maximize effectiveness. In this case, it is impossible to 
> calculate bookable savings, although improvements are easily 
> noticed without being measurable. Are you saying that we 
> shouldn't improve things because the Big Bosses can't be sure 
> exactly how much a different it makes? Unless they join the 
> front line, they'll never, ever know, because it all depends 
> so much on "here and now".

I detect a sort of an attitude problem.  "Big Bosses" terminolgy seems to
imply that they are not prepared to listen to your input.  I think that many
of these "Big Bosses" as you label them do not have a problem in allowing
you to change things as long as you can give them the feedback they need.
Improvements can only be measured if you know where you are now.  This means
you need some measurements before you can demonstrate your changes lead to
improvement.  There are different techniques to do that.  But changes are
not only a matter of business value.  Organisational changes for instance
can be very painful.  Even though there may be an obvious business value, we
still have people to deal with.

I also don't agree with the "here and now" statement.  Here and now sounds
like crisis management to me.  In such a context you cannot take the same
kind of decisions as in a healthy business environment.  Here again I think
we should consider context.  Introducing a new software development process
and organisation takes time, perhaps it is not the wisest thing to do if
your company is in a crisis situation.  The business people should also be
allowed to find those gaps that need to be filled.
> 
> J. B. Rainsberger,
> President, Diaspar Software Services
> Let's write software that people understand.
> http://www.diasparsoftware.com/
> telephone: +1 416 791-8603
> All correspondence (c) 2002 Diaspar Software Services.
> If you want to use it, just ask; don't steal.

Regards, Stefan Steurs.


____
 
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
 
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL unless it is confirmed by appropriately signed hard copy.
 
Any views expressed in this message are those of the sender.



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Turn flat surfaces into speakers with the Soundbug.
http://us.click.yahoo.com/QWAVSC/onCFAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
extremecustomering-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/