Agile Project Management

One of the tenets of agile Programming is "working software", which can be interpreted any number of ways, but always boils down to the fact that agile developers should plan on delivering a "shippable" build more frequently than developers using traditional methods. This actually puts a lot of focus on the agile project manager, because they need to more closely monitor both the quality of code as well as the coupling of code to other systems and services. In my experience, most project managers tend to look at agile development methodologies and classify them as valid for small projects. They tend to ignore them for larger projects, which in my opinion is a huge mistake.

Service Oriented Architectures and Agile Projects

When Service Oriented Architecture (SOA) started becoming the buzzword in the software industry, developers began to look at their products and made a concerted effort to break the components into building blocks that were all disconnected from one another yet functioned together as a whole. This process fits well with the object oriented world, and most development toolkits and patterns take SOA for granted these days. In my opinion this same transformation needs to occur in the Project Management world. Project Managers need to do the same thing with their projects. Break them down into sub-projects and then look at each of those as a candidate for using agile development methodologies.

Decoupling and the Agile Manifesto

Remember that the Agile Manifesto states that customer collaboration should be valued more than contract negotiation (which in this context means that you let the customer drive your requirements as opposed to developing to a strict set or predefined ones). This is very hard for many project managers to accept, but can be very helpful when trying to decompose, or decouple larger projects into smaller, more agile ones. Take for example a highly-coupled software system (say that it performs a configuration management function) that has a 1 year development cycle for each release. Trying to switch the entire project to an agile-based methodology would be doomed to failure. Decoupling both the software components and the projects around them however stands a fair chance for working well in the Agile world.