News

I was once an agile project manager. In fact, I did it more than once.

If that is not shocking enough then maybe I should also confess that I have coached, trained and enabled others to be agile project managers.

In this article, I will share my experience of being an agile PM without a real product owner or team facilitator (ScrumMaster, Kanban commander, iteration manager etc). I think it worked out well, but I will let you be the judge.

Background

Some people have told me that you cannot have a project manager and be agile at the same time.

Some of these people are simply zealots who preach things that I disagree with, so I can ignore them.

But there are also people who I respect, who make some good points about why a project manager can get in the way of an agile team. Some of these people even tell me that the project manager is an “anti-pattern” or hindrance to teams trying to become agile.

So it is for these people that I thought I would spell out my thinking on why you might want an agile project manager in an agile project with agile all over the place.

But I am not claiming that you MUST have an agile project manager to deliver work in an agile way. In fact, I explored two common issues with project management in an agile context in my last two articles:

• The problem of managing a project when you want a self-managing team to manage the project
• The problem of thinking in terms of projects when agile approaches are often based on product-based thinking

Is there a textbook answer as to why you need agile project managers?

I want to justify having project managers then maybe I should consult the ancient scriptures, as they were handed down by the agile prophets. If I can find some forgotten scrolls at the bottom of agile mountain then I can look for the ancient symbols for the project manager.

But sadly, these scriptures do not exist and even if they did, the approach of digging up scriptures written by ancient prophets who lived in a different time, so that we can follow their teachings precisely, sounds like the opposite of what I think an agile approach would be.

Come to think of it, do you ever really need a project manager?

Instead, let’s go right back to basics and ask a tougher question:

Do you need a project manager at all?

Some things I work on are projects and some are not. If there is no project then I think we can end the discussion quickly – there is nothing for a project manager to manage.

So let’s say you are in a pure customer service team, where customers drop by and you serve them. In this case, agile or not, I would say that there is no need for a PM.

The same could apply to a team of 3-9 people who all artisans working on a consistent product with a single product owner who makes all the decisions. Especially if the product owner selects new things to work on each week based on whatever she thinks is important rather than some overarching plan.

But if there is a project then you might have someone to manage it.

When might you want a project manager?

I will define a project as an adventure (or endeavour) to achieve an outcome. Some adventures do not need a project manager because they are pretty easy to achieve or you are the only one on an adventure.

If you are the only one on the adventure, then you are the project “do-er” but I am not sure you could call yourself a manager.

But let us assume that you have an endeavour that involves multiple people, who set out to achieve a challenging outcome. In this case, you might consider having someone to manage the team and the resources they need to accomplish the outcome.

There is often a scope, a deadline and a budget. There is often a set of assumptions that you are making and hopefully a specific team that you on the adventure together.

Sometimes one or more constraints are fixed and sometimes the team only comes together for that particular endeavour, so it is a temporary team. But this is not always the case.

For me, there are 3 key elements that make something a project that can be managed:

• The desired outcome;
• A starting point, where the team accept the mission to achieve the outcome; and
• An endpoint, where the outcome is achieved and the project is over.

This is different from a stable team working perpetually on a single product, where the concepts of a start and end are not really important.

An example of a "pure agile" project

A number of years ago, I ran infrastructure projects in what I think is an agile way.

Infrastructure can mean different things. So more specifically, I was involved in implementing, upgrading and decommissioning servers, networks and middleware. But I used similar approaches when I was managing data conversions and solving other sudoku-like puzzles.

For example, one of my projects was to replace the ageing infrastructure that supported some existing functionality. We scoped the workout and came up with a proposal. This was the starting point of the project.

I met with multiple vendors and multiple internal teams and defined what things would look like at the end of the project. We did this in enough detail to commit to a plan of attack, but there was a lot more analysis to do after we started.

For some application teams, the end date was when we upgraded them, but for us, the end date was when the final piece of tech was stable and “SEP” or Somebody Else’s Problem. This meant that part of the project involved a hand-over to others.

Who "owned" the project?

There was a sponsor, who I could potentially describe as the product owner but he was not involved much at all.

The sponsor was IT Director and he was accountable for the IT application services provided to the internal customers.

But the IT Director saw the infrastructure as a service to be provided to his team. He delegated the authority for running the project to me and I gave him updates during management meetings. He also assumed that if his IT Managers were happy with the infrastructure then all was good.

There were also two vendors with managers who would be accountable for the ongoing services for a lot of the infrastructure and they saw themselves (validly) as the owners of the outcome.

My job was to make the vendors happy, but I worked for the end client, who was paying for the upgrade and I had to ensure we had some adequate contracts in place and that the end customer received value.

There were multiple application development teams and they each got involved when their applications were impacted. They were critical stakeholders who owned part of the outcome. But I did not report directly to them.

So that is why we needed a PM, there were multiple teams involved with competing needs and there were multiple risks and resources to manage. So I was really the “project owner.”

