A professor of mine was fond of saying, “We’re not building bridges, people.” His point was that the process required to build a bridge—extensive planning, budgeting and documentation, followed by execution—has been misused by the software development industry.
My professor saw engineering as a science and software development as an art, and he believed the processes to build each should be different. The result of all that planning and budgeting can be expensive websites with irrelevant or useless features. Web culture changes often and fast, but bridge culture is predictable.
Unless you’re a fearsome troll hiding under bridges, waiting for a goat lunch. In that case, you have some reading to do. Here, borrow my copy of Three Billy Goats Gruff. You’re welcome.
The Agile development approach has been gaining traction in the last few years because it aims to address the biggest factors tripping up projects. Agile is a different way to manage project teams and the processes that govern them. Agile promotes working software over documentation, customer engagement over contract negotiation, and a fluid development processes over a strict plan and timeline.
In a traditional model, change requests are a burden on project teams and a leading cause of project failures. A minor mistake can have a catastrophic impact on timelines and budget.
In other words, don’t believe those small goats: a small lunch is better than dead.
Agile avoids this by favouring short, focused, iterative development cycles. Because Agile is designed to adapt, project teams can evolve with the needs of a project and changing requirements are welcome.
Say you decide to switch things up by eating the first goat that comes along, or—even better—all the goats (you know, instead of ending up on a milk carton): Agile is flexible enough to to accommodate this.
At ImageX we start the Agile process with clients by creating a Minimum Viable Product (MVP). This isn’t the “least we can get away with,” but a set of features to satisfy core project goals: the minimum required for it to be successful.
One small goat should about do it, hey?
This gets the product into the client’s hands faster. It also allows clients and stakeholders to assess the actual product (not a diagram or description) and its usefulness sooner in the process.
When features and functionality of the MVP have been set, the remaining features and functionality are placed in a queue, prioritized by importance. These features are designed, documented and developed in the order they appear in the queue.
Once the MVP is finished, work starts on the development queue. Should a new idea come along, it can be placed in the queue without disrupting the development plan. Since development cycles in Agile are short and focused (and relatively inexpensive), the impact of change is minimized.
Now you can troll your lunch and eat it too!
The management of Agile projects requires a skilled team, a project manager with strong communication abilities, and a client willing and able to be involved in the process. Let’s get started!