[More Than] Project Managing
14 October 201910 October 2019 | Software Development
As a software outsourcing company with 700+ engineers onboard and more than 200 customers served, we regularly manage projects in teams of anywhere from 2 to 50 engineers. We work with anything from legacy code to the latest web frameworks.
As you can probably imagine, we’ve had the chance to experience a lot of management styles and client requirements. Each project has its particularities, but there is a common fundamental variable that can predict the success of any project: the mindset. Read further to discover our insights on Agile project management.
To begin with, we need to address the elephant in the room – Agile, Agility, and Project Management.
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, it’s expected to fix all management issues (including getting rid of the project manager). Also, working Agile suggests projects are delivered in 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 classical “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?
It might look something like this:
Image Source: Luqman Academy
We end up with four zones of operation:
- Simple – clear requirements and proven technical needs
Complicated – either:
- changing requirements and proven tech or
- clear requirements and tech experimentation
- Complex – we are now getting into the unproven tech and variable specs area
- 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.
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.
Approach: proven best practices;
Methodologies: Waterfall can be easily applied, giving a clear roadmap and milestones, predictability of the outcome.
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.
Approach: good practice – the expert will drive this; we rely on that expertise;
Methodologies: iterative approach, Agile, Scrum.
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.
Approach: experimentation; amplify success; minimize the impact of failure;
Methodologies: iterative approach, Agile, Scrum, Kanban.
Even if it sounds … chaotic, this type of project has its place in 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.
Methodologies: extreme programming, Lean, Kanban.
A Project Manager Appears
Image Source: Reddit.com
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 of the team: 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 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.
Performing teams do exist and are more-or-less self-managed, given enough time to reach such 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 in 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
We, as individuals, all have expectations about everything and anything – from the time it takes to find a cab, to the way the coffee tastes in the morning. It’s a given that our mind projects a mental image over the future, a blanket of safety and familiarity.
Because expectations live in our minds, we are free to shape them as we see fit, but there’s a caveat – our mind is isolated from outside factors.
We can predict reactions and interactions up to a point, but the reality is far too complex and chaotic for our minds to imagine far into the future reliably. So, when inevitably expectations meet reality, our minds need to handle the difference. That’s when we undergo an expectation hangover (more on this in Christine Hassler’s book with this exact title).
I’m not saying expectations are wrong – they’re actually inevitable. I’m merely exploring the possibility that we, as project managers, can develop an agile mindset that will enable us to shift towards asking “What am I learning?” rather than “Why is this happening?”.
This mindset will allow us to guide a project throughout its lifetime while, at the same time, align 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.
About the Author
Andrei started his professional journey as a software developer. Since then, he moved from team lead to project manager and then unit manager. Engaged continuously on the “team”, “project,” and “client” side of the software outsourcing world, Andrei is currently pursuing a new challenge as a Client Executive in our sales organization.