RE: [leandevelopment] how do I find bottlenecks?
- Re respect for people, the best place to start, IMHO, is Deming. Here are his fourteen points (Chapter 2 of Out of the Crisis, by W. Edwards Deming, MIT Press, 2000; originally published in 1982.):
1. Provide for the long range needs of the company; don't focus on short term profitability. The goal is to stay in business and provide jobs.
2. The world has changed and managers need to adopt a new way of thinking. Delays, mistakes, defective workmanship and poor service are longer acceptable.
3. Quit depending on inspection to find defects and start building quality into products while they are being built. Use statistical process control.
4. Don't choose suppliers on the basis of low bids alone. Minimize total cost by establishing long term relationships with suppliers that are based on loyalty and trust.
5. Work continually to improve the system of production and service. Improvement is not a one-time effort; every activity in the system must be continually improved to reduce waste and improve quality.
6. Institute training. Managers should know how to do the job they supervise and be able to train workers. Managers also need training to understand the system of production.
7. Institute leadership. The job of managers is to help people do a better job and remove barriers in the system that keep them from doing their job with pride. The greatest waste in America is failure to use the abilities of people.
8. Drive out fear. People need to feel secure in order to do their job well. There should never be a conflict between doing what is best for the company and meeting the expectations of a person's immediate job.
9. Break down barriers between departments. Create cross-functional teams so everyone can understand each-other's perspective. Do not undermine team cooperation by rewarding individual performance.
10. Stop using slogans, exhortations and targets. It is the system, not the workers, that creates defects and lowers productivity. Exhortations don't change the system; that is management's responsibility.
11. Eliminate numerical quotas for workers and numerical goals for people in management. [We add: Eliminate arbitrary deadlines for development teams.] This is management by fear. Try leadership.
12. Eliminate barriers that rob the people of their right to pride of workmanship. Stop treating hourly workers like a commodity. Eliminate annual performance ratings for salaried workers.
13. Encourage education and self-improvement for everyone. An educated workforce and management is the key to the future.
14. Take action to accomplish the transformation. A top management team must lead the effort with action, not just support.
These go back 60 years. And (I can't help myself) these principles are in the context that process causes 94% of the errors - so work on the process to support the people! (people and process, people and process, people and process, ...) ;)
Alan Shalloway, CEO, Sr. Consultant
Net Objectives, Gold Level Sponsor of Agile 2006.
Integrating people, process and technology through training, coaching and consulting.
See http://www.netobjectives.com/courses/index.html for our list of nationally offered courses in Lean Software Development, Scrum, Requirements, OO, Design Patterns and TDD.
Blogs and podcasts http://blogs.netobjectives.com/
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of allan kelly
Sent: Sunday, October 08, 2006 8:26 AM
Subject: Re: [leandevelopment] how do I find bottlenecks?
David Carlton wrote:
>IMHO A regular cycle is one of the most important things in development.
> One of the difficulties in applying that to our situation: we don't
> have regular releases in which we can consider a cycle like that. The
> product hasn't yet been launched; the only external releases are
Software is soft, so is development, you can do anything you want. You need some structure, something work within. Sometimes you want to make a rod for your own back.
This is one of those occasions.
If you can't get yourself and your team into a regular release cycle now, before launch, what makes you think it will be easier after launch when customers want bug-fixes, sales want an extra feature so Mega Corp will buy and your Product Managers want v2.0 ?
> One thing I was thinking about last night: respect for people is oneRespect for people is more than a pillar of lean. It should be a pillar of all modern business and all IT.
> of the pillars of lean. (Hmm, googling suggests that there are lots
If you have a business were you don't need to respect your people the chances are you can parcel the work up and send it were you can get the cheapest wage rates.
Our business, IT, isn't like that, people are important and cheap isn't always best. Therefore people are the difference: you competitor can buy the same computers as you, buy the same software, analyse the same market, and rent the office next door, but, you can't employ the same people. (Not at the same time at least.)
Saying "people make the difference" has a long history in our world: read Mythical Man Month, Peopleware, Psychology of Programming, etc. These aren't new, there has always been this argument. However, we reduce it to a cliché, "people make the difference" and then forget it.
We buy faster computers.
We upgrade our compilers.
We adopt the latest Methodology.
But what do we do for our people?
Go into any good book store and count the books on Java, or Windows, or Oracle, or what ever. Now count the books on people. See the difference?
So, if you want to improve your software production you have two options:
- get better people
- improve the people you have
To my mind at least Lean is about giving you the tools to help you and your people improve. This is why the concept of learning is so central to lean.
Yahoo! Groups Links
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
- On Mon, 09 Oct 2006 09:41:26 +0100, allan kelly <allan@...> said:
> David Carlton wrote:Some reactions:
>> We have had (monthly) regular internal releases in the past. We've
>> had two problems with those, though:
>> * They're not real releases: nobody in the outside world is keeping us
>> honest as to their quality. We try to do a good job of keeping
>> ourselves honest, but an internal release (or even one for partners)
>> just isn't the same as an external release.
> I find this worrying. It sounds like people only take quality
> seriously when a customer is in sight. So, for the first 11 months
> of a 12 month project quality can take a holiday.
* Yes, it is worrying: I am worried!
* We have a few kinds of quality problems. I think we're getting
better on outright bugs, though there's room to go there.
Specification mismatches seem to be a harder problem to solve.
* I don't think I'm unique in feeling that internal releases are
different from external releases. It's the same sort of reasoning
that recommends that, in XP speak, your Customer be an actual
customer, not a customer representative. Or that your daily
deployments (if you're that far) actually deploy, they're not just
builds that could be deployed. There's a reason why the value
stream map ends when the customer actually gets the value, after
>> * They're sometimes not fast enough - if we learn now that a bigAnd, indeed, our internal releases are good enough quality that this
>> potential customer wants to start a trial in three weeks, and new
>> feature X is necessary for the trial, then sticking to a monthly
>> heartbeat isn't going to do us much good.
> There are few ways to tackle this.
> Firstly, this seems to contradict your point above. Surely you want
> to stay as close to release quality at all times so you can just
> take what your working on, add feature X and ship it over? Provided
> your internal releases were good quality this wouldn't be a problem.
isn't a problem: we have successfully created trial releases in short
order. All I'm saying is that it means that we're not on a regular
> Second consider what you call your releases. Say your internalThat's a good idea - I'll think about that.
> releases were called Beta, and you had 4 iterations to each release.
> Then, again assuming each iteration completed with high quality, the
> software at the end of each iteration could be called an Alpha.
> Provided you set expectations with your trial customer they should
> be happy to work with a Beta or an Alpha. Trials don't need full
> releases, make it clear to the customer that you can have an Alpha
> with the feature available for the trial, and say that by the time
> the trial is finished you will have a release version available.
> I suspect, from what you say and my own experience, that when yourI don't think this is entirely true. I don't think our quality is as
> customer staff come back with a request you drop your current plans,
> work out how to handle their request, do it, ship something of
> dubious quality and then try to work out were you are.
bad as you're getting a picture of. We do reprioritize work pretty
often; I guess it's not clear to me that this is inherently a problem.
(Isn't our ability to do that supposed to be one of the advantages of
What is bad is if either our interim work is of low quality or if we
implement something that ends up ultimately not to be useful. We're
working to avoid the former. I don't really understand how to avoid
the latter; I wish I did.
> Consequently, you are thrashing, changing direction and prioritise aIn all honesty, I don't think anybody in the world knows what should
> lot. (This is also a worry for product strategy if you are driven
> by ad hoc customer requests. Do your product managers really know
> what should be in the product?)
be in this product. (And if that worries you, well, it worries me
too.) We're trying to provide new capabilities in an existing space;
we have a compelling dream for the new capabilities, but nobody really
understands how the details will play out. And our product will be
part of a quite complex ecosystem: we need to work with others to
bring the new capabilities to fruition. At the same time, to displace
existing deployments, we have to be able to integrate with systems
that are already in place. And there is a woeful lack of
standardization, which means that, if we want to target five different
deployments, we probably have to do five different integrations.
It's taken us a while to find a good strategy for this. Our current
favorite one is to partner with systems integrators; I think that will
help a lot, because it will let us sell basically the same system to
multiple individual deployments.
> Most likely your customers really don't want it tomorrow.Yes, that is true.