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

Fwd: SCRUM/XP processes and Usability

Expand Messages
  • Adrian Howard
    Forwarded with permission... of interest I thought.. John s not on the list though :-)
    Message 1 of 1 , Mar 12, 2007
      Forwarded with permission... of interest I thought.. John's not on
      the list though :-)

      Begin forwarded message:

      > From: John Armitage <johnarmitage1@...>
      > Here is a C&P, sans images, of a short case study I wrote for an
      > internal
      > audience.
      > We have had good results so far. I can send it via attachment to any
      > interested
      > -John
      > ______________________________
      > Data Federator’s Agile Redesign Experience
      > Last October Eric Simon, Senior Director of BOBJ’s Data Federator
      > product
      > team, thought that his days of working in a startup software
      > company were
      > over. Medience, the company he co-founded, had just been acquired
      > by BOBJ
      > and he needed to upgrade its product appearance to fit the user
      > interface
      > standards of the BOBJ product suite, as well as translate the
      > product to
      > English from its native language of French. Expecting a
      > straightforward UI
      > facelift complete with icons, logos, and color palettes to match
      > the BOBJ
      > style, he found himself signing up to a difficult, risky, yet
      > compelling
      > overhaul of the entire Data Federator product user experience. The
      > effort
      > was, as he described it, “madness”. The product has nearly 150 unique
      > interface screens. But in the end, it worked, and can now serve as
      > a good
      > example of what to do and not to do in a thorough UE redesign.
      > What made this project unique is that it involved little new
      > functionality.
      > It was strictly focused on transforming the existing parts into a more
      > usable, understandable whole that would add significant value and
      > improve
      > competitiveness. Emphasizing product usability made sense to Simon,
      > because
      > Data Federator’s fundamental purpose is to present a complex array
      > of data
      > sources and data transformation processes to users in an
      > understandable and
      > meaningful way. Behind the scenes, Data Federator accelerates query
      > performance and extends the data warehouse via agile, on-demand,
      > virtual
      > data integration..) However, an important value is that it provides a
      > flexible and declarative interface to define a data transformation
      > mapping
      > between source data and target data unlike all its competitors
      > which use a
      > more operational operator-driven interface. “When we decided to
      > update the
      > user interface to match the other products in the BOBJ EIM suite, I
      > anticipated a relatively simple color, layout, and icon redesign.
      > However,
      > Interaction Designer Steve Kopp suggested a change to the product’s
      > overall
      > organization and structure to reflect how he believed our users
      > carried out
      > their tasks. I’d worked with an ergonomist before, so this approach
      > was not
      > foreign to me and his ideas made sense. I realized that we would
      > need to do
      > this eventually so I said ‘why not do it now?’”
      > What had started as a simple act of translation and fitting in to
      > their new
      > family had become something much larger. Realizing that the major
      > aspects of
      > the new design proposal were completely interdependent, Simon
      > “decided going
      > in that this was all or nothing, we either changed the design and
      > carried
      > through with it 100% or we failed. There was no going back or
      > compromise.”
      > Faced with limited resources and a six-month schedule, there was
      > little room
      > for error in executing the release while coordinating design,
      > development,
      > testing, and documentation. Simon’s answer was to integrate Kopp’s
      > designs
      > into the agile development process that his development team was
      > already
      > accustomed to, and organize the work specifically for this project.
      > Simon divided the development effort into five phases, or sprints,
      > based on
      > developing major components in the product and beginning with an
      > overall
      > design phase. Phase 0 consisted in defining the overall design of
      > the UI.
      > This was carried out through frequent meetings with Steve, the
      > developers (3
      > at that time) and Simon. Duration was about 3 weeks. Once the general
      > interaction principles and main screens of the UI were defined, the
      > development work was split into 5 phases or sprints. Each sprint was
      > organized through 3 steps: (1) pencil design, (2) pixel-perfect
      > screens and
      > design rules, (3) coding and feedback to step 1. In the design
      > phase, Simon
      > and Kopp used pencil-and-paper and simple screen layouts to plan
      > the major
      > design elements, or patterns, that would be repeated throughout the
      > whole
      > product. “A very important aspect here is that I was interacting
      > with the
      > development team based on the pencil-and-paper layouts to verify the
      > correctness of the functional workflow and address the implementation
      > issues” (that is, things that would be too hard to do given the short
      > timeframe). This led to refined layouts. So there was a loop at the
      > pencil
      > level. “It was at this time that we developed design rules that the
      > product
      > needed to adhere to”, said Simon. “Having these rules made decision-
      > making
      > easier later in the project”. Kopp then made precise, pixel-perfect
      > screen
      > designs for the developers to follow. “Once a design decision was
      > made, the
      > team was very rigorous to follow the decision to the pixel, which
      > required a
      > strong discipline and caused some overhead with respect to the usual
      > development style. The amazing ability of the development team to
      > adjust to
      > this new development style was instrumental to the success of the
      > project.”
      > Figure 1: Each Sprint delivered a build ready for testing and
      > documentation
      > “In the builds, we treated deviations from the design as bugs, and
      > our rule
      > was to fix all bugs before completing a sprint”. Sometimes, of
      > course, the
      > designs needed to change during a sprint, in reaction to development
      > constraints or better ideas that came out of the interaction with the
      > developers. In these cases, Simon always went back to Kopp for
      > strictly
      > time-boxed design sessions to address the problem and re-do the
      > specification. “He was relentless. He kept coming back and demanded
      > detailed
      > modifications to small pieces of the UI”, Kopp said of Simon, “but
      > I saw
      > that it was necessary”. Kopp spent half his time for three months
      > on the
      > effort while Simon spent half time during the first month then one-
      > third in
      > the two next months, working with three full-time developers at the
      > beginning and four at the end.
      > On such hectic projects, team cohesiveness, chemistry, and having a
      > decisive
      > leader is important for maintaining high morale. Kopp, although a
      > member of
      > the team from the beginning, actually works in the User Experience
      > team, not
      > the Data Federator team. “The rest of us had worked together a
      > great deal so
      > Steve was the new guy. The developers were skeptical at the
      > beginning, but
      > Steve managed to produce some very useful work. He proved himself by
      > demonstrating deep expertise in user experience, and by being
      > dedicated and
      > very accessible to react to the changes in development. He became
      > key to the
      > team’s success. In fact, to make up some time we had the developers
      > do a
      > sprint without design direction over the holidays, and it was very
      > unproductive. We needed to re-do all the work.”
      > The team’s phased approach allowed dev, testing, and documentation
      > to work
      > efficiently in parallel for most of the project duration. Guided by
      > the
      > overall design from the first sprint, the developers would build a
      > module,
      > hand it off for testing and documentation, then work on the next
      > module
      > while de-bugging the first module. Because Kopp’s detailed designs
      > were kept
      > up-to-date, the testers could easily test screens in the builds for
      > accuracy
      > of what is called “fit and finish” of the UI. This relay approach
      > proceeded
      > through all four production sprints. Sometimes previous modules
      > needed to be
      > modified later, but with the overall UE design as a guide, little
      > of this
      > was necessary. An important key to success for the project was the
      > adherence
      > to deadlines in each phase. This required a very high dedication of
      > the
      > development team.
      > Here are some examples of the resulting designs:
      > Fig. 2: Version 1 had 4 entry points that allowed the user to access 4
      > distinct ‘tools’ that looked very similar. Navigating among these
      > related
      > workflows was cumbersome. Version 2 combines the 4 tools into 1. The
      > different parts are accessible via an “Outlook-style” menu in the
      > left pane
      > The related content is consistently displayed in the main frame. A
      > dynamic
      > “breadcrumb” control at the top indicates the current location and
      > allows
      > the user to navigate within a given workflow.
      > Fig 3. Much of the work involved simplifying the product’s “mental
      > model”,
      > or the overall concept for how users think about and use the
      > application.
      > Because user’s product tasks resembled managing a project, the team
      > chose a
      > design based on a project metaphor, something lacking in version 1.
      > Before
      > there were no clear “containers” for work that was done. Tabs in
      > Version 1
      > confusingly represented both navigation controls and titles, and
      > its user of
      > button design and titling was inconsistent.
      > “We made some mistakes and I would have done some things
      > differently. For
      > example, our product is built with html and it would have been
      > great to have
      > an html expert to build the screen templates for our developers to
      > use. This
      > cost us a lot of time.” According to Simon, however, the results
      > are worth
      > the effort. “We presented our new product to customers and the
      > field in a
      > pre-release training session, and we found that people had little
      > difficulty
      > learning things that are typically difficult to grasp in a user
      > interface.
      > They seemed very comfortable with the product.” Even with this warm
      > reception, Simon is not resting. The development schedule prevented
      > any real
      > user input on the design, so the team is now making some last-
      > minute changes
      > to react to the training feedback.
      > When asked what has changed for his team’s working style in moving
      > from a
      > startup to BOBJ, Simon replied “Surprisingly little. We now have
      > access to
      > better resources and specialized expertise, but the work is still
      > fast and
      > furious.”
      > For More Information
      > Learn more about agile software development with the Agile Manifesto
      > http://agilemanifesto.org/
      > The Data Federatpr [product:
      > <http://www.businessobjects.com/products/dataintegration/
      > datafederator.asp
      > <http://www.businessobjects.com/products/dataintegration/
      > datafederator.asp>
    Your message has been successfully submitted and would be delivered to recipients shortly.