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

Appropriating Agile methods for traditional software development

Expand Messages
  • t_vo
    I am an Interaction Designer at a medium sized software company. We develop very complex design software for construction professionals. There is almost no
    Message 1 of 7 , Mar 10, 2006
    • 0 Attachment
      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?"
    • William Pietri
      ... One of my secret techniques for switching people over is to do the agile stuff in parallel. For example, with a big spec, I ll make up the cards and
      Message 2 of 7 , Mar 10, 2006
      • 0 Attachment
        t_vo wrote:
        > There is almost no hope of completely replacing our document-heavy
        > process with agile methods any time soon. [...] Does anyone have
        > experience merging some agile practices with more traditional design
        > methodologies without going"full bore?"

        One of my secret techniques for switching people over is to do the agile
        stuff in parallel. For example, with a big spec, I'll make up the cards
        and present it as a personal quirk. E.g., "I'm just a visual person; it
        helps me to lay it out like this." Or, "There's so much to be done that
        I wanted to make sure I didn't miss anything important." There's no
        conflict; it's just another way of looking at things.

        If you use them consistently, people will start picking up the agile
        approaches by osmosis. And if you're lucky, they will notice that the
        agile approaches are easier and start favoring them. If your board of
        cards is always more up to date and easier to use, then that giant
        Microsoft Project file will slowly become a historical artifact.

        When taking a stealth approach, it's important to never push. You can
        offer and question, but pushing can create opposition and defensiveness.
        There are a lot of things that people do that I think of as "security
        blankets". Accept that master Excel spreadsheet as their personal quirk.
        As long as they do the work of maintaining it, just be puzzled by it. If
        it's now useless, they will eventually stop. And if it's actually
        useful, you'll be glad you didn't hector them.


        Hoping that helps,

        William
      • 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 3 of 7 , Mar 10, 2006
        • 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 4 of 7 , Mar 10, 2006
          • 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 5 of 7 , Mar 11, 2006
            • 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 6 of 7 , Mar 11, 2006
              • 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 7 of 7 , Mar 11, 2006
                • 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.