Agile Work Management

I want to revisit Agile Project Management, something I talked about before. That first post was a brief introduction to a project management system that is gaining popularity. What I didn’t talk about at the time were the problems I see with Agile. Despite being called Agile Project Management, it is actually more of a work management method than a project management method. Agile will never be able to tell you if you should be doing a project, it will only give you the most efficient framework for doing the work.

These differences become clear if you look at books covering the different project management methods. Take Agile Project Management by Jim Highsmith and look up budget in the index, you get a range of four pages. Those pages are actually a summary of Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap by Jeremy Hope. Look up cost and you find absolutely nothing. Compare this to PMBOK where budget has four different index entries and cost has an entire column on an index page. Agile is wise to put aside issues. Attempting to work them into Agile would complicate the system and take away some of the efficiencies it promises. The fast and loose way Agile suggests playing with budgets and costs might be possible in a startup or large tech company, but it becomes increasingly difficult in the library world. For example, if the project requires new skills among the team, Agile assumes the next sprint (timeboxed work period) will make training a priority and relevant team members will stop work on the project and jump straight away into training. A company facing a deadline for a product launch might be able to do this, but you’d have trouble finding a library that could.

Agile also makes some assumptions about roles that could potentially cause problems. The Agile team structure of Scrum Master, Product Owner, and Team Members puts a great deal of responsibility on single individuals. If a team has a dedicated product owner with a laser like focus, it stands to reason they will be able to easily assign priorities and guide the goals of each sprint. However if the product owner doesn’t have these traits, or perhaps simply misunderstand the message from a group of key stakeholders, an entire sprint could be wasted. And if you’re talking about a large team of developers , the costs in money and personnel hours could be monumental. Agile was created to solve the problem of projects that were either misguided from the start or unresponsive to change. Agile allows for more times to catch and correct problems and to be more responsive to change, but it does so by often relying on a single person.

So, is there place in project management for Agile? It’s wide spread adoption clearly shows this is the case but right now it can’t completely replace traditional project management. If you look at the traditional PMBOK process areas: Initiating, Planning, Executing, Monitoring/Controlling, and Closing; Agile only really addresses Executing and parts of Monitoring/Controlling (some aspects of Closing show up in the retrospectives). I don’t think there’s anyone out there that really likes working on Earned Value Management but it is crucial to guide what projects you take on.

I enthusiastically await a post-scarcity future where everyone can ignore budgets and costs like Agile does. But sadly we aren’t there yet and it seems as distant as other things you see in Star Trek like replicators, transporters, and warp drives. So until that time comes, there won’t be one project management methodology to rule them all.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s