[More Than] Project Managing

Software development companies that work with international clients to shape their business & future regularly manage projects in teams of anywhere from 2 to 50 engineers. They work with anything from legacy code to the latest web frameworks.

Each project has its particularities, but a common fundamental variable can predict any project’s success: the mindset. This article takes a deep dive into Agile project management to offer insights and a new perspective.

Agile, Agility, and Project Management

We’re all riding the “Agile Transformation” bandwagon whether we like it or not. It’s happening all around us. Agile is like a massive band-aid of productivity that, when applied, is expected to fix all management issues (including getting rid of the project manager). Also, working Agile suggests projects are delivered on time and within budget. But here’s the catch: Agile should give us only one thing – the mindset; not the tools, not the routines, not the schedule, not the metrics, just the mindset – and if everybody is on board, it works flawlessly.

The problem is that most times we mechanically do the routines but fail to understand the underlying reasoning for having them in place. Start with the mindset, and the ceremonies will follow.

But wait, I’m using “Agile” wrong (as Dave Thomas points out in his rather dramatically named „Agile is dead” talk). Agile is an adjective, not a noun, not capitalized (auto-correct is actually pointing this out). To have agility (this is a noun), there needs to be something that is agile – an athlete, a car, a team, an organization, a mindset. Thus, we cannot do Agile, we have to be agile; and this applies to every person and stakeholder involved in the project.

Agility means that we are chasing a moving target. Yes, it feels that we sometimes go left and right, following a longer path. We rewrite code; we discard yesterday’s code; we challenge the need for some code. All this for staying on target. And that’s good. You wouldn’t want to wait around until the target has stopped moving; put a pin on the map and then start heading in that direction. If you do, by the time you get there, there might not even be a target to grab.

Let’s see how to approach a project and which scenario benefits most from agility.

Embracing Agility in a Software Development Project

So, how do we start? How do we embrace agility? What makes one project a good candidate for an agile approach?

I would argue it boils down to answering two questions. Does the client know exactly what it is that he wants to create? And do we, as a software development partner, know exactly how to mix and match the myriad of software technologies to make it all happen?
We can plot this on a graph with two dimensions:

• Requirements uncertainty – from low to high, where a low uncertainty means that the requirements are crystal clear. We see this a lot in highly regulated industries, where the level of detail is plentiful. On the other end of the spectrum, high uncertainty in requirements means that we usually get a one-liner that outlines the vision, the now classic “We must implement a web app;”
• Technical uncertainty – unsurprisingly, from low to high. Here, we have a spectrum again. It is based on the developer’s understanding and maturity in the technology used. How confident are we that every use case is technically feasible?

We end up with four zones of operation:

1. Simple – clear requirements and proven technical needs
2. Complicated – either:
   1. changing requirements and proven tech or
   2. clear requirements and tech experimentation
3. Complex – we are now getting into the unproven tech and variable specs area
4. Chaos – this is the riskiest zone – where the requirements change constantly, and the technology gets developed along the way.

Dave Snowden defines these zones in the Cynefin Framework.  But how can they be mapped to project management?

Let’s take each one at a time and explore the best approaches to managing such challenges.

Simple Projects

We’re dealing with a predictable outcome; the timeline becomes clear; there is a proven solution for the project; the technological stack is mature and well-supported. In such scenarios, the decision model we use relies on categorizing the problem. This is the only critical part – making sure we understand what we need to solve, and the response becomes self-evident.

Strategy: understand-categorize-implement;

Approach: proven best practices;

Methodologies: Waterfall can be easily applied, giving a clear roadmap and milestones, predictability of the outcome.

Complicated Projects

Although we’re entering the challenging areas of uncertainty, there is still hope.  We know there is a correct answer to the problem and an appropriate technical solution. However, it’s not self-evident. Some understanding of the surroundings is essential – whether this means business or tech know-how. An expert should join the project to bring some clarity.

Strategy: understand-analyze-implement;

Approach: good practice – the expert will drive this; we rely on that expertise;

Methodologies: iterative approach, Agile, Scrum.

Complex Projects

A complex system by nature has light causality – changing one part does not give a predictable output and might have a big impact on the outcome. Ever-changing requirements, for example, mean that we’re forced to build on top of a flexible design. We dare not dream of a fail-safe design at this point, because the system, by nature, changes over time. It’s better to experiment and adapt, incorporate what works, discard what doesn’t.

Strategy: probe-sense-respond;

Approach: experimentation; amplify success; minimize the impact of failure;

Methodologies: iterative approach, Agile, Scrum, Kanban.

Chaos Projects

Even if it sounds … chaotic, this type of project has its place on our list because this is where innovation comes from most of the time – exploration beyond best practices, thinking outside the box. We do need to tread lightly, as there is the pitfall of losing focus and control. Having no requirements and innovating as we go along forces us to act quickly, to stabilize the ground.

Strategy: act-sense-respond;

Approach: innovation;

Methodologies: extreme programming, Lean, Kanban.

A Project Manager Appears

So, we’re starting a project, now what?

As a client, it’s hard to justify the benefit of having a project manager in charge of delivering the software project. In most cases, clients expect a self-managed and self-organizing agile team, able to start and keep the momentum going.

Keeping these in mind, I see two areas where a project manager can fundamentally impact the success of a project and ensure the best output from the team: a project engagement strategy and team development. Let’s dive a bit into each of them.

Project Engagement Strategy

When presented with a new project, any manager can classify it based on the types of projects presented above (Simple, Complicated, Complex, and Chaotic). Keeping in mind their specific engagement strategy, the project manager should be set on a course towards the best outcome.

I envision a project manager being able to evaluate the surroundings and be experienced enough to select a suitable development methodology. Also, to establish some rules for the game, set valid expectations, and make sure all stakeholders are aligned and aware of the journey that lies ahead.

Team Development

Performing teams do exist and are more-or-less self-managed, given enough time to reach such a level; however, their journey has been long and with ups and downs.

It’s the PM’s goal to guide a new team and the project’s stakeholders through all the stages of maturity: storming, forming, norming, and finally performing. Even if the team members knew each other and were performing flawlessly on previous projects, getting on board with a new client means that some things do change. Also, the team needs to adapt and create new norms and ways of working together.

All this happens smoothly when a mindful and present project manager is facilitating the interactions along the way.

This leads us to the last section – expectations and mindset.

Setting Expectations and Aligning a Mindset

Project managers need to develop an agile mindset that will enable them to shift towards asking “What am I learning?” rather than “Why is this happening?”

This mindset will allow them to guide a project throughout its lifetime while, at the same time, aligning all stakeholder expectations step by step to minimize the difference between them and reality. In my mind, this is the true value of a project manager – mindset over hyped expectations.