How and Why to do project management in agile-based Companies?

As you know, now days everyone goes for Agile (I’m an advocate too), while many people say “We are agile”, in the meantime, when they hear about ‘Project’ or ‘Project Management’, many tend to relate them to ‘Waterfall’ and say “we don’t do project management because it’s waterfall ”.

But is that correct?

While I appreciate all the aspects of Agile in software development, but it seems lead to a few possible perceptions very often (not saying to everyone, but to many people as I can see):

1. Agile is all right, Project Management is all wrong, because it’s ‘Waterfall’.
2. Agile and Project Management are exclusive to each other, meaning if a company is ‘Agile’, then they don’t/shouldn’t do Project Management, otherwise, it’s not Agile.
3. Project Management = Waterfall

However, if we stay cool and take a step back, look at the whole thing, there are a couple of questions:

• Who said that projects have to be managed in Waterfall and why?
• Why Agile and Project Management have to be exclusive?
• We all know there is nothing perfect, so what are the limits of each one, and more importantly, what do we do to these?
• Why not to take advantages of both (and cover the shortage/limits of each other) with an integrated solution to benefit the business?

Now here are some of my thoughts from my practical experiences/lessons learn and how I did/do in my previous/current companies: 

I have been working at tech/digital/software companies over 15 years, either traditional waterfall or agile. Since 2009 I started to lead agile-based software development teams, took on internal agile coach role and was part of the team leading agile transformation in some multi-national organisations, meanwhile, I also led Project/Program Management team/PMO in the companies to deliver projects. What I learned from those actually tells me that they not only can co-exist in an organisation but also could leverage the advantages of each other and you could create an integrated, best-fit framework to your company/organisation that best benefit the business. Apparently, this should be through a systematic approach, but everything starts from knowing/recognising the natures and differences of ‘Agile’ and ‘Project (Management)’ correctly.

Recognise the essence of ‘Agile’ and ‘Project Management’

Agile is a mindset, we can apply it in the way we develop/integrate/test/deliver our software(or potentially to broader products) with some frameworks/methodologies (e.g. Scrum, Kanban, XP, SAFe, etc.). Simply speaking, it’s a better way/mindset (compare to the traditional way) that enable people to deliver software (or ‘Value’) more efficiently, but the precondition is that you run it correctly! However, software development can be a constant, long-term, never-end activity for a (software/digital) company (unless the products is phased out or the company shuts down), so applying agile practices in software development is a BAU(Business-As-Usual) .

Project (Management), first, what is ‘project’?

A ‘Project’ is a ‘Project’, Project itself is nothing to do with ‘Agile’ or ‘Waterfall’. By saying that, I mean, a project is an initiative with certain objective(s) to achieve within certain timeframe and sometimes (very often) with budget limitation. This might be because there are some commercial commitments (contracts) to be fulfilled, or can be certain market time window to be caught up, or maybe some competing pressures effect on the business. So, the key characteristics of projects are: Clearly set objectives, Temporary, One-off(coz every project has different objective), Time Limitation, Budget Limitation which set Project apart from BAUs. And a project is not necessarily only software development (of cause it can be) but can also involve collaborations/works from broader functions/teams (such as sales, account management, support, implementation, marketing, legal, finance, etc.) to achieve particular commercial goals, in this case, software development task (that done through agile framework/methodologies) will be only a part of the project.

So, Project Management is the way to manage the whole lifecycle of the projects (as defined above) to make sure they are well set up, planned, organised, coordinated, executed, communicated, and delivered, in the meantime the clients/stakeholders are looked after, then to achieve the ultimate commercial goals.

It's not really a matter to call it 'project' or 'initiative' or whatever the name, they are there. The only thing really matters is HOW you run projects (or whatever the name is). 

You see the differences?

So, if Agile and Project Management are about different things in business serving different purposes, benefiting companies from different perspectives, why do they have to be exclusive to each other? And more importantly, can projects be managed with Agile mindset rather than waterfall?

Here are some of the things/approach how I did/have been doing (together with my colleagues and teams) in my previous/current companies: 

1) Help people to understand the essence, the differences, and the reasons

I have been the first Project Manager to my current company, there was no project management practice but only agile software development process(scrum). I knew it was going to be a process for people to know, to understand, then to ‘buy-in’ project management in a purely agile-based company. The first thing I tried to do was to explain/clarify what is Project Management, what is Agile and the differences between them (their natures, purposes, etc.), and why they are inclusive and how they contribute to the business from different perspective in a different way, just like what I explained in the earlier part of this article. Buy knowing that, it got easier for people to know the reason of doing project Management while running agile software development. More importantly, put it very clear that we’re going to run project with agile mindset, take every advantage of agile rather than destroy agile practice. It helps to eliminate the concerns of introducing project management in the company. Seriously, it’s been a massive communication process and nothing changes overnight. In the first couple of months I took every possible opportunities/occasions to communicate with people in all the possible ways, through company confluence, lunch & learn sessions, kitchen conversations, elevator chats, 1on1 catch-ups, any opportunity you name ?. But it’s definitely worth, because if people get to understand these, they won’t (or less) worry about being ‘un-agile’ by doing project management.

