Martin Griss of CMU West and Adam Blum of Mobio Networks had a fairly interactive discussion about integrating traditional software engineering practices into modern service oriented development.
Griss is a big proponent of agile development, and believes that the traditional software development process is too ponderous; Blum admits to benefits from smaller teams and lightweight process for faster delivery, but he believes that some of the artifacts of traditional development methods provide value to the process.
Griss’ problems with traditional development are:
- Too many large documents
- It’s too hard to keep the documents in synch with each other and the development
- People spend too much time in document reviews
- Use cases are too complex
- Can’t react well to changes in requirements
- Schedule and features become omnipotent, rather than actual user requirements
In response, Blum had his list of problems with agile development:
- Some things really do need upfront analysis/architecture to create requirements and specification, particularly the lower layers in the stack
- Team management needs to be more complex on larger projects
- Many agile artifacts are simply “old wine in new bottles”, and it’ simply a matter of determining the right level of detail
- If you have a team that’s currently delivering well, the introduction of agile processes can disrupt the team and impact productivity — if it’s not broke, don’t fix it
- Some of the time-boxing of agile development (e.g., SCRUM monthly sprints, daily 10-minute meetings) creates artificial schedule constraints
- Agile development theory is mostly pseudo-science without many facts to back it up
- Modern tools can make older artifacts lighter-weight and more usable
Writing requirements and specifications is something that I’ve spent probably 1000’s of hours doing over the years, and many of my customers still require this methodology, so I’m sympathetic to Blum’s viewpoint: sometimes it’s not appropriate or not possible to go agile.
An interesting point emerged from the back-and-forth discussion: it may not be possible to build the development platforms and frameworks themselves (such as what Mobio builds) in an agile fashion, but the applications built on those high-level platforms lend themselves well to agile development. Features to be added to the platform are effectively prototyped in an agile way in applications built on the platform, then are handed off to the more traditional, structured development cycle of the platform itself.
Griss, who was partially looking to just stir up discussion earlier, pointed out that it’s necessary to take the best parts of both ends of the software development methodology spectrum. At the end, it appears that they agree that there are methodologies and artifacts that are important, it’s just a matter of the degree of ceremony to use on any given part of the software development process.