Agile Project Management: Working Within Complex Adaptive Systems
Hi Andrew. If anyone asks you what I do for a living you, it's pretty simple: I'm a Project Manager, an Agile Project Manager to be a little more precise. The Agile part of the title is important in that it lets people know that I choose to manage projects differently than other more traditional managers. It's also important to note this distinction: I don't manage Agile Projects - I am an Agile Manager of projects.
So what is the distinction in being an Agile Manager? Let's start with this premise: software development is hard to do well. We know this because our success record for projects is pretty dismal and this is not because we haven't put our best people on it. Great developers and analysts and managers and architects have been working on software development efforts for years and we still have a dismal record of success.
One of the reasons that software development is difficult is that software is complex and the development process is equally complex. So in trying to manage the complexity of software and software development one of two approaches can be taken.
The first approach to managing complexity in a software development project is to try to control the complexity in the project by keeping things as static as possible. This is one of the fundamental tenets of the waterfall approach to project management that results in the following practices:
So a new approach to software development has emerged - Agile Project Management. Agile does not attempt to keep things static but rather embraces change. Agile manages complexity by keeping things as simple as responsible and by constant learning and adapting to the changing conditions surrounding the project.
As an Agile Manager of projects I attempt to create environments where complex systems can adapt as the organization, customer and development team learns. Agile uses the following practices in managing these Complex Adaptive Systems:
So what is the distinction in being an Agile Manager? Let's start with this premise: software development is hard to do well. We know this because our success record for projects is pretty dismal and this is not because we haven't put our best people on it. Great developers and analysts and managers and architects have been working on software development efforts for years and we still have a dismal record of success.
One of the reasons that software development is difficult is that software is complex and the development process is equally complex. So in trying to manage the complexity of software and software development one of two approaches can be taken.
The first approach to managing complexity in a software development project is to try to control the complexity in the project by keeping things as static as possible. This is one of the fundamental tenets of the waterfall approach to project management that results in the following practices:
- Get the requirements right from the start so they won't change during the course of the project;
- Define your architecture up front and try to anticipate anything that the application may be required to handle in the future;
- Commit to the estimates that your team makes at the beginning of the project and stick to them throughout the project;
- Establish standard methodologies in your organization to assure that each project is done the same way.
So a new approach to software development has emerged - Agile Project Management. Agile does not attempt to keep things static but rather embraces change. Agile manages complexity by keeping things as simple as responsible and by constant learning and adapting to the changing conditions surrounding the project.
As an Agile Manager of projects I attempt to create environments where complex systems can adapt as the organization, customer and development team learns. Agile uses the following practices in managing these Complex Adaptive Systems:
- User Stories are gathered just-in-time during development of the software so we get the freshest requirements for the system
- The highest priority User Stories are developed first so we don't over-complicate the software with features that are not really needed
- Architectures emerge through coding, not by big upfront design
- Working software is delivered early and often for feedback from the customer
- Development teams self-organize around what works best for their team