If you're not open-minded to communicate it comprehensively, the misunderstandings and the resistances would be always there and lead things to worse circumstance.

2) Clearly define project setup criteria: When(in what cases) we will setup a project and when we won’t – so people know the why to setup a project

While helping people to better understand the differences and correlations between project management and agile, we also have been trying to clearly define in what situation we need to set up a project and in which we don’t. Basically, when an initiative meets a few main criteria as I explained earlier, we (The leadership team) should set up a new project:

• There must be a clear business objective(s);
• There has a time frame/limitation to achieve the objective(s) with important business reasons;
• The initiative will involve multiple functions (not just software development teams) collaborations heavily;
• The cost/budget has to be controlled/tracked (When applicable); 

Of cause, there are also some complementary (but not mandatory) criteria that could help us further confirm the project setup, such as the needs of project reporting to clients/stakeholders, client communications, etc.

For the things don’t meet the main criteria, we tend to consider them as BAU (Business-As-Usual).

Please noted that the criteria is not fixed one but can very depends on different companies/industries, so it’s important to consider your business circumstance and develop the best fit for you.

3) Build a project management framework/process that fully respects Agile values, principles, and practices – Apply Agile Project Management

It’s never just about setting up a project, the more important thing is HOW to run a project! To build up a project management framework that truly shares and respects Agile values/principles is the key. By saying that, it means the project management framework has to recognise the ways Agile is working. There are so many aspects worth to state/discuss in this area, but to put it simple, just take an example: The Agile Project Management has to acknowledge that there could be changes or unexpected issues at any time throughout the project lifecycle, and it’s not realistic to plan everything ahead coz we all have limited rationality as human. But Agile does not equal to ‘No Plan’ or ‘No commitment’ or ‘Delay is not a matter’, Agile encourages people/team to commit to the deliverables by teamwork through a series of good practices: Make a plan with your best knowledge, keep following up all the things up(by daily stand-ups) and observe the progress(by burn down chart), while it progresses not well take actions/try everything the team can to get it back on track, keep things transparent, and respond to changes quickly. It highly values team’s/individual’s commitment. So, as an agile project manager, you should helping/holding people/team to adopt agile values/principles correctly, in practice, the best practice is that if team’s practices are well aligned with agile values/principles, step back and observe as an consulting role, just empower/encourage people/team to do their best and be accountable about what they are doing but provide advices/suggestions where necessary. But if you realise there are some misleadings in agile values/principles, you should step in and help people/team on the right track. Helping team to apply agile values/principles correctly is the best way to advocate agile in your organisation. 

In regards to some of the most common misleadings in applying agile practice, it's another interesting topic, I may write another post when I get time.

4) Proactively educate the clients/stakeholders about the nature/benefits of Agile(if necessary) and appropriately manage their expectations – protect the space for team to advocate Agile values and principles

So let’s say your project management framework is agile-based, then managing/looking after the clients/stakeholders who might be working in a different model/framework or may have different mindset would be critical, without their understanding/supporting the agile principles and benefits, team will keep getting pressure/noise when applying agile practice and hard to get really agile. So in my company we have been actively communicating how we are working in Agile, and the reasons/benefits by doing that, to those clients who are from traditional industries/working models. The more we can influence them the more they are used to the way we are planning and delivering, because they have the expectation. More importantly, as changes happen very often in Agile projects, transparency is especially critical during the execution. Communicate/report the issues/changes/risks in a timely manner, in a clear and meaningful form, with reasonable countermeasures, action plans, proposals with the attempts to get things back on track, or provide a new reasonable estimation on the plan with meaningful reasons, to set up a new goal (expectation) where necessary.

Also, the project manager should act as a ‘team guard’ for managing the scope, priorities, and minimise the disruptions to the team, to help team keep focusing on the clear goals/tasks of the project with reasonable time and space.

Most importantly, keep in mind that we should keep delivering tangible deliverables from the small iterations to demonstrate the way we are working is good. Whatever you do/say, at the end of the day, the best/only way to build long lasting trust between clients and ourselves is ‘Delivering good results’.

So, Yes, it’s not easy! However, to reach the point where agile project management can best contribute to a company, you have to take a systematic approach and be patient, things won't be changed overnight.

Fortunately, by doing project management with agile mindset, we have had managed/delivered nearly 10 projects in the company with positive outcomes since we started 1.5 years ago, more importantly, Clients’ (from different sectors) experience in working with us on projects were significantly enhanced according to their feedbacks, which contributes to better trust and business relationship build-up.