I made the calls and managed things within the constraints and differing stakeholder goals. I also communicated the good and bad news so people knew what was going on and I resolved conflicts around both goals and the approach to take.

Was there a stable “scrum-like team” with a ScrumMaster?

There was no ScrumMaster or iteration manager and there were really no sprints. I worked on a weekly basis, so you could stretch things and rename weeks as sprints, but they were not the basic unit for chunking the work.

Rather, I managed things in “releases.” Each release had one or more pieces of infrastructure and a defined outcome where old things were retired, things were migrated to a happy new home and new things were implemented.

Each also had a roll-back strategy and a team linked to the release.

I had a small core team, who were involved in each release. But the core team was merged with specialists from the relevant application development teams and the relevant vendors.

I also had to get each release through a swarm of stakeholders such as IT security, IT Release Management and some others. So there was a lot of important interaction outside the core team as well as inside it. I think ScrumMasters are usually focused on “intra-team” collaboration, but I was very busy with “inter-team” and “inter-company” interaction.

Then how could this strange beast be agile?

So I created a basic project charter for the project and then another basic one for each “release.” Each charter included a definition of done (or success), a test strategy, a plan of attack, and an escape plan if things went wrong.

Each delivery (release) included a warranty agreement that was more a handshake than a detailed plan. But each “release” ended when the application team and vendor teams agreed they were happy. Each also impacted support contracts and involved some payment or change in funding.

The team interaction drove the analysis and planning

We had constant interaction with the people in the team, which drove our planning. I think that is a core aspect of being agile.

Testing drove both planning and analysis

We did some analysis and a lot of testing, as people usually do in all IT related projects. But unlike “waterfall” projects, the testing did not come after the work and it was not there to validate that we had done the work properly.

Instead, the testing drove both our planning and our analysis. We would form a general plan of attack then test it knowing that it would fail. Based on what we learned we would run another test until we were confident we knew what we were doing.

We tried to make implementation routine

Based on this, our implementations were more routine that drama. This is an important aspect of agility for me.

I used to be involved in big bang releases that were huge fun and were almost a project on their own. But I learned with my infrastructure projects that this approach sucked in practice.

Instead, we would do some probing, some testing, some thinking and then some dress rehearsals. We entered the release ready for anything and usually found out that things were an anti-climax.

But we also found out that a lot of work could be done before the release and some could be done after it. So we learned to have a minimum drama “cut-over” with a lot of pre-work and some post work.

This is something I found to be generally true of many of my projects – they were about learning and feedback cycles driven by testing. They were not linear in the way other projects were – where people would scope properly, analyse in detail, plan well then execute and test.

In fact, the only way to plan many of the most complex releases I have managed was to test, break and discard plans until we were ready for the final release.

So I will say it again – we wanted our implementations to be routine rather than drama. Rhythm (er … cadence) and testing (er … learning through working with the problem) were the keys to success.

This coupled with good interaction among the key players was always the secret to being lucky.

We had an owner and a facilitator

Of course we should have had a product owner from “the business” and in fact, we did. In this case, the “business” was made up of IT people (I include in that the vendors and the application teams as the business). I was endorsed as the one who made and communicated decisions to the business.

I facilitated the interaction of the people in each “release” but the team formed and broke up each release.

Also, some of the team were working in multiple teams at once and saw mine as less important than their core team.

But it made more sense to call me the implementation manager or the infrastructure project manager rather than the “agile product owner/team facilitator.”

Was it just my projects or was there a pattern?

Before I fell in with the agile crowd, I had struggled to see how people could run a project without constant feedback loops. No matter how well I planned things, I found that my projects were more about managing the evolution of a system than executing a plan with precision.

In fact, one of the greatest books I had read on project management was about systems rather than projects – “The Fifth Discipline,” by Peter M Senge. As strange as it seems, this was my project management bible.

Later though, I read an excellent book that validated many of my thoughts and challenged many of my most dearly held assumptions. It was called “Agile Project Management” and it was written by Jim Highsmith (although the link is to the second edition, which I have not read).

This single book captured a viable life-cycle for my projects, provided templates for tracking features and even (importantly) taught me the concept of “performance cards” to commit to performance standards or quality features.

It could have been a complete guide to agile projects but then I also read “Manage IT – your guide to modern, pragmatic project management” by Johanna Rothman. This book was neither agile nor anti-agile and it filled in many gaps for me around how projects should work in the real world.

Of course – for the best chance of success you should probably do some training or coaching with SoftEd. Otherwise, you are probably doomed.

I am also happy to help and if you try reading those books and trusting your team to come up with a good approach you will actually be fine.

So I think some aspects of my experience must have been generic. Or at least other people found generic solutions to managing the kinds of projects I ran.

I did not really talk about an agile framework or an agile mindset. To me, “agile” meant a toolbox of things that make it quicker and easier to run projects.

I didn’t really get the rest of agile in those days and I have learned a lot since then, but I still think I was running good agile projects with a project manager.

