Nov
7
On Incompetence
November 7, 2005 |
Agile methods make one critical assumption: that the people on your team are competent. An agile method isn’t going to work if you have some of the developers I’ve seen in the past working for you. For instance, I remember being shown the database structure for a project done by a former employer (I wasn’t involved in this one; I found out about it because a co-worker was showing the design around in horror). The account information–all of it–was implemented in a single denormalized table. The table had something like a hundred columns, including multiple customer records, account history, funds in the account, and so forth. The customer for whom this had been built now wanted to allow additional customer records to be placed into the account–which was, as a result, going to require a complete re-write of the application.
I do have similar horror stories for BAs–I recall one instance in which I saw a series of use cases which stated that there were no actors and steps like:
- The customer opens the account.
- The customer makes changes as desired.
- The customer saves the account.
…of course, the requirements didn’t define what the account information consisted of…
It’s not really fair to call this a “flaw” in Agile methods. After all, selecting a good team is one of the most important things a project manager can do. With a strong team, you have to work to make them fail, whereas with a weak team you have to work to make them succeed.
However, I do think that any method intended for use in most IT shops has to take into account that you will not, in most cases, have the luxury of building your team from only the top 10% of performers. Your talent pool is likely to be both limited and fixed. At best, you’ll be able to supplement your in-house team with a few new hires. Now, if your in-house team are a bunch of idiots, I’d suggest updating your resume. But if you assume they’re just average for the most part, with a couple of top performers, then you need to look at adjusting your approach to compensate.
The overall goal should be to let the most effective members of the team deal with the areas of greatest risk in the project. For instance, if the risk area is requirements, a strong BA can do a lot of the detailed specification of UIs, data models, and such up front, or by working to evaluate third-party products to replace custom development. A strong architect can compensate for a mediocre BA by asking that BA to focus on capturing the business process and other raw data–in essence, run things as an Agile project. A strong QA lead can force higher quality requirements and design by developing testing strategies early and articulating those strategies to the analysis and design staff.
This is a big reason that a PM should have an understanding of multiple project management approaches. A big consideration in choosing a methodology should be to shift the risk management burden onto the strongest members of your team.
Comments
What I'm Reading- Communicating requirements to different stakeholdersBA Rocks!
- Product Management Reader: 13Nov08The Productologist
- Satisficing SprintsTyner Blain
- The Decline and Fall of AgileJames Shore
- Theory is Obsolete and other touchy topicsHerding Cats
- Agile Product Managers and Agile Product Owners Living Together in Harmonyenthiosys agile product management
- Rapid Results and the Big Systems ProjectProject X Discussions
- PMBOK, Agile and the need for TheoryHerding Cats
- A 5th element for the Agile ManifestoOn Product Management
- More on Agile Product Managers and Product OwnersScaling Software Agility