Don't waste people's time
Everyone should know and follow the three most important “don'ts”: Don't lie, Don't steal, Don't shoot vertical videos. My intent here is to argue to add one, with equal importance, to the list: Don't waste people's time.
The ultimate management sin. It sounds like this should be an easy sin to avoid, but it isn’t. You have some needs of your own as a manager, and these needs may run squarely against your intention to preserve and use wisely the time of the people working under you.
Types of wasted time
For instance, you call a meeting with your staff but arrive late yourself (you had to take an urgent call from your own boss), leaving the others to cool their heels. Or, you let yourself be called out of the meeting for a quick but important chat with the client, and the meeting loses focus without you. Or, you call a meeting and it becomes evident that the meeting itself is a waste of everyone’s time (except possibly your own, the characteristic of many ceremonial meetings).
When you convene a meeting with people present, the normal presumption is that all those in the room are there because they need to interact with each other in order to come to certain conclusions. When, instead, the participants take turns interacting with one key figure, the expected rationale for assembling the whole group is missing; the “boss” might just as well have interacted separately with each of the subordinates without obliging the others to listen in.
When people’s time is wasted in unnecessary meetings or as a “time fragmentation” (doing stuff here and there just to fill out the required 8 hours per day), they’ll know it. They’ll be frustrated and they’ll know why. If there is enough of such waste, they’ll probably let you know about it, too. So these problems, though serious, are at least not invisible.
How one can react and respond to someone trying to waste their time can take different forms, but nonetheless, they should be clear and transparent to the person trying to micromanage them that it is not healthy. Let’s see a couple of examples.
The email
I’ve seen emails with 2000+ words that span to a thread of sequential follow ups before even having a chance to respond to the initial one. Sometimes these emails contain irrelevant information, bloated in a foreword that yields no value before reaching to the essence of the topic, that even then might not give much information. Such emails are a pure waste of time, and if coming from “higher up” they are immediately tagged in a person’s mind as TOP PRIORITY, VERY URGENT, MUST DROP EVERYTHING AND READ IT, that quickly switches the reader's attention, focus, and flow and creates an interruption that will take thrice the time to attain again. Completely different in one’s mind, but still the same principles apply, is the communication upwards, which in less experienced cases can bring a lot of pain and stress.
The pattern that quickly eradicates this problem from the root and makes a lot less noise to busy schedules is: “When communicating with stakeholders, keep your written communication down to a 100 words.” Now let’s undermine that advice and write an article of 2000+ words to explain why!
Stakeholders can be a lot of different people, in many cases, you are communicating to people of various disciplines. Especially if the stakeholders are managers, business owners, CEOs (and other O’s), they receive a lot of emails daily, and they can spare <1 minute to each “IMPORTANT” email. So for them to categorize the email as important, they need to understand it in the first 100 minutes, so that they can spend the rest 59.9 seconds reading it, digesting it AND hopefully answering it.
As a war general from WW2 once said, “I have two types of problems, IMPORTANT and URGENT. The important ones are never urgent, and the urgent ones are never important.” The idea is for you to be important. As it is the case with writing code, you write it as a “well-written prose” to quote Robert C. Martin. First you name your method so that it explains the purpose. If the reader needs more information it goes deeper and reads wordings inside the method but as an overview to form a sentence, and only then, if more information is needed, the reader dives deeper into a greater cognitive load and reads the loops, conditionals, etc., to understand its deeper purpose.
Following that example, we can now use that pattern to write documentation (in this category, an email can also be considered a documentation, a conceptual documentation or eliciting requirements phase of a PRD).
How the process goes:
- Given that you have written the full intent of your message first
- When you proofread it
- Then you write your ‘unit tests’ (ask questions that clarify ambiguous areas)
- And you refactor the original message
- then you refactor some more
- After that you write a summary and put it at the beginning as an abstract
- And lastly, you name your method/document to show its purpose
So let’s break down how one reads the message:
- I start by reading the name of the email and I need to understand what is the content of the email, what is the problem and what is required of me (PRD Phase 1: Eliciting requirements, [Project Name] required feedback from initial design proposal).
- I get inside the message, glance through the formalities (hopefully the first 2 sentences) and get to the first paragraph. If I can understand the purpose of the message from this paragraph, and it is relevant to me, I get into the core (open the design and start providing feedback)
- If I need more details, (e.g., I don’t quite understand the design flow in some places), I get back to the message and read again and with a bit more attention to see if I’ve missed something, and so on. Only then, If the information is not provided, I ask for it, trying to keep it short
One anti-pattern that can sneak in here is: If you put a lot of questions that people need to go through, analyze, distill, understand and respond, this is a lot of load for a feedback, and it gets pushed back for future consideration and when “there is enough time” which is never. Instead, distill the information, give as little as is necessary, so if you get an answer from some stakeholder, and they like your idea,then you push (maybe some) of your questions. It should never be as a “questionnaire” but a discussion, trying to engage the stakeholder more into your project, maybe to invest (time, effort, money) by raising their curiosity.
The report
Recently, I have had an experience which has led me to believe that busy people rarely read reports, even if they are short and to the point. This is a common problem nowadays, especially among millennials, to whom the attention span is short and in bursts. There are several techniques on how to peak their interest: “MINI - Make it New and Intriguing” (don’t look it up, you won’t find it)
So let us break down one report and what patterns we can use to provide enough information and follow the example explained up until now in this article.
Report Initiation
Start with the project name, sprint number and the period of execution. Clean and easy way to enumerate the document and inform the reader if it is the most current one. Optionally provide a Table of Contents to digest the document.
The roadmap
The first and most important topic should be a general overview of the current status of the project. We usually call this “The roadmap”. We can use a screenshot of the roadmap set in “Quarterly” view, displaying a couple of previous sprints, the current one and one or two subsequent ones. Display the epics, ordered by priority and by engagement (the finished are first, the ongoing are following, the new ones are at the end).
You can also write below the roadmap the “affected epics” by the current sprint to reduce ambiguities to the reader. For some of the stakeholders this is enough and here is where they stop. They need to know that we are working on what was agreed, where we are at the moment, and if we are keeping the estimated delivery plan. This can remove many following engagements in communication between the delivery team and stakeholders, and it is using the CFD pattern (Colors for Directors) that I have talked about in the Scrumfall: The fall of Scrum article.
Following the affected epics are the “major milestones” accomplished by the sprint. A milestone is different from an epic in a way that it can be a part of an epic or can span several epics (tracked as phases). It is an agreed-upon achievement that brings value to the client. If it is healthy, it represents a step in the desired direction, or it can be an end of the road signpost. But sometimes, it can show the complete opposite, that we are heading where we do not want to go and can stop us before we spend more resources and do more damage - agile at its finest.
Lastly is the “sprint goal”, a short-term mission statement that can declare the sprint a success or a failure. It is a mutually-agreed statement by the team that we need to accomplish at the end of the sprint, so it is important to add it here. It shows the stakeholders that we understood what is most important during this iteration and that we have all worked towards completing it. If there are multiple sprint goals set for the ongoing sprint, add them separately and tag their state (completed, partially completed or not completed) or mark them with colors accordingly.
The status
Next we have “the status” topic. This is a short descriptive summary of the overall status of the project or product. How is this different from the milestones then? Well, the status can give updates of certain aspects that may not be considered milestones, or it may give a reason why certain milestones have not been achieved, where we are with our development effort and if we have certain blockers or impediments. The status bar can also have different accent colors depending on our understanding of the health of the project.
The status can have multiple bullet points that are written in third person and are generalized descriptions written on a high level of abstraction for specific change efforts, i.e., they are accomplishments by the team or certain individuals and can be used as a type of praise for exceptional efforts and investments.
It can also include information for the environment of a certain epic or a feature that has not completed its expected lifecycle (e.g., It is waiting for feedback on UAT instead of moving to production as planned), why it is found there, and what needs to be done for it to move forward. This is considered waste in the lean philosophy, and reduces the overall development throughput, so it is paramount to be communicated with the stakeholders and is of highest importance, so that we can quickly remove it as a constraint or bottleneck to the delivery process.
The delivery
What follows is the “delivery” report. It is a simple table displaying the team velocity for the past 3 sprints, averaged on the last 5. It also displays the period that these sprints were completed in.
The averaging on five sprints is a bit confusing here because we are displaying only the last three, but experienced Scrum Masters will immediately note that averaging on the last three might not give correct approximations (Cone of Uncertainty), and displaying all five only makes more noise. That noise comes a bit later if the reader is interested to dive deeper into the report.
Risk Management
So we come to every manager’s nightmare: “risks”. This is where the most energy is invested by each manager, tracking and following the effort as the sprint progresses, creating a holistic view and presenting it in a risk matrix. It basically is really simple because there is no standard approach and it is just individual assessment of risks (and opportunities) that have been noticed during the sprint period and might affect the upcoming one or few iterations.
- We start with a simple risk description, or a summary of the reasoning why we consider a certain point as a risk
- Next, we have the probability of it happening in the expected period (low to high)
- We then note the severity of the damage it might cause if it happens (low to high)
- And we consider the status of what we intend or try to do next (avoid, mitigate, transfer or accept)
- Lastly, we have a short description of an action plan regarding the status, explaining how we are to follow through with it
The Scope
This phase means we reached the core of the report and started a new phase, a more in-depth analysis of the team progress spanning multiple past sprints (up to 10) and displaying their KPIs. Simply, we note the sprint name/number (duration), total story points committed, story points completed, story points not completed, the calculated completion rate (completed, divided, committed), story points added during the sprints (indicating scope creep - or we failed in our risk management), and lastly, our bug bash progress (or how much effort was invested in bug management, either committed at the beginning of the sprint or found in our regression testing phase).
A good practice is to revisit our initial estimations at the end of each sprint, update them in a separate field after the fact, double check if we have a correct estimation feeling of our story points scale as a team and if we can improve upon it. Comparing the initial value with the new value can give us a discrepancy percentage that we can follow in subsequent sprints to see if we reduce it, therefore increasing the completion rate. If the discrepancy widens, it is an indication of “pumping up” effort points so it seems like we are delivering much more value than we actually are.
An anti pattern can occur at this point. The manager is tempted to track the logged times for each item and try to correct the estimations using man-days. These two values should never be put in the same basket and be interchangeable. Tracking time for each item is an engineer’s complete waste of time and it does not improve the team’s estimation precision, since it is not something they have concluded as a team effort, rather it was imposed by the manager.
Providing a detailed table, showing each story, task and bug that was committed at the beginning of the sprint, and ones added during its duration marked as red, can give the interested reader a chance to follow the status of an epic broken down to its subcomponents. A table of items that have not been completed or have been removed from the sprint can follow next.
Lastly, we have the analysis of the discrepancy (if any), or a description of the reasons for changing the sprint plan. This is in a way a more detailed dive-in for the status of the sprint, that can connect several points, risks, milestones, and goals into a whole, giving a clearer picture of why something has happened that it was not supposed to occur - a failed delivery plan, affecting the overall release plan.
The Next Sprint
And lastly, we give a slight glimpse into the “Plan for our next sprint”, writing down the delivery plan into a neat table of a task breakdown structure, our stories, tasks, and bugs with our initial estimations.
The structure of the table can follow the previous table of completed items, so for the next report, one can simply copy the planned items into the completed (and hopefully not) incomplete items.
Conclusion
There are many more examples and best practices we can research in order to reduce ours and more importantly, others’ wasted time. However, until next time, I’d like to try to KISS (keep it simple, stupid), as indicated by the length of this article of course.
About the author
Borjan Petreski is a Service Delivery Manager working in the engineering hub in Skopje.
Borjan is a versatile Service Delivery Manager and Scrum Master who has experience working within different agile frameworks, such as Scrum, Kanban, or "Scrumfall." Borjan managed multiple projects and products simultaneously with varying stakeholders and SMEs from various fields.
