This post is part of a series on IT consulting.
Both Waterfall and agile methodologies are steeped in good and bad practices, dogma, and myth. Most successful projects succeed in spite of their chosen methodology, rather than because of it. The point of this post is to list some useful practices regardless of any methodology you might use.
- Change board
- Cross-functional teams
- Daily builds
- Design for change
- Evolutionary delivery
- Evolutionary protyping
- Goal setting
- Principled negotiation
- Risk management
- Staged delivery
- Stakeholder management
- Throw-away prototyping
Begin with the end in mind. Jumping into code on the first day is tempting (I often do), but make a plan. If you’re handling credit card data, you’ll encounter the Payment Card Industry Data Security Standard (PCI DSS). If you’re writing an application that’s subject to legislative constraints, you’ll encounter change when the legislation changes. If you want to view orders by customers and products by sales volumes, you’re going to encounter relational issues that aren’t suited to document databases. You don’t need to spend weeks at it, but it helps to know what "finished" looks like (even though finished at the start will inevitably not resemble finished at the end).
A cross-functional team is one in which all roles are committed to the project from start to finish. This has a number of benefits. First and foremost, communication within the team will be excellent, and the communication gaps inherent in Waterfall go away. Next, if for example the user experience role is available throughout the project, it becomes easier to refine the user interface later in the project.
Late-stage course changes won't cost an arm and a leg.
Building a prototype means creating a model of the final system. It’s not the system, but something that resembles it. It may not contain the performance, security or operational aspects of the final solution, but it might well provide an indication of its function. The prototype can be used to validate requirements – in fact, it can be used to completely replace the requirements gathering phase of a Waterfall model. Prototypes can be discarded in favour of a new production solution, or they can be evolved to become the production solution.
A proof of concept is a small project (no more than a single, short iteration) in which a design decision is proven. Good candidates of a proof of concept are any aspect the team is unsure about, or hasn’t done before. Proof of concepts are typically used to validate technical design decisions. They’re usually discarded, but their teachings are applied to the solution being built.
Design for Change
Change happens. It happens with the tedious inevitability of puberty. Anticipate it.