Project Management with DevOps

Sometimes in technical project management (TPM) we tend to focus on just a few of these roles:

• Devs
• IT Operations (DataOps, Data Management, CloudOps, MLops, SecOps, etc)
• Testing & QA

But we tend to forget to work with DevOps.

The DevOps culture changed the way IT works in any IT project, moving away from traditional initiatives in pursuit of greater speed, performance, and agility in the software development lifecycle (SDLC).

It is difficult nowadays for a TPM to have the possibility (or at least try) to take the time to plan everything from the start as the old books say.

Many times we have to enter a battlefield that has already started and with a pin to defend ourselves.

In IT there are many variables that conspire at the same time so that a DevOps-oriented project can fall under the typical stages of a project.

Tackling projects like these require a strong project management practice to keep projects moving on schedule in a very agile way with a clear focus on dependencies.

TPMs can't just focus on the Gantt chart and call meetings (I saw this in a real-world project and I clearly remember the DevOps team laughing when the PM said "what percentage of the day are you going to use for this task? very sad scene) is really more than that.

The typical bar charts are outdated in time (at least for DevOps) and many times nobody pays attention to them, which at least for other IT areas they tend to work.

That is why there is an urgent need to apply "agility" to the management of projects of this type.

Ok, I know "agile" is a very mainstream-fancy term nowadays, but there is no other to define the nature of what needs to be applied.

• *Agile is not just a software development methodology or concept; it is a way to manage today's needs for long-term projects aligned with the continuous integration/continuous delivery (CI/CD) approaches of the DevOps era too.

You have to see it that way, there isn't another way. I've seen it and traditional TPM schemes don't work in the DevOps niche.

Divide and Conquer: "Microservices"

Just as the microservices architecture breaks down the monolithic business application into more granular services, projects can also be broken down into much smaller, interdependent workpieces. I know this sounds familiar, the famous WBS.

This logically gives us more room for maneuver and greater control over the expected results.

Is not the same to do a BBQ for an entire cow than handle independently the cooking of the ribs, the sirloin, t-bone, picanha, and all the pieces you like for a BBQ with friends. The same approach here but without the smoke, good food, and friends.

The function of the TPM is to try to immerse in the DevOps culture and oriented towards a "microservices" approach in the best "features" style (characteristic of a product that we could achieve incrementally through a series of Sprints applying Scrum and blah blah blah) that allows handling a much higher speed due to the correct handling of smaller work-sets.

The last paragraph sounds nice, but some time is a nice-to-have feature that we don't have in our project. If we do things (or they let us do them as we know they'll work) we can achieve good results by working in an orderly manner with an agile approach.

Applying agile concepts we can correct the course with each release that we have on the horizon. It's fundamental been clear in this concept since the beginning and count on real support from the stakeholders, especially our own managers, the PMO, and the rest of the board.

The best practice is always to take the big release and automatically negotiate the "split" into "manageable" portions with the ultimate goal of being able to easily display results incrementally and thus get feedback on each iteration without overcomplicating our existence and thus learn something from the retrospectives in our journey.

This will always be a wild card up the sleeve for the TPM, if we would get off of the course and we could be behind the times, we can do damage containment (at the right time) and make everyone more or less happy at the end of the story by applying the right strategy. Not rocket science, just common most of the time.

Becoming an expert in "dependencies"

Knowing how to “do something and do it well” is essential for most things in life, not just projects. Understanding how all those pieces work together and make sense of a whole is even more important.

There is something that always raises the adrenaline in projects and it is the delivery date

When the speed of delivery increases (which is typical of the DevOps culture and is due to the demand for results), the importance of dependencies increases a lot. Downstream and Upstream dependencies are vital, we need to know how everything is interconnected and how anything can be a potential negative impact on our ecosystem during the release.

Why this?

Because when we are in a hurry we make mistakes, if there isn't a clear framework and if we touch X and it makes it stop working Y that's where knowing about dependencies makes you worth as TPM.

