True confessions. I was an agile project manager

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 (scrum master, 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 still have a project with a project manager even when you want to be agile.

However, 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 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 text book answer to why you need agile project managers?

Since I want to justify having project managers, 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 project manager. These might then explain where the PM fits in.

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 of the things I work on are projects and some are not.  If there is no project then we can end the discussion quickly – there is nothing for a project manager to manage. 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 endeavor) 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.

On the other hand, let us assume that you have an endeavor 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 have been made and hopefully there is a specific team that join the adventure.

Sometimes one or more constraints are fixed and sometimes the team only comes together for that particular endeavor, 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:

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

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

An example of  “my pure agile project”

Let’s look at an example.

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

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

One my projects was to replace the aging infrastructure that supported some existing functionality.

We scoped the work out 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 and moved on to another team, 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.

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.

The IT director told me that as long as  his IT Managers were happy with the infrastructure then all was good.  That was his main criteria for success, although he also wanted to save money and make sure nothing blew up.

There were also two vendors with managers who would be accountable for the ongoing delivery of infrastructure services. They saw themselves (validly) as the owners of the outcome too.

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

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.

To me, this made me the “project owner.”

I made the calls and managed things within the constraints we had agreed.

In addition, I facilitated the achievement of 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 scrum master?

There was no scrum master 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, some things were migrated to a happy new home and some new things were implemented.

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

I had a small core team, who were involved in every release.  But the core team was merged with specialists from the relevant application development teams and the relevant vendors who joined us for specific releases.

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 Scrum Masters 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 a basic plan 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 release also impacted support contracts and involved some payment or change in funding and cleaning these things up was part of our definition of success.  Most of the team were not involved in this, but it was important to all the stakeholders.

The team interaction drove the analysis and planning

We had constant interaction among 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 was completed and it was not there to validate that we had done the work properly.  If we failed to do the work properly then our angry stakeholders would have told us pretty quickly.

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.

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

Learning loops and feedback cycles mattered a lot

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 key 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 🙂

SoftEd training

I am also happy to help.

But the honest truth is that if you try reading those books and trusting your team to come up with a good approach you will probably 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.

Another example of a “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 the bad things our system did (compliance breaches, defects, work-arounds).  When we did this we repaired the system so it would keep working.

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

“But where is the project?” you ask

We had about 12 different internal stakeholder groups.  We also had 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 those 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 that were 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.  We didn’t leave them to do this on their own though. 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 the 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.

I also had the important role of acting as a figure-head.  This gave the team permission to manage themselves and seemed to matter to some of the stakeholders.

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 on 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 your 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” 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 🙂

SoftEd training

I am also happy to help.

Again though, to be honest, you could develop a complete set of agile practices that would work for releases that are really a bunch of related enhancements by working with your team to see what they think will work.

You can add Scrum or Kanban 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 both if this was a project and if it was agile.  I think it was both.

These days most “agile projects” are linked to a customer facing problem and they have product owners, self managing teams and things that make them recognizably agile.

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.