I will leave you to decide for yourself if that project was an agile project or just a weird beast that included some agile like things.

An example of another "pure agile" project

Another role I had was to manage a production support team. My team looked after some organisational assets (IT Applications) and shared a core skill or craft (IT development arts and sciences).

Sometimes we even had to apologize for bad things our system did (compliance breaches, defects, workarounds). When we did this we repaired the system so it would keep working.

But we did not just watch the production system, we constantly tuned and enhanced it.

“But where is the project?” you ask

We had about 12 different internal stakeholder groups and also some external users who used some of our applications. But the external users either came through a help desk or a relationship manager before they encountered us.

These stakeholder groups all wanted changes to our applications and it would have been chaos if we tried to handle these changes in an unstructured way.

So we set up three feedback loops (feedback cycles? release cycles?):

• Immediate changes were made when we thought that they should be made, as long as we communicated what we did;
• Small changes were bundled into a weekly release so that we could control better control them and communicate what we were doing; and
• Bigger changes, as well as some non-urgent ones, went into a longer release cycle (monthly for our friends and quarterly if we had to integrate into somebody else’s project).

We bundled our slower change cycle into a project

Rather than just making changes based on priority, we developed a deliberate process for prioritizing and developing things bigger than a few days work.

• We used WAG’s to do a first cut estimate – WAG meant Wild A***D Guess and it took only 5 minutes. We used it to create a “potential stuff” backlog.
• This backlog was not final though because I ran a “user group meeting” that prioritized the work.
• My team took a bunch of changes that we said were mandatory. We also took a bunch of things we wanted to do.
• Each stakeholder came with their own list. My team did a first cut analysis of the likely candidates and supported the stakeholders in explaining their needs.
• We locked down a plan with some mandatory stuff and some buffer (er I mean important to do but we will drop them if we have to).
• We took control of things from there, but we called stakeholders in when we got to their work and we let them test everything as we developed it.
• We also had weekly progress meetings and stakeholders came along if they were interested. But the meetings were as much for our team as anyone else.
• Finally, we packaged it all together, communicated what was coming and put it all into production.
• Then we did a retro and started again.

We had an owner and a facilitator

I guess I was the product owner because I managed the process that we used to prioritize the work for the “Asset” that I was accountable for managing.

Notably, though, I was not the real owner because I did not “own the decision.”

Instead, I owned the process for making the decision and I was able to explain to stakeholders that there was justice in the decisions even if they did not get what they wanted.

Sometimes people escalated over my head or asked for an appeals process for my court of prioritisation. But generally speaking I managed those processes too, so I made sure justice was served even if senior people were grumpy with me.

At any rate, I was the one who confirmed and communicated decisions to both the team and the stakeholders. I also had accountability for the health of the product (our IT Asset).

I used to facilitate work in the team but soon another crew member took on that role. In fact, my team member soon stepped up and ran the facilitation process.

I still remember the shock he had when he asked what else I do. He thought that I was doing some project management or IT management magic …. but it turned out that he and the team were doing the management while I approved time-sheets and holiday requests.

More analysis than testing though

Unlike my infrastructure projects, there was often some meaningful upfront analysis that sometimes took longer than the building and the testing.

Investigating and research were a core part of the work and we had some BA type people who helped with that a lot. But we never completed the analysis before we built something and people signed off the final product rather than having to lock everything in up front.

The generic experience

There were a number of books I read about good operations management. But the book I really loved was “Implementing Lean Software development,” which is one of a series by Mary and Tom Poppendieck. I think if you based your entire “agile” approach on the lean concepts that are highlighted in that book then you would be OK.

If you want to go over the top then you could also read anything by Jeff Patton (especially story mapping) or Mike Cohn (especially on User Stories and Release Planning).

My team were all into agile development practices like extreme programming and things. I think all development teams should do that kind of thing. But I am not much help because my role of Figurehead meant that the team created their own practices based on the demands of their craft.

My role as “agile project manager type” was to encourage and empower them to do that, while also stopping organisational stakeholders and processes from stopping them from doing good work. Craftsmanship is critical if you want any self-managed (or agile) team to succeed.

Of course – for the best chance of success you should probably do some training or coaching with SoftEd. Otherwise, you are probably doomed.

I am also happy to help.

I think that would give you a complete set of agile practices that would work for projects and releases that are really a bunch of related enhancements and maintenance improvements that have been bundled together.

You can actually add Scrum if you like and I have seen it work well for these types of projects. But we were only ever “sort of like scrum, in a way,” and we felt agile.

Is that agile though?

This time I will let you decide if this was a project and whether it was agile. I think it was both.

But these days most “agile projects” are linked to a customer-facing problem and they have product owners, self-managing teams and things. So next time I will give my views on whether a project manager fits into that world and (spoiler alert) some patterns for implementing successful project management.

Again though it will be based on my own experience and bias, so it might not be the correct agile view.