Okay, so let's think through the problems that Agile attempts to solve. The biggest issue I've faced as the owner of a development company was the inconsistency with development projects. I had a software development company building online applications for the insurance industry. So between 2000 and 2005 our development process went something like this. Our business analyst wrote a business requirements document, our development lead wrote the functional specification, and as a team we built a time and budget proposal for the end-to-end application build. The customer signed off the specification timeline and budget. The project managers ran the project using Microsoft Project, and the get chart was the source of truth for us all. But here's how it played out in reality. Pretty soon into the development the customer realized they needed something not described in that functional specification. The customer would create a change request. 

We would document the change request, estimate the work required to fix it, propose a change cost if it was required, and ask the customer to accept that proposed change. Now this process would happen over and over. It was slow and painful. Now we did practice RAD, or rapid application development, practices in how we built our code. But the agile documentation that came available in 2005 really made it easy for everybody to understand how to do this. It wasn't an overnight shift by any means. But straight away we could see how agile made it easier to discuss and share ideas. Agile was popular with customers as well as with developers, and so over time agile became more prominent in how we designed and delivered software projects. The most improved change for me was moving away from having a static project specification document, as inevitably the requirements of the application would change, as we all learnt more about how the end users actually needed to use the software. 

As the developers that meant we would actively discourage any change from that specification. Change was seen as a problem. We immediately labeled any change an exception. An exception meant we had to renegotiate the overall project timeline and budget with the end customer. Now this made for a kind of compromising working environment as the customer just wanted software to do what their end users needed, and we just wanted to complete the project on time and within budget. So running projects like this for five years was hard work, and honestly success was hit and miss. When agile became more prolific in 2005 I leapt at it with open arms and I changed my way of thinking about projects and code. So let's review the problems agile sets out to solve. The first is that traditional documentation doesn't adequately record and reflect the actual requirements. It's so difficult to describe and capture user requirements in a traditional requirements document. The problem is that requirement documents are static snapshots of a set of requirements that doesn't suit software development. And I think we all have struggled to describe functions and features using this functional requirements format. Now business analysts spend a long time writing requirements. 

Customers try to match them back to what they originally wanted and developers tend to avoid them. So the functional specification document was an unpopular part of the project. And the proposal that accompanied the functional specification was, at best, a projection based on what that point-of-time snapshot should look like. So with the traditional project plan we worked to a critical path. If one aspect of the project takes longer than expected, the entire project would be impacted. So the second problem is that it's difficult to manage projects in a linear manner. Projects, and life in general, is a series of irregular events, things in life and so in projects rarely flow evenly from one event to the next, like a get diagram does. So trying to apply a linear order to things is like trying to make water flow in a straight line. Agile encourages events to occur concurrently and independently. Third issue agile attempts to solve is the top-down approach to projects disempowers our most important asset, our team members. The intelligence of individual contributors. The concept that developers are unable to manage themselves without the expertise of a project manager is a myth in my view. To get the most from collective sums of parts we need to encourage self management by empowering people to self prioritize, take initiative, and to act autonomously. And the fourth one is testing. In traditional projects testing is nearly always last, which means that often just doesn't get done 'cause you're already out of time.