4 ms·

Can Agile work for a team of experts?

10 points by absconditus 17y ago

russell 17y ago
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.
gchucky 17y ago
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.
- deleted 17y ago
  [deleted]
- mechanical_fish 17y ago
  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.
swombat 17y ago
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 17y ago
Yes, much of the methodology can still work. This is like multiplayer Extreme Hacking (http://www.c2.com/cgi/wiki?ExtremeHacking 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.

10 points by absconditus 17y ago

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.

gchucky 17y ago

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.

deleted 17y ago
[deleted]
mechanical_fish 17y ago
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.

swombat 17y ago

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 17y ago

Yes, much of the methodology can still work. This is like multiplayer Extreme Hacking (http://www.c2.com/cgi/wiki?ExtremeHacking 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.