Why the Industry Needs Agile Project Management
Written by Nick Bruecken
“There is a tremor in the force.” – Darth Vader
I don’t usually like to start out a post with a quote from someone as foreboding as Darth Vader, but there’s no better way to say it. In my nearly 20 years as a project leader (certified in both scrum and project management), this is the 3rd time I’ve felt such a tremor. All of them center around businesses seeking more dynamic approaches, and leaders, to deliver their software projects and build excellent teams.
The first tremor I felt was my journey into the world of the Project Management Professional certification or PMP. At that time, “project manager” meant a lot of things. Then came along the PMP certification (tailored to software development) that helped create a structure for what good project management is. Hiring managers looked for it when placing leaders to manage their software projects. In order to get on the short stack of resumes for a project manager role, this certification became necessary.
At a high level, the certification taught balancing the triple constraints (budget, scope, time) and all the activities related to how to keep them in balance. This starts with the concept of a waterfall approach. In short, waterfall meant applying a sequential phasing where you cannot start the next phase without finishing the current. The triple constraints supplied a sense of order. Project success was defined as being the triple constraints were in balance.
However, waterfall turned out not to be software development’s friend. In order to manage triple constraints, it required heavy up-front planning and stage gates to report on progress. It simply wasn’t flexible or adaptive enough to address the fast-paced environment of software solutions to meet the needs of its customers. Once again, the practice started to shift and I began to feel another tremor. This one led to a shift to iterative development or sprinting.
At first, this was used experimentally because it was harder to communicate progress in the project management structure. Instead of finishing a phase before moving to the next, they were all mixed together in smaller increments. Trust in the process had to be earned. Eventually, it gained steam and steered to things like agile transformation and the promise of increased efficiency and frequently delivered value-added features to your software!
To complete the transformation, one must toss aside waterfall management, and focus on high-performing teams that can deliver predictably. Scrum became the dominant approach to replace waterfall practices. Lines were drawn. You were either waterfall or agile, and you cannot do both.
Which brings us now. The latest tremor. It seems organizations are unsure where to go because the industry has not offered what they seek, or if it has, it’s not clear how to ask for it.
By now, most companies and technology teams have an understanding of both approaches, as well as their limitations. For example, to be able to meaningfully manage the triple constraints, project management focuses on planning. Lots of planning. Maybe too much planning. The common glitch in the process is that project managers usually fall in love with the plan, lose track of the project’s purpose, and become less willing to change during the execution of the plan. It becomes more important to say why the plan is off track instead of how to change to meet the project’s value.
In a traditional agile approach, there is a focus on value, iteration, continuous improvement and working software being the primary measures of success. Most agile approaches use scrum and a focus on building high functioning, empowered teams that deliver predictive value over managing the triple constraints. Metrics are setup that measure the team success over project health. The trap that gets set is a team can commit to work in a sprint and even deliver it, but the value being delivered does not meet the cost to continue funding the team.
Understanding these limitations allows us a gateway to the of the best of both worlds, by structuring things that avoid these common pitfalls. The industry is trying to adjust, but no clear terminology has yet broken through. Research to date is leading us to a place called Agile Project Management. A simple merger of the approaches.
In agile project management, an agile project manager can set the boundaries of triple constraints while implementing agile minded team(s) to deliver the work. Monitoring spend, progress and risk evaluates the health of the project. Additionally, the project plan can include non-development activities not found in agile teams such as training, communication, production support, rollout, etc. Simultaneously, the same role can help enable an agile mindset within the teams and across the project. Iteration that encourages regular feedback loops between technical and business teams remains. This makes it easier to adapt to changes in the landscape and plans. As we iterate, we modify the project plan, cost, scope, and schedule. We don’t fall in love with the plan, we continuously review it to ensure it’s aligned with business goals and value.
Agile project management delivers 2 assets: Project outcomes and high performing teams. Project Management is too commonly branded as waterfall and incapable of being agile. Agile is too commonly labeled as chaotic and incapable of having guardrails. The issue isn’t the approaches. It’s the fight amongst them and stereotypes that have taken hold. Companies just want to get things done, and they want to have visibility into how its coming along both at the funding level, as well as the outcome level. We can give them that.
*Star Wars Nerd clarification: I used “tremor in the force” as a reference over say, “disturbance in the force,” intentionally. Disturbances tend to be more serious (planet destroyed, new enemy, etc). Tremors seem to be more evasive, as though more research is needed and we don’t yet know the level of seriousness. Both serve a purpose, but I don’t know if this subject qualifies as a disturbance…yet.