7 sins of Agile Project Management
First of all, let me make it clear: I’ve nothing against project managers, or at least most of them. I’ve been one for many years. However, project management (not managers) used in Software Product Development usually makes more harm than good. And there are systemic reasons for that.
What’s project anyway?
Let’s look at the definition of Project. Here’s one from Wikipedia:
“A project is a temporary endeavor designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or staffing) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value.” (https://en.wikipedia.org/wiki/Project_management)
So we have a clear start, a clear end, clear goals and objectives. How many times you’ve seen these in software development? Or, how many times you’ve seen these changing as a result of new knowledge and changes in the environment?
Product, not projects
Projects are time-bounded. Work usually ends with project closure. Therefore it’s critical to control three dimensions (time, budget and scope). However, that’s not a case for the majority of software products. Most of them are continuously being developed, usually for a decade or more. Have a look at Facebook, Google Search or Booking.com. They are constantly modified, improved and expanded. Even the embedded systems are the base for next version of the product. I’m pretty sure that a lot of code from iPhone 1 can still be found in iPhone X. Personally, I’ve seen a code that was older than me. Therefore, as long as there will be customers, development of software products will continue.
Seven sins of Agile Project Management
Using project approach to product development has significant consequences. Below I list seven most important I’ve observed in different organizations.
1. Long planning cycle
Project management needs to control costs. Therefore before development starts, goals are translated into requirements, so that precise costs estimates can be provided. Defining scope, estimating and approving budget takes time. I’ve seen projects in which more time was spent on analysis approval than on development and delivery. And as Tom DeMarco said “All projects that finish late have this one thing in common: they started late”.
2. Many parallel projects
Long planning cycle leads to many projects being in progress at the same time. Once, I’ve visited a bank where IT department of 40 people was responsible for 120 projects in different phases. That leads to a lot of overhead of complicated planning, tracking and reporting, not to mention a waste of multitasking. That increases projects’ lead time even more and organizations’ inability to change direction quickly.
3. Fight for people and resources
Many multiple projects lead to constant fights between people responsible for delivery, as they try to get people and resources needed. In many organizations, it’s a developer who decides what to focus next. Even worse, in some cases, people are so busy trying to do everything at once that they fail to finish anything.
4. Focus on scope, not the goal
Project management focuses on executing the plan. Any change to scope increases the risk of delay. Even with “agile” techniques, adding new features is rather seen as necessary pain. Which is exactly opposite to discovery we’d like to see in product development. We need to focus on maximizing value - run experiments, validate hypothesis, change direction, get quick feedback and act upon it. Adding new ideas and removing already planned makes a lot of sense as we learn what customers really need and how they are using our product.
5. Implementing unnecessary features
There’s no incentive in project management for questioning the scope. However, from the product perspective, any unnecessary feature does not just generate costs of development. There are even bigger expenses related to maintenance, testing, bug fixing and increased complexity generated by any functionality.
6. Reducing quality
With a deadline approaching there’s tendency to ‘push a little harder’. Most developers react by reducing the quality a little bit by skipping refactoring or testing and using complicated but working solutions. Year after year, this approach slowly, but steadily creates technical debt, making the product hard to develop and maintain. However, the consequences do not impact the project, as it ends when a deadline is met.
7. Conflict between Product Owner and Project Managers
In the organizations trying to deliver projects using Scrum there is a natural conflict between Product Owner focusing on value and project managers focusing on executing the plan. If project managers win, then Product Owner has no authority over the product and his/her role is reduced just to backlog management. If Product Owner makes decision, then project managers have responsibility without authority
Is it so bad?
Some of these examples might seem to you as extreme. Many organizations do their best and fight hard with negative consequences of using project approach for product development, reducing the impact of these practices. Some organizations have to use project management for different reasons. However, at the end of the day, wouldn’t it be just easier if we’d abandon project management in products which do not need it?