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

RE: [agile-usability] Appropriating Agile methods for traditional software development

Expand Messages
  • Ken Auer
    Not to toot my own horn, but there is a section on this in the book I co-authored with Roy Miller Extreme Programming Applied: Playing to Win including a
    Message 1 of 7 , Mar 10, 2006
    View Source
    • 0 Attachment

      Not to toot my own horn, but there is a section on this in the book I co-authored with Roy Miller “Extreme Programming Applied: Playing to Win” including a couple of side bars.  If you don’t like paying full price, and giving me $2-3 of royalties, there are usually a decent amount of used books on amazon.

       

      Ken

       


      From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of t_vo
      Sent: Friday, March 10, 2006 10:03 AM
      To: agile-usability@yahoogroups.com
      Subject: [agile-usability] Appropriating Agile methods for traditional software development

       

      I am an Interaction Designer at a medium sized software company. We
      develop very complex design software for construction professionals.
      There is almost no hope of completely replacing our document-heavy
      process with agile methods any time soon. However, I migrated recently
      from a small web start up that was using agile methods and I am
      looking for ways to incorporate some of the practices. Specifically, I
      really liked having the project plans  and feature cards right up on
      the wall where everyone could see them (as opposed to buried in some
      network folder.) Does anyone have experience merging some agile
      practices with more traditional design methodologies without going
      "full bore?"




    • Cory Foy
      ... I know this doesn t exactly answer your question, but back in September there was an interesting thread on the XP list about applying XP practices to
      Message 2 of 7 , Mar 10, 2006
      View Source
      • 0 Attachment
        > Does anyone have experience merging some agile
        > practices with more traditional design methodologies without going
        > "full bore?"

        I know this doesn't exactly answer your question, but back in September
        there was an interesting thread on the XP list about applying XP
        practices to non-software projects that was quite interesting (I've
        forwarded it here as Yahoo changed their web interface and searching
        messages there is quite a pain now.). I thought it might have some
        relevance for you in the construction business.


        Cory

        -------- Original Message --------
        Greetings,

        In October 2003, I gave a talk on Extreme Programming to an
        architectural firm. They were interested developing "high-performance
        teams" for their building projects. Several months later, they
        decided to use XP, actually an adaptation of XP, on one of their
        projects: a fairly large building complex (over $100 million
        construction cost). The time schedule was tight (32 weeks to design
        the building and prepare construction documents) and there were many
        interim deadlines. The project team eventually grew to eleven
        architects, a few fresh out of university, others with more than 30
        years experience.

        Although this was a non-software project, we followed many XP
        practices by the book, adapted some, and added a few from Scrum and
        Industrial XP. Here are some examples:

        ·Planning Game: We created project and release plans based on tasks
        rather than user stories. We created a task card (3 x 5 index card)
        for each substantial task. We held weekly planning meetings to select
        and discuss the highest priority tasks, then posted the cards on a
        task board and let team members select tasks they wished to complete.
        Task cards served as physical tokens that helped us focus, estimate,
        and prioritize our work efficiently and effectively.

        ·Small Releases: In architecture, our deliverable (prior to
        construction) is a set of construction documents that show how the
        building is to be built. We issued an up-to-date set of documents (a
        progress set) each week for review by our customers (the contractor,
        client, and consultants). Releasing a set of documents isn't as
        effective as a customer actually trying out a software program, but
        it does generate feedback, clarifies intent, and prevents oversights.
        In some cases the interim documents were used to solicit
        subcontractor bids.

        ·Testing and Continuous Integration: Instead of tests, we used an
        accelerated peer-review process. As each task was completed, the work
        (usually a drawing) was handed to an "integrator" who reviewed and
        integrated the work into the progress set. The integrator made sure
        the drawing followed our standards, was correct and complete, and was
        coordinated with the rest of the work. This task-based review system
        provided rapid feedback that was greatly appreciated, especially by
        less experienced team members.

        ·Pair Programming: We encouraged pairing but left it up to team
        members. They usually paired on an as-needed basis. They would often
        pair (or group) to discuss a task, then one person would complete the
        task, discussing it with others as-needed. We also encouraged open
        communication and facilitated it by grouping team members together in
        an open workspace.

        ·Collective Ownership: The team collectively owned the construction
        drawings. Anyone could change any drawing at any time. Initially,
        some team members were uncomfortable with collective ownership, but
        later came to appreciate its benefits.

        ·40-Hour Week: We met all our interim and final deadlines (there were
        many), except for one, without resorting to overtime. We often
        completed our work before deadline, something team members had rarely
        experienced before.

        ·On-Site Customer: An architectural project has many customers:
        clients, contractors, and consultants, to name a few. Instead of
        being on-site, customers were represented by the project manager,
        project architect, or by one of the team members.

        ·Coding Standards: The team followed a minimal set of project drawing
        standards dictated by our customers. To further promote consistency,
        we supplemented the standards with prototype drawings. We used the
        prototypes like templates or examples. They were drawings that showed
        how, what, where, and how much information to include for a
        particular type of object. For example, we might have to draw 10
        different wall sections, complete with notes and dimensions. We would
        designate the first wall section as the prototype after it had been
        reviewed and approved by other team members. Remaining wall sections
        would be adapted from the prototype.

        ·Simple Design and Refactoring: We attempted to keep things simple
        throughout, mostly by keeping duplication to an absolute minimum. We
        never did any formal refactoring, but did remove anything on a
        drawing that didn't help clarify our intent.

        ·Metaphor: All team members shared a common language and
        understanding of what was required to complete the project, so we
        didn't feel a need for a metaphor.

        ·Retrospectives: We held weekly retrospectives, supplemented with one-
        on-ones, to get feedback from team members. We modified our practices
        based on team member comments, not just at the beginning, but
        throughout the entire project.

        ·Big Visible Charts: We created weekly progress/burn-down charts and
        posted them, along with other important information, on the task
        board. They gave team members and others a sense of the project's
        status.

        ·Stand-Up Meetings: We held daily stand-up meetings in which each
        team member would show what they had accomplished and tell what they
        intended to do next. Stand-ups were invaluable for keeping team
        members aligned, focused, and informed. They also gave us an
        opportunity to acknowledge and appreciate each person's contributions.

        Overall, the firm considered the XP-based process an outstanding
        success. Team members especially liked being able to select tasks
        rather than having them assigned, being able to reliably predict how
        long work would take, sharing and learning via pairing, and being
        kept informed in stand-up meetings. The firm is now using XP (we call
        it XPM for Extreme Project Management) on several other projects.

        I've posted a more comprehensive report at
        http://www.architecturalpractices.com/articles_report_001.html
        I welcome your comments, questions, and suggestions.

        Dennis V. O'Neill
        www.architecturalpractices.com





        To Post a message, send it to: extremeprogramming@...

        To Unsubscribe, send a blank message to:
        extremeprogramming-unsubscribe@...

        ad-free courtesy of objectmentor.com
        Yahoo! Groups Links
      • Tobias Mayer
        Hi t_vo (got a real name?), It is not so much the practices (such as the writing of big documents) that will be a block to agile, it is the mindset of the
        Message 3 of 7 , Mar 11, 2006
        View Source
        • 0 Attachment
          Hi t_vo (got a real name?),
           
          It is not so much the practices (such as the writing of big documents) that will be a block to agile, it is the mindset of the people who do the practices.  You should assess whether the pepole are willing to work and think in different ways.  If you believe there is a possibility, even a slim one, then you are on good ground.
           
          I suggest you start by introducing the Scrum framework - see: http://www.mountaingoatsoftware.com/scrum/.  This will help you to begin to see clearly the activities that impede progress.  Scrum's magic - if done in the right spirit: i.e. fearlessly - is to surface problems, make them visible and therefore harder to ignore.  Scrum will not solve these problems, but knowing what they are, will allow you to resolve them, or escalate them as appropriate.  This takes courage.  Are you prepared for that?
           
          Move slowly.  Identify the worst constraint and explore with your team/s ways to remove the block or streamline the process.  As it improves another constraint will become apparent.
           
          There are many good agile practices for usability people, lots have been described on this list, and I'm certain many more will be, as they are discovered*.  Finding which ones to use/adapt to your organization will be a challenge, and having a simple but firm framework in place will be a great asset.
           
          Have fun - and keep asking questions.
           
          Tobias
          "There's a box?"
           
          * That raises an interesting question.  Are good practices discovered or are they invented?  Another thread perhaps...
           
           

          t_vo <tvollaro@...> wrote:
          I am an Interaction Designer at a medium sized software company. We
          develop very complex design software for construction professionals.
          There is almost no hope of completely replacing our document-heavy
          process with agile methods any time soon. However, I migrated recently
          from a small web start up that was using agile methods and I am
          looking for ways to incorporate some of the practices. Specifically, I
          really liked having the project plans  and feature cards right up on
          the wall where everyone could see them (as opposed to buried in some
          network folder.) Does anyone have experience merging some agile
          practices with more traditional design methodologies without going
          "full bore?"




        • Tobias Mayer
          Hmm.. I realise that my earlier response begs the question. If the organization does not want to become Agile then they will not consider adopting Scrum.
          Message 4 of 7 , Mar 11, 2006
          View Source
          • 0 Attachment
            Hmm.. I realise that my earlier response begs the question.  If the organization does not want to become Agile then they will not consider adopting Scrum.  
             
            William mentioned in an earlier thread the concept of a stealth approach.  I have also tried that with some success, i.e. the single team improved but the practices did not ripple out into the rest of the organization.  The latter took some serious agitation and evangelizing on my part.  It cost me my job, ultimately, but by the time I left there Scrum/Agile had been accepted by some high-up VPs and other management types, and the practices (if not yet the mindset) were being adopted by a number of teams, so I reckon it was worth it.
             
            Changing minds is so much harder than changing practices.  Trouble is, if you don't you can be almost certain that the practices will revert back.  Agile practices make no sense without the underlying principles.
             
            Tobias
            "There's a box?"


             Mayer <tobyanon@...> wrote:
            Hi t_vo (got a real name?),
             
            It is not so much the practices (such as the writing of big documents) that will be a block to agile, it is the mindset of the people who do the practices.  You should assess whether the pepole are willing to work and think in different ways.  If you believe there is a possibility, even a slim one, then you are on good ground.
             
            I suggest you start by introducing the Scrum framework - see: http://www.mountaingoatsoftware.com/scrum/.  This will help you to begin to see clearly the activities that impede progress.  Scrum's magic - if done in the right spirit: i.e. fearlessly - is to surface problems, make them visible and therefore harder to ignore.  Scrum will not solve these problems, but knowing what they are, will allow you to resolve them, or escalate them as appropriate.  This takes courage.  Are you prepared for that?
             
            Move slowly.  Identify the worst constraint and explore with your team/s ways to remove the block or streamline the process.  As it improves another constraint will become apparent.
             
            There are many good agile practices for usability people, lots have been described on this list, and I'm certain many more will be, as they are discovered*.  Finding which ones to use/adapt to your organization will be a challenge, and having a simple but firm framework in place will be a great asset.
             
            Have fun - and keep asking questions.
             
            Tobias
            "There's a box?"
             
            * That raises an interesting question.  Are good practices discovered or are they invented?  Another thread perhaps...
             
             

            t_vo <tvollaro@...> wrote:
            I am an Interaction Designer at a medium sized software company. We
            develop very complex design software for construction professionals.
            There is almost no hope of completely replacing our document-heavy
            process with agile methods any time soon. However, I migrated recently
            from a small web start up that was using agile methods and I am
            looking for ways to incorporate some of the practices. Specifically, I
            really liked having the project plans  and feature cards right up on
            the wall where everyone could see them (as opposed to buried in some
            network folder.) Does anyone have experience merging some agile
            practices with more traditional design methodologies without going
            "full bore?"





          • Deb
            Trouble with the stealth approach (yes, I ve done it too) is the problem of constraints. Each constraint resolved reveals another as Tobias indicates. When
            Message 5 of 7 , Mar 11, 2006
            View Source
            • 0 Attachment
              Trouble with the "stealth approach" (yes, I've done it too) is the
              problem of constraints.

              Each constraint resolved reveals another as Tobias indicates. When the
              next constraint is outside the team... hmmm, now the team is showing
              up someone's work as problematic. If this someone doesn't buy into
              either Lean or Agile ideas, this may be very threatening to them.
              Suddenly, the new practices of your team are perceived as subversive
              or divisive.

              I'm not saying "don't do it", but rather: extend your stealth approach
              outside the team, right from the start. Mary Lynn Manns and Linda
              Rising's book Fearless Change is full of strategies for doing this.
              Identify who on your team has the personality to do this stuff and
              dedicate a little of their time to it. I think it could pay off.

              This could give you advocates *outside* the team when stupid rumours
              start, like: "they're not doing any documentation!!" or "pairing is
              doubling development time!!", etc. It may even forestall rumours.

              Go for it!
              deb

              --- In agile-usability@yahoogroups.com, Tobias Mayer <tobyanon@...> wrote:
              >
              > Hmm.. I realise that my earlier response begs the question. If the
              organization does not want to become Agile then they will not consider
              adopting Scrum.
              >
              > William mentioned in an earlier thread the concept of a stealth
              approach. I have also tried that with some success, i.e. the single
              team improved but the practices did not ripple out into the rest of
              the organization. The latter took some serious agitation and
              evangelizing on my part. It cost me my job, ultimately, but by the
              time I left there Scrum/Agile had been accepted by some high-up VPs
              and other management types, and the practices (if not yet the mindset)
              were being adopted by a number of teams, so I reckon it was worth it.
              >
              > Changing minds is so much harder than changing practices. Trouble
              is, if you don't you can be almost certain that the practices will
              revert back. Agile practices make no sense without the underlying
              principles.
              >
              > Tobias
              > http://agilethinking.net
              > "There's a box?"
              >
              >
              > Mayer <tobyanon@...> wrote:
              > Hi t_vo (got a real name?),
              >
              > It is not so much the practices (such as the writing of big
              documents) that will be a block to agile, it is the mindset of the
              people who do the practices. You should assess whether the pepole are
              willing to work and think in different ways. If you believe there is
              a possibility, even a slim one, then you are on good ground.
              >
              > I suggest you start by introducing the Scrum framework - see:
              http://www.mountaingoatsoftware.com/scrum/. This will help you to
              begin to see clearly the activities that impede progress. Scrum's
              magic - if done in the right spirit: i.e. fearlessly - is to surface
              problems, make them visible and therefore harder to ignore. Scrum
              will not solve these problems, but knowing what they are, will allow
              you to resolve them, or escalate them as appropriate. This takes
              courage. Are you prepared for that?
              >
              > Move slowly. Identify the worst constraint and explore with your
              team/s ways to remove the block or streamline the process. As it
              improves another constraint will become apparent.
              >
              > There are many good agile practices for usability people, lots
              have been described on this list, and I'm certain many more will be,
              as they are discovered*. Finding which ones to use/adapt to your
              organization will be a challenge, and having a simple but firm
              framework in place will be a great asset.
              >
              > Have fun - and keep asking questions.
              >
              > Tobias
              > http://agilethinking.net
              > "There's a box?"
              >
              > * That raises an interesting question. Are good practices
              discovered or are they invented? Another thread perhaps...
              >
              >
              >
              > t_vo <tvollaro@...> wrote:
              > I am an Interaction Designer at a medium sized software company. We
              > develop very complex design software for construction professionals.
              > There is almost no hope of completely replacing our document-heavy
              > process with agile methods any time soon. However, I migrated recently
              > from a small web start up that was using agile methods and I am
              > looking for ways to incorporate some of the practices. Specifically, I
              > really liked having the project plans and feature cards right up on
              > the wall where everyone could see them (as opposed to buried in some
              > network folder.) Does anyone have experience merging some agile
              > practices with more traditional design methodologies without going
              > "full bore?"
              >
              >
              >
              >
              >
              >
              > SPONSORED LINKS
              > Usability testing Usability Agile software development
              Agile development
              >
              > ---------------------------------
              > YAHOO! GROUPS LINKS
              >
              >
              > Visit your group "agile-usability" on the web.
              >
              > To unsubscribe from this group, send an email to:
              > agile-usability-unsubscribe@yahoogroups.com
              >
              > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
              Service.
              >
              >
              > ---------------------------------
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.