What is Agile?
To truly understand Agile, we need to understand the context under which the Agile Manifesto was written, way back in 2001. In the 1990’s a project was considered a failure if it was not delivered on time, on budget or within scope. These three factors are known as the Iron Triangle, and they are the foundation of the waterfall software development methodology. In 1994, the Standish Group published the CHAOS report, (no I am not making this up,) that stated only 16% of software development projects were a success. This was NOT a surprise because there were many very public high-profile software project failures that made national news, so even if you did not work in technology, you knew about some of these project failures.
On February 11th, 2001, at The Lodge at Snowbird ski resort in Utah, seventeen leaders in the software development community (who were developers by the way, NOT product managers) met to talk, ski, relax, and find better ways of developing software, the result was the Agile ‘Software Development’ Manifesto.
Agile Manifesto
What is the Agile Manifesto? The Agile Manifesto is simply a set of 4 values and 12 principles, that are intended to help organizations uncover better ways of developing software.
The four values are:
We value individuals and interactions over processes and tools.
We value working software over comprehensive documentation.
We value customer collaboration over contract negotiation.
We value responding to change over following a plan.
That’s it, that is all that Agile is, 4 simple Values. But to truly understand the four values, we need to take a look at the context in which these 4 Agile Values were written to truly understand their meaning:
We value individuals and interactions over processes and tools.
Valuing individuals and interactions, in 2001 when the Agile manifesto was written, was important because interaction between developers and really anyone in the organization was very limited at that time. Software developers often worked together in a room, with no lights on, with a door on it, that was often closed, and they were isolated from the rest of the organization. I am NOT joking, I know, because I was one of them. Interaction with developers was typically during the planning phase and was focused on getting estimates (in hours) on how long it would take to develop each and every one of the requirements. The focus during planning was to document the requirements, creating a plan, in the form of a detailed project plan or Gantt chart, and estimate the time and cost for each task. Once the plan was complete, the development phase could start, and interaction was limited to weekly status updates, where developers would communicate the percent complete on the individual tasks. There was no daily standup, only a weekly status report, due on Friday afternoon, that was focused on updating the percentage complete for each task. Therefore, if all tasks were completed according to schedule, you didn’t even have to talk. You only had to interact with each other when there was an issue, and it was not a good thing to bring up issues. It was more important to deliver what was documented, the way it was documented, which is why we have Agile value number 2.
We value working software over comprehensive documentation.
Documentation was at the core of the waterfall methodology, especially in the planning phase. The Business Analyst documented the requirements, a technical lead or architect documented the tasks that needed to be done to fulfill the requirement, and the Project Manager documented a detailed project plan based on the estimates that were provided by the development team. Then the developers executed and built whatever was documented. The reason I left my software development role was because developers just built what was documented. It was more important to report that you were 100% complete with building the features you were assigned, the way they were documented, than it was to identify any tasks that did not work, or did not work together. It was less important at the time to deliver working software, than it was to deliver the software requirements in the way they were documented.
Why? Because enterprise, or B2B software contracts dominated the industry and often included software requirements in them. The legal contracts between the two companies were negotiated for a considerable amount of time before a contract was finalized, and the contract contained requirements. The requirements for an enterprise project essentially started as a list of features in a legal contract between the two organizations. So, the second Agile Value essentially discouraged the inclusion of “requirements” in the contracts between companies, and this led to value number 3
We value customer collaboration over contract negotiation.
As I said, the reason developers coded what was documented was because the requirements of the software were often embedded in the legal contracts. When you changed the requirements, or changed the scope, the legal contract between the two companies had to be modified and this was a lengthy time-consuming, costly process. It was anything but collaborative, because it included attorneys, (no offense to all the attorneys out there, my father was an attorney) and usually meant one of three things, you increased costs, decreased scope, or increased timeline, aka you broke the iron triangle. And, if you increased cost or decreased scope or pushed out the delivery date, the project was considered a failure. So you had no incentive to change the scope, even if it meant changing to deliver functioning software. You built what was documented, and when the software was delivered, if it didn’t work, but did exactly what was documented in the contract, you created a new contract to fill in all the missing pieces.
Which led to the final Agile value:
We value responding to change over following a plan.
The final Agile Value was there to address the belief that it is better to respond to change early in the process, if there was an issue identified, then it was to continue to follow a plan that everyone knew was not going to work. The biggest impact Agile had in 2001, was on how projects were financed, funded, and contracted. Agile essentially recommended that detailed scope definitions be removed from software delivery contracts. Early adoption of Agile was slow because from a contract point, even for internal projects, it meant that software contracts would no longer include detailed requirements. Going forward contracts would state that for $1 M, Company A will build and deliver software to Company B. Generally, it would provide a very basic description of what the software did, like a CRM functionality, but the specific features would no longer be defined in the contract. Then the Agile development team would work closely with the customer and build the features that were identified as priority until the $1 M dollar budget was gone. Then whatever the final scope was, when the $1 M ran out, that would be the final scope of the project. This basic approach was the same for funding internal projects. The initial scope would be identified but not be detailed in the way it was in the past, a backlog of features would be created, the features would be prioritized, and each feature would be refined until they were understood enough by the development team to go ahead and develop. When the $1 M dollar budget ran out, that would be the final scope of the project.
Conclusion
Agile was a revolutionary change to the way software was being developed, during a revolutionary time in the history of technology and software development. Agile was just a recognition that the software development landscape was changing as the technologies we used to develop software solutions were changing. I myself applied agile software development principles into projects I managed before the Agile Manifesto was written, and I was not alone. We were all experimenting with different ways of managing projects back then, because of the change in technology, and the changing landscape driven by customer relations. The Agile Manifesto was a revolutionary change, but Agile did not start the revolution, the revolution had started long before the manifesto was written.