The need for an "Agile Evangelist"
- The "seeking agitator" thread has been going on about people picking
the easy parts of an agile methodology, not doing the rigid parts,
and then wondering why the results are not up to par.
I'd like to pose a twist with a different question -- and this is one
that Jeff can weigh in on because he has seen it first hand -- the
need for an "Agile Evangelist".
It has been my experience that when agility is brought into a project
(and it works) there is a constant push from someone with 1) agile
experience (often a consultant), and 2) excitement/passion for the
task at hand. We'll refer to this person as the "Agile Evangelist".
The problem comes into play when that person's influence is no longer
there. Sometimes it is as simple as the person leaving the company.
Sometimes (as I have seen) it is more harsh in that the company sees
the success of the agile team, and then wants to implement the
methodologies elsewhere in the company. But then they get confused
when the results are not the same.
So my "agitation" to get this thread going is the following:
1) It appears to me that an Agile Evangelist is REQUIRED to start an
agile process -- agree? Or is the reading of books and common sense
2) If they are required, for how long? What is the "signal" that all
is OK to move on?
3) After the loss of a leader, there is a period of transition. What
can a group do to ensure that this transition is successful?
4) This same scenario might also apply to usability people, but for
some reason, it seems to be harder felt in the agile scenario (IMO).
-- Andrew Lawrence
Software Design/Development Consultant
- Hi, Andrew! Interesting questions. Here's my take on them.
On Tue, 2005-06-14 at 15:32 +0000, Andrew Lawrence wrote:
> 1) It appears to me that an Agile Evangelist is REQUIRED to start an
> agile process -- agree? Or is the reading of books and common sense
I think it's possible to start it without one; I've seen successful
agile adoptions that way. However, I always recommend one; it's an
easier path, and the adoption is much, much faster.
> 2) If they are required, for how long? What is the "signal" that all
> is OK to move on?
I think the most important thing is that the team experiences what a
well-run agile project feels like. In that, it's a lot like learning to
ride a bike: you have to know what keeping your balance feels like, and
the continuous small corrections required to stay balanced must become
When I do an adoption, my general deal with the team is that they try
everything my way for 6-8 weeks, so that they get enough experience with
the techniques to judge them for themselves. Then they can do as they
please, although I'll drop back with declining frequency over the next
6-12 months to coach them.
Ideally during this period you bring in enough people with agile
experience that the team is roughly 1:1 novices vs agile-skilled.
After that initial jump start, the external people roll slowly off while
you bring on other internal people. This keeps the project running
smoothly at the beginning. Later it provides continuous moderate
challenge for the permanent team to pick up the slack.
> 3) After the loss of a leader, there is a period of transition. What
> can a group do to ensure that this transition is successful?
My goal as a coach is to make everybody a leader. That sounds a little
corny, but I think it's entirely possible.
The team should continuously strive to reduce hierarchy and keep from
pigeonholing people. Pair programming helps a lot with that. I'm also
fond of rotating responsibilities. For example, if I think the team is
getting too dependent on me to lead the meetings, I'll start assigning
random people to do it in my stead.
Generally, any single member of the team should be able to go on
vacation and things should roll on pretty much like before.
I hope that helps!
William Pietri <william@...>