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

Re: Appropriating Agile methods for traditional software development

Expand Messages
  • 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 1 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!

      --- 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
      > 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?"
      > Usability testing Usability Agile software development
      Agile development
      > ---------------------------------
      > 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
      > ---------------------------------
    Your message has been successfully submitted and would be delivered to recipients shortly.