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

Re: [agile-usability] usability and corporate hierarchy

Expand Messages
  • William Pietri
    ... Sure. It comes from a Lean analysis of the workflow. Lean people are ardent about minimizing waste. That leads to 3 things relevant to backlogs: *
    Message 1 of 12 , Feb 15, 2010
      On 02/14/2010 08:09 PM, Ilen Zazueta-Hall wrote:
      Can you elaborate on minimum backlog?

      Sure. It comes from a Lean analysis of the workflow.

      Lean people are ardent about minimizing waste. That leads to 3 things relevant to backlogs:
      • pull-based workflows
      • deciding at the last responsible moment
      • just-in-time construction of design artifacts

      A push-based approach to design treats having the idea for something as the kickoff for a process of research, design iteration, and elaboration of artifacts. Those artifacts are then fed to a development team from a backlog.

      A pull-based approach instead looks at the team as an entity producing a roughly consistent amount of stuff based on certain inputs, and then asks, "What's the minimum amount of upstream work we can do to keep productivity maximized?" The team pulls from the top of a backlog just large and elaborated enough keep things moving.

      That in turn leads to making decisions at the last moment necessary, when the pull of production forces it. Ditto for design artifacts. That avoids waste, and since later decisions and designs have the most information available, will be the best ones. The work not done on things that never make it this far is time saved, waste avoided. And because teams don't have a mountainous backlog making them feel behind, they're less likely to rush and introduce defects.

      This applies to your situation because I think far-off managers are most likely to interfere based on high-fidelity design artifacts that sit around for a long time. The Agile teams I see doing best very rarely start an iteration with a set of pixel-perfect renderings of interfaces. Instead, they start with just enough information that a cross-functional team can smoothly build a nice-looking interface.

      From this, I'm wondering if you're working in relatively large chunks. What's your iteration frequency and your release frequency? And what sort of design artifacts are you using?

      Do you really need to test all browser versions for your A/B test, or achieve pixel perfection? Or if you do, can you do the tests in stages, where early tests help you decide whether to do later tests?

      This team is at 2 week iterations, releases every iteration (some stories take several iterations, but we don't have big releases per se) -- it's a good point that we could test only on one browser, I'll bring that up next time we're in the "please make 4 of these" situation. A/B testing is certainly part of the toolkit we should be using more.

      The real problem, from my perspective, is that design is happening outside the team... Any suggestions on how to change that?

      Hmmm... Not knowing much about your situation, I can only give generic advice.

      My suggestion is to put everybody necessary to making a good product within range of easy eye contact and discussion. If people are physically in one place and frequently responsible for achieving a shared result, they will generally turn into a team, rather than a group of individuals.

      As to why designers should want to move in, or managers allow it: cross-functional teams make the best products and get the best results. Which brings us back to corporate culture: that only matters if great products and great results are really the highest value.


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