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

RE: [leandevelopment] how do I find bottlenecks?

Expand Messages
  • Alan Shalloway
    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
    Message 1 of 47 , Oct 8, 2006
      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/

      -----Original Message-----
      From: leandevelopment@yahoogroups.com [mailto:leandevelopment@yahoogroups.com] On Behalf Of allan kelly
      Sent: Sunday, October 08, 2006 8:26 AM
      To: leandevelopment@yahoogroups.com
      Subject: Re: [leandevelopment] how do I find bottlenecks?

      David Carlton wrote:
      > 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

      IMHO A regular cycle is one of the most important things in development.
      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 one
      > of the pillars of lean. (Hmm, googling suggests that there are lots

      Respect for people is more than a pillar of lean. It should be a pillar of all modern business and all IT.

      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 ______________________________________________________________________
    • David Carlton
      ... Some reactions: * 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
      Message 47 of 47 , Oct 9, 2006
        On Mon, 09 Oct 2006 09:41:26 +0100, allan kelly <allan@...> said:

        > David Carlton wrote:
        >> 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.

        Some reactions:

        * 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
        all. :-)

        >> * They're sometimes not fast enough - if we learn now that a big
        >> 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.

        And, indeed, our internal releases are good enough quality that this
        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
        monthly heartbeat.

        > Second consider what you call your releases. Say your internal
        > 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.

        That's a good idea - I'll think about that.

        > I suspect, from what you say and my own experience, that when your
        > 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.

        I don't think this is entirely true. I don't think our quality is as
        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
        agile approaches?)

        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 a
        > 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?)

        In all honesty, I don't think anybody in the world knows what should
        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.

        David Carlton
      Your message has been successfully submitted and would be delivered to recipients shortly.