I stood to face them, a circle of busy looking people in tailored suits and designer dresses. I could feel their PMI certified eyes monitoring my every move: searching for signs of underutilisation; searching for weaknesses that they could exploit to improve my productivity; searching for certainty in a complex, unpredictable world. Mustering up all of my courage, I finally addressed the group in a wavering tone:
“My name is Marcio Sete, and I am not a Project Manager.” I recently emigrated to Australia from Brazil to join Elabor8, a company that for all intents and purposes seemed to be really well aligned with my skill set and career direction. In the interviews, we talked about agile, lean and DevOps (my speciality), intent based leadership and coaching for change. You can therefore imagine my face on the day that I was assigned to my first engagement. Our Client Services Manager said: “We have a client that wants someone to manage a Data Centre migration project and we think you’d be a great fit”.
A Project Management role. On a Data Centre Migration project. Working with an Operations Team. I looked up the conditions of my visa and the local laws on euthanasia, and realised that I would have to make the most of it.
This series of articles describes my journey: From agile coach, to project manager, and back to agile coach. Over the last few months, I’ve had the pleasure of working with a group of motivated individuals, helping to build a high performing technology operations team that provides a higher fidelity of management information than traditional project management methods ever could.
In these articles, you’ll also find the eight-step program that I’ve created to cure organisations of their addiction to traditional project management and build high performing agile IT operations teams. Actually, it’s an nine-step program. The first step for me was acceptance. And so we begin.
On the first day of the new role, I found myself immersed (for the first time in my career) in an IT Operations Team. For over a decade operations represented to me the dark side of technology, teams whose sole purpose was to drive security and stability to the company rather than support an organisation’s ability to adapt and grow.
It took me a couple of weeks to really understand how that strange looking group of people wearing shorts and shirts with quirky slogans worked (the company is a tech start-up with a delightful work environment). About 65% of their effort is spent on emergent work and small initiatives. Five percent is spent with incidents and firefighting and about 30% in a major IT Project that will boost productivity and improve the company’s competitiveness.
Beyond all the typical challenges of any team of knowledge workers, I could observe that IT Ops Teams have some particular ones due their nature of work:
- They tend to work with individual queues due their high level of specialisation. For instance, a DBA specialised in Cassandra – a Database designed to handle large amounts of data with high availability and no single point of failure – probably won’t be interested in getting specialised in security in a level of striking online fraud and vice versa.
- Increasing the multidisciplinary nature of the team (the ability to have different people working on different types of demand) can be quite challenging and sometimes even not possible, again because their level of specialisation.
- Context switching is extremely high due the emergent nature of work, which increases the volume of work in progress (WIP). Other characteristics that lead them to work in a high WIP mode are long execution tasks (installations, backups, migrations, scanning) and BAU (business as usual) work (quoting and buying stuff and services, creating guides, approving new policies across the organisation).
- It is difficult to share a team goal to hold everybody together in environments with such a large amount of emergent work and specialisation. The path of least resistance is to have just a bunch of people working on a different bunch of tasks rather than have a concise, creative and resilient Team.
It is important to have clarity on the problem you are trying to solve. In the beginning, I was looking for the Ops area as a whole, trying new things in the context of the Team. However, after a while, I realised that the team has completely different behaviour depending on the type of work they are performing. Over time I sorted these into three distinct “behaviour/kind of work” categories: Emergent Work, IT Project, Incidents and we ended up applying different strategies for each of them.
Before exploring how those three different types of work can be approached in an agile manner, let’s examine some fundamental things, which are common to all of them and valuable for most agile initiatives. I have structured it in what we are calling inside the team as “The 8 steps strategy”. It looks like this:
#1 – Visualise everything
#2 – Collaborate to win
#3 – Reduce WIP & batch sizes to improve predictability and flow
#4 – Make sure we are doing the right thing and just the right thing
#5 – Collect tangible results and celebrate quick wins
#6 – Have in place different feedback loops to improve continuously
#7 – Grow a great Team
#8 – Share experiences, successful or not, to enable others to learn
Rather than implementing any existing framework, the above steps are guiding our agile journey. Do you want to look inside?My number one challenge was to eradicate invisible work. Depending on the environment you are in, this can be a tough thing to do. Fortunately, my team is awesome, and it took us about one week to start visualising everything.
We began with a physical board. As this was the team’s first agile initiative, I felt that it was important to them to know what a piece of work looks like; to be able to touch it, to move it and to respect it. I’ve found in the past that this helps them to understand that depending on how they behave, the system dynamic would change completely in one way or another.
Visualising everything meant visualising everything. Therefore, beyond all planned work we also started to visualise unplanned work, blocked work, impediments, risks, due date work and periodic work. Here is what our board looked like at the beginning of the journey in case it may inspire you.
A guide to agile ‘project management’
Backlog
The backlog should contain all known work the Team expects to do soon.
Pull System
The relative merits of Pull Systems vs. Push Systems is a long discussion, but basically, in a Pull system, work can only go further on the board just when there is a slot available in the next phase (according to the Work in Process (WIP) Limit policy established by the Team). The main benefits of Pull Systems are reduced WIP and active queue management – the system works at the speed of the slowest component in the value stream.
So for instance, imagine that a piece of planned work was completed. This would mean that a new position would open in the “Planned” queue, allowing the team to take the piece of work that makes more sense to start next from the “Next 4” and promote it. The same way, a position will open in the “Next 4” so the team could take one from the “Next 8” to promote, and then the “Next 12”, etc.
The Pull System brings a just in time prioritisation approach. So based on the current scenario and the information available at that moment, the Team chooses the next work that makes the most sense given the context.
Planned
On this stage, we expect the work to be broken down into smaller chunks that can be delivered by the team. We aim to decompose the work into chunks that are roughly at the same size because it increases our stability and predictability as well as our capacity to learn from the work done.
No matter how many levels of categories you have, my advice is to measure just one level of work. Even if you have Epics, Features, Stories and Tasks, you should track just one level, where smaller is better. In our case, looking from bottom up, Stories are an aggregation of a set of tasks which deliver meaningful value. Features are an aggregation of Stories, which together provide meaningful Business Value, and Epics are a grouping of contextually similar Features.
In our Team, we were tracking at the task level and targeting every piece of work to be between one to three days. You could alternatively track at Story level and target it to be between three to five days or even at feature level, but the larger the measure, the lower the fidelity, and the slower the learning.
In Progress
Part of visualising everything includes visualising who is working on each work-in-progress. Some teams print avatars and team members attach it to the cards respecting the WIP Limit policy. In this case, instead of having people moving around the cards, we preferred to have the team fixed and the work moving across the team. This worked really well in an Operations context. Each member had their own area on the board for the work in progress and any eventually interrupted work, always respecting the WIP Limit policy.
Done
Here is where all completed work goes. I personally like to organise them in week columns, so it is easier to find a particular card you need among other 500 completed cards.
Unplanned Work
What is considered unplanned work can vary from different agile flavours. If you are running iterations, that could be any work which has emerged after the planning meeting. If you are working in a flow mode, unplanned work could be any piece of work that has emerged with the necessity to be done as soon as anyone in the team finishes the previous work (e.g. work classified with a different Class of Service and hence priority).
Some teams could represent it with different lanes on the board. We decided to express it with a different colour, purple to be precise.
Unplanned work is a productivity killer and you must keep watch on it. When teams are working on unplanned work, they are necessarily not working on planned work. Unplanned work can also be symptomatic, and root cause analysis can lead to the detection of systemic problems which can improve team velocity.
Due Date Work
Some works have a particular due date, especially in Ops Teams, where they are dealing with several contracts with different vendors and suppliers, licensing and buying things. For example, if you do not cancel a specific service on a specific date, it may go for another monthly charge. Alternatively, you may do a quotation for acquiring new servers and need to follow it up in three business days.
We represent this type of work with a beige card, and we check the due date work every day in the daily meeting.
Periodic
Some work recurs on a periodic basis and it is useful to visualise it as it impacts the team’s capacity. Examples include a daily check to verify that system backups were successfully completed, a weekly scan for vulnerabilities, or a monthly financial report that must be completed.
We represent periodic work with dark blue cards, and it works well as a checkpoint, where the Team can remember and check if those things have been done as expected. They check it in the daily meeting. Periodic work is also a great source of opportunities to automate and improve team velocity.
Blocked / Awaiting
If work is blocked for any reason or waiting for third parties, we need to make it clearly visual. When work is blocked, it affects the flow of the team and increases WIP and queue length. We need to actively manage it, following up the dependency at the minimum viable interval.
To visualise we move the card (regardless of type/colour) into the blocked / awaiting area and discuss it at the daily meeting.
Impediments
Impediments are quite similar to blocked work. The key difference is that the problem cannot be resolved at the team level and needs the intervention of someone outside the Team.
We represent impediments with red cards, and whenever it appears, there is an enormous effort applied to solve it ASAP as it may affect an entire day of a Team member or even the whole Team.
Risks
I personally don’t like surprises, and we do not want our Team to be surprised by any emerging work that will take a considerable amount of time to be done.
We represent the risks with pink cards, and we expect that all known unknowns and uncertainties to be visualised and followed closely by the entire team.
Team Identity
For me, in order for a group of people to be considered a Team, they need to have an identity, something that represents their culture and values. Our Team has a name, flag and a set of core values, which guide us day by day, and help to inform us when we are making decisions. The core values of our team are commitment, trust, simplicity, competence, teamwork, creativity and fun. Lots of fun, to be honest.
The organisation is no longer surprised to see Nerf wars break out in the middle of the day without warning, accompanied by an appropriate soundtrack. If civil war ever breaks out in Australia, I know that my team will have my back.
Team Strategy
It is always good to have the team reflecting on their strategy, be it when they are in the daily meeting or when crossing the aisle. It is also good to generate awareness across the organisation and communicate how we are working.
Ceremonies
Even though we have calendar meetings for every ceremony, we want to make it visible to the Team and the organisation. Therefore, we visualise them on the wall with the right days and time.
Legend
With all those different types of work, card format, and colours, we also needed a legend to support new members, and also to help the rest of the organisation to be able to read it. One of the key principles of Visual Management is to ensure that anyone who looks at your board can work out what is going on.You could opt to use a virtual board, but I would suggest starting with the physical board and then, only if you feel it is necessary, you move on. The level of engagement and awareness promoted by a physical wall is tremendous.
You may also want to visualise the risks of your project in a way where it is easy to identify their relative priority and importance. You can then introduce mitigating actions into the backlog to reduce the consequence of the risk (I prefer measuring the impact in “size of loss” in workdays) or to reduce the likelihood for it to happen. You can track different risks with different colours, e.g. business risks, engineering risks, people risks.
If your risks remain in a spreadsheet somewhere in the network, it may not trigger your team to think about it every day. A happy team is a motivated and productive team, so why not also visualise the Team Happiness? We tracked happiness over time and made it a key retrospective item.There are many invisible things you may make visible or things you may help become more evident. The more that we visualise, the more actively we can manage. Now that you know how to create a great visual management environment, you can start with Step #2: Collaborate to Win!
This is Step One of my Eight Step Program to Agile Operations for Project Management Anonymous. I’ll be publishing a new article regularly, so please register for updates!