Here's the thing: None of us work in an isolated vacuum, and we have customers who rely on us to deliver when we say we will. In large organizations that means that we often end up at the "beck and call" of a project manager.
Most of the time when we talk about project management, the "higher ups" see this as a way to get visibility into the working of the organization. It's a very clear and simple goal. Project Management is all about planning, executing, controlling and closing a team's work (and here's the important bit) to achieve specific goals and meet specific success criteria. The Project Management Institute makes this even clearer by defining a project more clearly - it is time-boxed and is "unique in that it is a specific set of operations designed to accomplish a singular goal".
How this impacts us in the day-to-day use of DevOps methodologies is clear - we are going to build out some tools or automate some task. That specific goal is our project. What Project Management does not handle well in this case is the interrupt driven nature of what the core "DevOps Team" (see "A DevOps Team is a daft idea and you should feel bad") actually does.
Note that I don't say "does not handle", I say "does not handle well". There are some clear methods that we can use to help here, but the typical organization has problems implementing them.
The crux of the problem is that much of the work that Internal Engineering (Tools Eng, Infrastructure, etc.) handles is not covered by the term "project". Even if you create a "project" for maintenance items, that is not a true project - it is not time-boxed, and doesn't meet specific goals, rather, general concepts. So how can we handle that?
Well, the first thing to do is figure out what your workflow is and what the balance is between true projects and interrupt driven tasks. Next is to put in place some method of tracking these 2 fundamentally different work approaches. Why, I hear you ask, should we track this work? Well, the normal response put together by Project Managers and "Agile Coaches" (see Dave Thomas' excellent "Agile is Dead (Long Live Agility)") is that we can get better and better at estimating.
Frankly that is a load of old hogwash, as my father would say. It is not about getting better at estimating, it's about managing expectations, and mitigating risk. Think about who the audience is for these tracking tools. It's the customer, not the developer. The developer needs a todo list. "What did I do yesterday, what am I doing today and what's in my way" - That's the standard set of standup questions. This keeps the team abreast of what work has been done and what remains. It is a commitment to each other. And that can be easily written in a chat message, email or face to face meeting.
What can't be answered in that meeting (and shouldn't be) is "why was x delayed". That is a qualitative judgment. The 5-whys (another Toyota invention btw) will often pare down to "another requirement/task came in that meant we needed to adjust". What the tracking tools do do well, is expose what came in and when, and therefore we can pick up some trends as to how to plan the actual project work.
Unfortunately there's not a really good way of doing this. Analysing the cycle times of a group according to project work and interrupt work would be a reasonable approach. There's no single tool that I know of at the time of writing that will handle both, but we could have 2 different tracking methods which would address cycle metrics (cycle time and lead time). While these metrics are usually tied to Kanban methods, they can be taken out of this context and used independently.
Thinking about these stats is really important to us as practitioners of devops. They promote collaboration in a very specific way, if used transparently. Not only do our customers start to see the actual work that needs to be done, but they start to see how to help reduce cycle times to make things better. There is a fairly large added benefit (and this should have a post all its own in the future): estimating "this will take 2 weeks" and being held to the task being complete 2 weeks later goes away. Now the process is "this should take about 2 weeks when we get to it - our lead time is roughly x days".
There are only three ways for a team to reduce their cycle time -
Get better and faster at working Reduce Work In Process Make the batch size smaller
So - how can we measure these easily? Well, find a nice friendly project manager... your local neighborhood tracking tool probably has this for free. And added extra benefit? - if you make your Batch size smaller, then you have a nice todo list. (even the wonderful Trello has plugins that do this!)
Project management isn't about estimating and accountability - it's about expectation management and risk mitigation. Even the most interrupt driven teams should track their cycle and lead times to better handle those 2 concerns.