Archive for the ‘Design Excellence’ Category

• Agile Transitions Workshop

  Date: 2008.11.13 | Category: Agile, Agile SD, Design for Six Sigma, Presentations, Transitions | Response: 0

  I am quite busy with the presentations lately.  Next up is an appearance at XPSD on December 4th where I will run a workshop showing how to use some simple tools to chart and monitor an Agile transition for your organization.  This will be a hands-on session.   The tools I will be demonstrating come from my Design for Six Sigma work.   Look forward to seeing you in December!

• Designing for User Performance

  Date: 2008.10.28 | Category: Conferences, Design Excellence | Response: 0

  Stopped by to listen to Larry Constantine today to hear what he is thinking about how to best design applications.  These are a number of the key points I picked up from his talk:

  • Prioritize design efforts around tasks which have the most frequency and greatest importance.
  • Organize designs around the fewest number of transitions for key tasks
  • Keep the screen context consistent when you do transition.
  • Use proximal and visual context to group related and associated elements.
  • Provide context when offering corrections and support editing-in-place when the user makes an error.
  • Edit-in-place is the best way to train the user on the correct data entry.
  • Redundancy or alternate paths are in general a good thing; allowing actions to be reversible is better.
  • For user tasks that are not reversible we need to carefully consider their design. (ed. duh!)
  • Filter non-numeric characters from number only fields.
  • Don’t make the user a subroutine of the program, automatically update known information if the user gave it to you.
  • If there is a natural\alternative way of entering data in the real world, the machine should be flexible enough to accept it.
  • If the error is obvious and detectable by the program, why tell the user about it?
  • Propagate errors, and their cause, to the highest level that can handle them.
  • If there is an error in the program, tell people where the error is and how to fix it.
  • Don’t ever give an nodal\dialogue\confirmation box to a user unless the message is relevant, recognizable AND the user can intelligently respond to the message; otherwise just “eat” the message.

• SOA Measures for Success

  Date: 2008.10.28 | Category: Conferences, Measures | Response: 0

  One of the sessions I visited today was about what are the correct measurements to determine if your SOA initiative was successful.  One of the most interesting statistic from the speaker was this continuum of cyclometric complexity (CC):

      CC < 10: "simple" code
      10 > CC < 20: "moderately" complex code
      20 > CC < 50: "severely" complex code
      CC > 50: "untestable"

  He based that experience on a simple equation of:

      # of test cases = 2CC-1

  Which suggests code with a CC as low as 15 will have 16,384 test cases!  Ouch!  That has got to hurt considering functional testing only gets you about 20% of test coverage.

  I think another valuable observation provided was software reliability is inversely related to CC, the higher the CC, the less reliable the software.  The most eye-popping statistic from the talk was the speaker’s observation that if you can refactor your code to have a CC in the 10-15 range, an organization would reduce their maintenance costs by 2 to 5 times!

  Finally, these are the ten measures from the talk that I thought I would share with all of you and how one should optimize the measures.  The words in the parenthesis are what level the measures speak to.

  1. Dollars per service -> higher is better (corporate)
  2. Service vitality index (new service revenue/total revenue) -> ~10%-20% is good (corporate)
  3. Number of new services/total services -> higher % is better(management)
  4. Mean time to service deployment -> lower t is better (management)
  5. Mean time to service charge -> lower t is better (management)
  6. Service availability -> higher % is better (management)
  7. Service reuse -> higher % is better (project)
  8. Cost of not using/stopping the service -> lower $ is better (project)
  9. Service complexity -> lower CC is better (service)
  10. Service QA confidence -> higher % is better (service)

• Pay Attention to the Obvious

  Date: 2008.07.25 | Category: Design for Six Sigma, Practices, Voice of the Customer | Response: 0

  The other day we were talking about DfSS and how much training material we were going to produce and what sort of timelines we could commit to. I was having a hard time wrapping my head around the scope of the problem because it seemed very large and undefined. Specifically, I was thinking I had a LOT of original training I needed to create around some Agile code practices. Somewhere along the way I had missed aan important concept about my role on the DfSS rollout team. For some reason, I was under the impression that DfSS was about making better engineers.

  “Noooo. DfSS (DESIGN for Six Sigma) is about taking good engineers (people with good skills and proven engineering aptitude) and training them to become good designers.”

  While had been consistently told that DfSS is the program is about “designing quality into the system”, what I heard was “building quality into the system”. During the implementation (ostensibly the work that happens after DfSS), quality engineering practices are monitored and controlled via the scorecard. It is through the scorecard that good engineering practices like continuous integration, automated unit tests,refactoring, etc., etc. are implied to the Team. During implementation, you have to do “something” which will satisfy the scorecard, that “something” is up to you.

  Call me a bit skeptical about using the scorecard as a control mechanism for good engineering practices. I feel comfortable that the design coming from DfSS will be excellent, reflect the Voice of the Customer and be marketable, but leaving implementation as a black box to be monitored via a scorecard at phase gates ,or through periodic in-process reviews, leaves me less than satisfied. It seems to me that DfSS relies heavily on the ability of the DfSS Black Belt to bring both an excellent design AND quality engineering practices to the implementation team. In many of the environments I have encountered, there is big gap between the skills of the designers and the implementation team. It might be a bridge too far, I don’t know.

• New Directions & Design for Six Sigma (DfSS)

  Date: 2008.07.17 | Category: Design for Six Sigma | Response: 0

  At my current location we develop products that are regulated by the FDA, so we must have a quality system based on CFR Title 21, Part 820. Around here, that quality system is called the Global Development Process or GDP. However, those regulations do not tell you how to build a quality product, just that you need to have a documented process and you need to follow it. Because the FDA allows companies to define their own quality process within the guidelines of Title 21, Part 820, when auditors come for an inspection, what they are looking to see if we are adhering to our own process.

  For us, the GDP is simply the minimum requirements we must follow in order to be in compliance with the FDA. While our GDP explains the deliverables we must create and when, it does not provide any guidance on how to produce these deliverables. In addition, it is my understanding that while the GDP is focused on compliance for the FDA, it does not show how to build excellent products within the GDP. I am now part of the core team which will create a set of Lean tools that will help us create excellent products that excite our customers and better help their patients. This concept is calledDesign for Six Sigma (DfSS) and has been described to me as a way to build quality into our new products. I have been selected to be on this team to provide an Agile viewpoint and create tools that will aid software engineers make more robust products and apply widely-used “best practices”.

  At first glance, DfSS sounds a lot like waterfall and I am a very Agile guy at heart. Initially, I was very skeptical about this initiative, but I have changed my thinking. This could be a very interesting avenue of study since most of my experience has been working on small teams creating small products using lightweight tools. However, big companies with complex hardware and software requirements, especially ones regulated by the FDA, need a different set of tools, tools that are a more heavyweight than I am used to.

  I am not certain that the concepts of DfSS and Agile can be combined, but what intrigues me is the emphasis on the Voice of the Customer (VOC). If we remain committed to learning the VOC and focused on what the customer’s user needs, I can see how Agile and DfSS can play nice together. How that plays out in real life remains to be seen, but I definitely have an open mind that something “bigger” than Agile is needed for big companies and DfSS might be it. Perhaps DfSS is the way big companies make products in a recognizably Agile way?