With hundreds of students joining our national conference in just a few weeks for a special session, ‘Activate Agile’, we’ve invited guest blogger Ted Tencza (who will be speaking at Activate Agile) to tell us why he chooses to work in an Agile way.
From the early days of software development, ‘Waterfall’ was a ubiquitous methodology for managing software projects. This model was predicated on the notion that all the requirements for a project should be defined before any code was written. In early 2001, several prominent technologists got together to try to define a better way to build software. The result was the Agile Manifesto, a set of four principles defining what should be valued in development.
Why was this needed? What problems were they trying to solve? To answer this, let’s look at each principle in turn, and examine these questions.
Individuals and interactions over processes and tools – Tools cannot think independently, and processes can outlive their usefulness. It is more important that team members are skilled, informed of the goals of the project, and communicate to keep the project on track to solve the problem it is intended to solve.
Working software over comprehensive documentation – Waterfall projects tended to have extensive documentation attempting to define every possible contingency. This caused two problems: 1) it took a really long time to define requirements as project managers tried to anticipate everything; and 2) ironically the documentation became very difficult to understand as it grew more complex, making feedback less likely. Example documentation of a simple user interaction:
Req. 1.1.1. – There will be a web button
Req. 220.127.116.11. – Button will be Green hexcode 00ff00
Req. 18.104.22.168. – Button is 125px X 125px
It is far easier, more efficient, less time consuming, and a better overall experience to build a webpage with a green button to show user and get immediate feedback.
Customer collaboration over contract negotiation – It is not realistic to assume that all requirements can be known at the start, so Agile allows for new information to help inform the project. Waterfall tended to stick strictly to the contract, making changes difficult to implement with unwieldy meetings where people without the full context decided if a change would be allowed. Agile builds in short development feedback cycles allowing for greater collaboration.
Responding to change over following a plan – Things change, markets shift, owners gain more understanding with inspecting business data. While it is valuable to plan, blindly following an old plan when there is new information is foolhardy. Agile allows for responding to changes to happen much more fluidly.
Agile isn’t perfect, but it solves far more problems than the old way, and I will never go back to Waterfall.