Re: Appropriating Agile methods for traditional software development
- 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
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 email@example.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
> 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
> "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.
> "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
> YAHOO! GROUPS LINKS
> Visit your group "agile-usability" on the web.
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of