We live in a culture of immediacy and DevOps do not escape that (they living on the edge like Aerosmith's song) and this is how we expect them to always behave.

When they are slow to respond, something is happening and this may be because the pool of resources is low or they found a bottleneck not identified, guess when? during the dependencies check during the release planning.

There are many fires around the corner every day and if we don't pay attention to this dependencies identification process you can be sure that this will slow down the response speed of our teams and planned tasks could be neglected resulting in "Stranger Things" in our products and systems.

To avoid entropy within projects of this type, you have to be aware of these variables in terms of communications:

• The speed between integrations.
• The speed of communication between the project team and the stakeholders.
• The deadline > current date.

You must have to speak the same language as DevOps. You have to be a technical guy/girl and understand what they talk about in meetings, they can't explain what is Kubernetes in the middle of a meeting. That will prevent future issues or "broken phones situations".

Scrum, Kanban, what do we use?

There is no recipe here and despite the fact that there is much-written literature, the battlefield that occurs in organizations when implementing a project of this nature is far from what the manuals say.

Everyone knows that it is essential to use a framework like Scrum to divide the work into iterations where its dependencies can be well known and managed by the project team guided by a Scrum Master. With that we achieve that concept of "agility" so desired and that sounds so good when the project starts.

Using tools such as Kanban boards also helps us and allows us immediate views of dependencies between tasks, see the work blocked, issues, progress, bugs and the best of all for me is that it makes the work of the project team visible for the outside.

This is important because sometimes in the world of DevOps we are not clear about the resources that undertake X or Y tasks and when they will be done. The sense of progress sometimes is a dark zone that if you don't have the right communication and the tools to get it from them, let me tell you that you're going to suffer.

The last paragraph may sound illogical in an ideal world, but it happens more than usual. We have to have a framework that allows us to "manage" the project agilely and know "who" is with "what" and the "how" will achieve it by "when".

A Gantt chart that is quickly out of date often does not help us because, in the DevOps culture, resources and requirements change very quickly and it does not allow us to correctly follow up the activities (and thus avoid us going to a Slack channel and timidly asking who is in charge of X thing and when it's ready and hear the crickets sound)

That is why the project plans must evolve and adapt to this kind of automation typical of the DevOps culture.

It is a "must" to shorten the timeline of a delivery cycle for projects of this type. It is maybe obvious but it must be said and repeated because sometimes we are very ambitious and "we're in a hurry" and we forget.

This means that you can no longer afford to update a project plan once a week, this does not make sense since a continuous integration/distribution (CI/CD) environment such as the DevOps world is.

TPMs must be aware of everything at any moment, automation is not only for DevOps, it also impacts those who lead (or try to) it.

Be careful playing with time...

When making adjustments to projects almost by default we are going to attack time

It is perhaps the fundamental variable that governs our lives and therefore our projects and that inevitably conditions us to give it the greatest importance in many ways, whether we like it or not.

Something typical is to adjust only that dimension in our Sprints and we overlook how essential the same speed of response and quality of DevOps work can be, taking into consideration the velocity of the team completing stories.

Quality ensures better results in the future. Doing things "just to putting out fires" rarely brings "lessons learned" and is useful for us in the immediate future.

Some final tips

• Create integrated plans that take unplanned work into account. This sometimes "goes under the table" and is work that is not seen by the stakeholders, and less if there are no metrics to support it. When we're allocating resources, this time is not taken into account and the needle can move in situations where we are short of time
• Always look for feedback from unit tests and that production implementations/releases are being used to replan correctly for the next iterations. Something like the Sprint retrospective but more down to earth.
• Always look for the "incrementability" word that does not exist but if it existed it would be defined in doing what Scrum dictates through the Sprints and achieve a very good product/result at the end.
• In a DevOps environment we should always be able to answer the magical question (and one that annoys some so much): "Is it done yet?" - or your close relative, "When will it be done?" - with zero human interaction. If this is not the case, we must check and apply the right tools to get them.
• Our best friends: The sprint burn-down, sprint speed, and metrics. These as the simple reason to be able to see if individual tasks are progressing on time. Sometimes we don't have any of that, it's sad and it's happened. Don't be that person that invents metrics in the middle of a meeting.
• There are people who hate Jira, but if you use it right from the beginning it helps project management, no questions. The joke and the hard part is getting DevOps to provide up-to-date information on how the release is progressing and associated issues. Well-run Daily Standup (remote/in-site) style meetings are key to following the course of what we want to manage
• Good communication style is key, being humble and open to learning what those teams are doing is a good tactic to do your work better.
• Not being a fan of having a finished product at any cost based on a deadline, you have to seek and adopt the MVP approach (minimum viable product). In the DevOps world, the job is never really done with CI/CD running at full throttle.
• Continuous measurement (metrics of some kind - if we have them as I previously said) for the project are key, as is close collaboration between all members of the project (essential if there are no metrics, otherwise we are fried and good luck reporting to the stakeholders).
• The automation of the DevOps world sometimes overshadows the "good old practices" suggested by PMBOK and you have to be clear about that. Arriving with pretensions of "managing" in the best classic style to a project where the DevOps culture is rooted in the day-to-day can frustrate us if we do not know how to handle it.