Wednesday, April 14, 2004
Beyond Methodology
This session turned into an open discussion on the pros/cons of following methodologies in software development. The presenter clearly had an opinion that they should generally be avoided (and bug tracking systems!) - though the group saw the need, the general consensus was that following a methodology and expecting it to run your project / solve world famine was the wrong expectation.
Other facets mentioned:
The discussion was pretty lively with a whole bunch of different opinions and experiences coming out. It was clear that while everybody had some commonality of experience, there were a few differences that emerged. One guy said he used to work for a firm that had a strict method of delivery, which most of the teams didn't like very much, however he reckoned they could deliver almost all their projects to within 10% of the estimate.
I think it became evident that the speaker had been burnt rather severely on a few projects where a methodology ruled the roost at the expense of team members or dynamics.
This session turned into an open discussion on the pros/cons of following methodologies in software development. The presenter clearly had an opinion that they should generally be avoided (and bug tracking systems!) - though the group saw the need, the general consensus was that following a methodology and expecting it to run your project / solve world famine was the wrong expectation.
Other facets mentioned:
- The need to develop the developers, in terms of growing staff.
- The requirement to encourage good quality communication between team members
- Valuing dev intuition on design
- Using spikes to reduce risk
The discussion was pretty lively with a whole bunch of different opinions and experiences coming out. It was clear that while everybody had some commonality of experience, there were a few differences that emerged. One guy said he used to work for a firm that had a strict method of delivery, which most of the teams didn't like very much, however he reckoned they could deliver almost all their projects to within 10% of the estimate.
I think it became evident that the speaker had been burnt rather severely on a few projects where a methodology ruled the roost at the expense of team members or dynamics.
