

Can Agile work for a team of experts?  - absconditus
http://www.brendel.com/consulting/blog/2009/07/can-agile-work-for-team-of-experts.html

======
swombat
This is why a methodology, whether it is agile, waterfall, or some bastard
spawn of RUP, is not enough to direct a project. What you need is someone who
can take on the role of _project manager_.

A project manager has many roles, but one of the most important is to figure
out which bits of the chosen methodology do apply, and which don't. There is
no such thing as a "best practice" - only a "good practice within a certain
context". The PM's job is to figure out which practices match the current
context, and monitor them as the context changes and certain practices drop
out (and others drop in).

What you end up with, if you have a good PM, is a unique methodology tailored
to your specific project, which is the only sensible thing, since all
combinations of project and project team are, in fact, pretty much unique.

It's worth adding that the PM doesn't need to be full-time - but I'd say that
even on a 2-3 people start-up dev team you need at least one person who's
experienced enough to take on that role.

------
caffeine
Yes, much of the methodology can still work. This is like multiplayer Extreme
Hacking (<http://www.c2.com/cgi/wiki?ExtremeHacking>). The full-on testing,
DRY code, tight iterations, and frequent releases to the user all still apply.

Each user feature probably requires spiking through the expertise of all 4
devs. If people don't work together, APIs and workflows can diverge and then
integration becomes horrible. So everyone (+client) has to get together to
build acceptance tests and integration tests between different layers of the
framework.

And I think the article is wrong - pair programming _does_ work here, but not
on domain-specific issues. The most useful way is to pair program the
interfaces between layers/silos.

The database guy and the kernel guy should pair program the kernel module that
spits data out, and the DB module that loads its up. This gives each person a
feel for the other's assumptions, and lets them lay out a smarter interface
that takes advantage of both devs' silo'd domain knowledge.

Also, even if you don't do cross-silo pair _programming_ , code reviews are
still useful. This can be totally informal, but saying "Hey can I walk you
through my code?" discovers a lot of bugs, stupid misunderstandings, etc.
Doing it frequently (daily) is useful because it makes you code with the
understanding that you'll have to show it off later to someone who _won't_ get
it unless it's really clear - so the code stays clean, thus (hopefully)
better. Once again, the bonus is that a common metaphor emerges even among
more disparate members of the team.

The point of Agile is that it's _agile_. As in, nimble. Flexible. Suited to
your requirements. Subject to your needs and intelligent application.

------
gchucky
My current team is facing the exact same problem. We're doing Scrum, but our
team isn't nearly as interchangeable as the Scrum dogma would like. Example:
some of us are better at UI, some of us are better at IA, and so on. So while
we're all supposed to take what's next on the list, it never really works out
that way, and we actually end up picking what we're most comfortable with.

I'm curious as to how other people deal with this.

~~~
mechanical_fish
We do exactly what you do. And that's fine.

A good methodology is not like SQL programming. The system doesn't explode if
you don't follow every rule to the letter. In the immortal words of R. A.
Heinlein, a methodology is an art that you pursue rather than a goal that you
expect to achieve.

A methodology is like playing Dungeons and Dragons. There are rules. You
gather together, you play the game, and you generally follow the rules. But
the DM is empowered to bend or break any specific rule if it makes the story
better or brings the game closer to the goal.

Many RPG designers have suggested that you don't even need the rules. You
could just gather everyone in a room and say "okay, let's all pretend that we
are elves and dwarves". And that can work. The very _best_ storytellers can
get away with this. But, in general, people prefer games with rules, even if
they're very sparse and loose rules. They provide important structure, and
they give you an excuse for saying or doing things that other people might not
like.

------
russell
There's more to agile than pair programming. One person can be agile. Things
like compressing the requirements and design phases. Do things in small steps
to get them in customers' hands. Release often. Iterate.

