Super Standup. Helping Knowledge-Work teams standardize their workflows.
Have you asked your team lately about the pain points they are experiencing with your work management process? A good leader should take ALL feedback seriously and do your best to address it.
The most common complaint I hear in work management processes is that employees feel overwhelmed by the amount of paperwork they are having to do in order to provide leadership with metrics.?This is usually things like commenting on tickets in specific manners, having to individually mark start and completion times, or populate other metadata fields such as labels, classifications or otherwise.
Bad data in, bad data out.
These are the complaints you should take most seriously, if the process is too burdensome on an individual you will not be able to guarantee that the process will be completed in the manner you expect, preventing reliable data for metrics, reporting, or dashboarding. Without the reliable data, leaders are not able to make reliable decisions. Bad data in, bad data out.
...menial tasks are a burden on everyone, ...
This is not a failure on the employee's part but a failure of the process.?Additionally, while menial tasks are a burden on everyone, many menial tasks such as the ones described above are particularly difficult for those with neurodivergence to be successful at executing.?
The technology field has a larger-than-average number of neurodivergent workers, especially in non-leadership positions. As such, you should handle the feedback from these diverse viewpoints with care.
Most neurodivergence is a protected class with coverage from the ADA, and listening to this type of feedback and adjusting process or creating automations to help relieve the employee of these menial tasks is similar to the goals that exist behind the reasonable accommodation process that is generally not available to neurodivergent individuals, nor is it easily able to be requested outside of providing direct feedback to their leadership.?
Imagine, being a grown adult, asking for a doctor to write you a note requesting a Project Manager to not make you type the same data into the same 4 fields in a ticket 10 times a day as a reasonable accommodation request. This sounds absurd in our current society, even to the individual with something such as an executive function disorder that is protected by the ADA. They’re more likely than the average individual to simply forget, but that simple act of forgetting could result in a reprimand, write-up, or eventually the loss of their job.
Super-Standup mixes concepts from Agile, DevOps and ITIL
I try not to speak too much on an issue without at least offering a solution, so here are some I’ve helped teams implement that allow for better metrics for our project management and a more enjoyable workflow for our engineers as they complete their work.
I recommend what I like to call Super-Standup.?
Super-Standup includes prescriptive elements based on concepts from Agile, DevOps and ITIL in an attempt to create a system of work that allows for a team to perform knowledge and engineering work while still maintaining a ServiceDesk-style outward-facing engagement style for the rest of the organization.
Here is how it works.
Super-Standup
Note: This process is geared towards teams that are comfortable with a 1 work-week or greater SLO/turnaround-time. However it can be adjusted to meet the requirements of other groups.
While your individual work process may have Stories, Tickets, Tasks, or any other name for a discrete work item that can be started and completed, we'll be using the term "ticket" in this article to avoid confusion.
Get rid of the daily standup... If you're going to have a meeting, have one where issues are discussed and problems are solved.
The first step, get rid of the daily standup. Daily stand-ups always felt more like micro-management to the team anyway. If you're going to have a meeting, have one where issues are discussed and problems are solved. Your meeting participants should walk away knowing what they accomplished and how it helped them. Instead of the daily standup we will start every week with a work planning meeting we will call "Super Standup". Many of the same concepts from a normal standup are applied including discussing blockers and work in progress, however what would normally be "parking-lot" items to be discussed later is instead prioritized to ensure the team can move forward as a single unit. Let your workers do the problem solving they love, but you will guide this problem solving to be more productive than the traditional back and forth. This is accomplished by guiding your team to discuss how to "complete the work" rather than "how to solve the problem".
I recommend at least 1 hour per person that attends the meeting. If you need to break up a large team into smaller groups with a lead for each group, this is acceptable. The goal is to ensure each team member has enough time to cover everything they need to cover, and any conversations that need to be had can be had. If a decision needs to be made as part of the process of defining a work item, that decision will be made during this call if possible.
Separate your work items into at least 3 buckets or queues. Non-triaged, ready-for-work, and work-in-progress.
All items in the Non-Triaged queue are usually similar to what you would consider as a “User Story”, or rather, a simple request asking for some type of goal to be accomplished. These should have no one assigned as the ticket owner.
All items in the Ready-For-Work queue are where tickets from the Non-Triaged bucket are placed after the steps for successful completion and a time box have been assigned to them. These should have no one assigned as a ticket owner.
All items in the Work-In-Progress queue are where tickets from the Ready-For-Work bucket are placed after a ticket owner has been assigned.
Set the expectation that each team member is capable of 4 days worth of work each week. This includes everything planned in this session, and any potential unplanned events that may happen throughout the week that require response.
Assign a scribe. This person will be “leading” the conversation and updating work-items in your work tracking system (usually a ticket). This person is also responsible for keeping the discussion focused on how to complete the work defined in a ticket.
Start the meeting by ensuring any work currently assigned to an individual in the work-in-progress queue has been completed and closed. If a ticket has not been completed, the scribe will make note in the ticket of all the items were completed then will make a new ticket with the remaining, uncompleted, items. They will then discuss with the team to request an estimate of how many days of working-time it will take to complete the remaining items and type that value into an “Expected Completion Time” field in the new ticket. Do not subtract any time from the original ticket's completion time; instead reflect with the team on how you might better break this ticket up into transactional parts next time. This ticket will then be assigned to the same resource as the original ticket that was closed. Last, tally up all items left in the work-in-progress queue, as you will need to know how many days of “Expected Completion Time” is currently assigned to each individual.
Next, address each item in the Ready-For-Work queue. This should be a fairly short and simple process. All items in the Ready-For-Work queue should already have completion criteria defined and an Expected Completion Time assigned. The scribe will ask the team lead which tickets should be assigned first based on their desired prioritization.
Next, address each item in the Needs-triaged queue in the order desired by the team lead.?
My recommendation is for the team lead and the scribe to set aside ~30 minutes before the super standup to rank the tickets in the Needs-Triaged queue. This helps the scribe as they can continue to steer the conversation of the standup without devolving into a discussion over which items should be prioritized. Additionally this is helpful as it may not always be possible to address every item in the queue every week, this gives the team lead a chance to escalate tickets or increase priority prior to assigning the work to an individual.?
For each item in the Needs-Triaged queue you will follow the Planning Process (defined below) and perform Time Estimation (defined below) to populate the Expected Completion Time field in the ticket. Do not forget during this process the Scribe will be solely responsible for typing and updating tickets while the rest of the team is discussing the work. When the completion criteria checklist is fully defined and an Expected Completion Time has been put into it’s associated field, the ticket can be moved from the Needs-Triage queue to the? Ready-For-Work queue. This will make it easy to assign work during next week’s meeting quickly.?
If all items in the needs-triage queue have been planned and you have time remaining in your meeting, ask the team if they have any specific tickets they would like to spend more time discussing.?
Note For Teams With an On-Call Schedule
For teams with an on-call schedule I recommend creating a ticket each week for the on-call employee with an “Expected Completion Time” calculated based on how much time the team agrees that an on-call resource normally has to spend on on-call work each week. The on-call individual will create tickets for tracking the emergent, unplanned work they had to complete. They will not be required to populate more than the summary and any notes they deem important during the process. Additionally, they will be specifically asked to not populate the expected completion time of the on-call tasks they create tickets for as this will skew our metrics.?
Planning Process
1. Define Steps required to complete this ticket as a list of “checklist-able” steps an individual can complete.
2. The Scribe asks the team how long the completion criteria items will take and will document the answer in the “Expected Completion Time” filed in the ticket.
3. Break ticket into multiple parts if needed
Time Estimating on a ticket
The minimum amount of time to assign to any ticket is 0.25 (or ~2 hours)
Quarter or Half Days should be put into the expected days field in decimal format (i.e. 0.25 0.5) example: 1.5 = 1 and a half days
This should be based on number of working-days defined as 8 hours of work time.?
Estimates should be based on the longest it may take to complete this ticket if you were to assign it to the person on the team that would be the slowest to complete it (i.e. someone who hasn’t been trained on said process)?
Example: If it takes Jane 2 days to complete because they’ve done it 1000 times, but it takes Joe 3 days to complete because its their first time, you would estimate this work item as 3 days.?
Don’t punish your over-achievers for over-achieving by over-assigning them work. This encourages the over-achievers to spend more time carefully completing their work and tying up loose ends.
If a ticket may result in extra work and we know this, its usually best to split the difference between minimum time to complete and worst case scenario. Example: A ticket to “Perform Recurring Task A” may normally take 0.5 expected days, however we know depending on what is seen during that task completion, it may take as long as 1.5 expected days to fully complete the task and its follow up items. In this case you should usually estimate this to be 1 expected days.
Always estimate on the side of caution. The goal is to be delivering “A little early” or “On Time”. Do not shoot for delivering sooner than promised as this can lead to leadership scrutiny from having “too loose” of time tracking.
Metrics
The following metrics can quickly be calculated weekly as a simple integer. Further abstractions can be made by comparing and contrasting these metrics allowing for a team manager to identify resourcing requirements and opportunities for improvement. Additional enhanced metrics can be defined for this process by following some of the suggestions in the Continuous Improvement section.
领英推荐
1. Weekly completed work effort
Method of Calculation: Sum of Expected Completion Time for all completed tickets
2. Number of tickets completed
Method of Calculation: Count of tickets that transitioned from Work-In-Progress to done
3. Number of tickets assigned
Method of Calculation: Count of tickets that transitioned from Ready-For-Work to Work-In-Progress
4. Number of tickets planned and time boxed
Method of Calculation: Count of tickets that transitioned from Needs-Triage to Ready-For-Work
5. Known Outstanding Work Effort
Method of Calculation: Sum of Expected Completion Time for all tickets in Ready-For-Work queue
6. Number of Unplanned Tickets?
Method of Calculation: Count of tickets in Needs-Triage queue
7. Number of Emergent (unplanned) Work Items
Method of Calculation: Count of tickets that transitioned to “Done” that have no Expected Completion Time defined.
8. Known Assigned Work Effort
Method of Calculation: Sum of Expected Completion Time for all tickets in Work-In-Progress queue
9. Average Assigned Work Effort per resource
Method of Calculation: Sum of Expected Completion Time for all tickets in Work-In-Progress queue divided by count of employees working the queue
10. Average Completed Work Effort per resource
Method of Calculation: Sum of Expected Completion Time for all tickets marked as “done” divided by count of employees working the queue
Continuous Improvement
The best method I can recommend for this continuous improvement is to identify the following scenarios while performing the planning process and create tickets to address these items.
1. Recurring work
Any work item you see as coming up in multiple planning meetings should have a ticket created for the team asking them to define the following:
You’ll then assign this ticket an expected completion time of 4 days, ensuring that an assigned resource has time to fully think through the process, consulting any external teams (Security, Engineering, IT, Legal, HR, or whomever may have stake in the process)
This ticket to document the work should be moved to the ready-for-work?queue and assigned to a resource within 1-2 weeks following the last time they performed the task. The fresher it is in their mind, the better documentation you will get.
Some benefits you will see from this is the ability for less experienced resources to be able to take on this task as it is fully documented.
A collection of details acting as metadata around this process can be defined allowing for tickets of this type to be easily labeled and tracked in future tickets. These metadata details are something i normally recommend be populated as "Tags" if possible, but can be established in a work management system as true/false applicability fields as well.
2. Creation of Templates
After documentation of a process, its drivers, stakeholders, and average completion time has been created due to the continuous improvement step 1, you can pre-build this type of ticket into your work management software ensuring all the extra metadata and tags are populated for enhanced metrics. This will also speed up the planning process in the future. If the recurring work item occurs on a schedule rather than by request, it is recommended to have your work management system automatically create the ticket in the morning of work planning day, populate all fields and info, then place into the “Ready-for-work” queue. This further reduces the burden on the team or the scribe and allows for the work to be quickly delegated. This template creation should also be created as a ticket, assigned an expected completion time, and a completion criteria checklist.
3. Practice self-discipline and coaching within the team
The scribe and team lead role are separated to allow for an authoritative balance to the team lead. The scribe pushes back and ensures those within the team follow the process, usually by telling their eager workforce that they are not allowed to have more than 4 days of work assigned to them per week. If this means that someone has to be settled with 3 or 3.5 days of work in a single week because no other ticket could be broken into smaller chunks to fill up their schedule, so be it. This is especially true for the Team Lead, who in my experience will try multiple excuses for why they should be over-provisioned.
We as a team are not in full control of all that is asked of us, however we are in control of what we commit to the organization will be completed. The best thing we can provide the organization is not a couple weeks a year where we over perform, but instead a full year where everything we said we would complete was completed, on time. If the organization requests more work to be completed than our team is able to complete, the metrics produced by this process will prove that reality. This gives our leadership chains a chance to remediate the issue early, before it becomes worse.
The best thing we can provide the organization is not a couple weeks a year where we exceeded expectations, but instead a full year where everything we said we would complete was completed, on time.
Pro-Tips
1. On-Call and Pseudo-On-Call
If you don’t have an on-call today, that’s okay. However If you receive any type of emergent(unplanned) work that must be completed on a weekly basis, I recommend you have a rotating member of team that is responsible for completing unplanned work each week. They will receive a ticket at the beginning of the week to track that they are on the “pseudo-on-call” with the estimated time they will spend on emergent requests. They will still work their normal schedule, they will just need to check the queue each morning for emergent work.
2. Emergent Work
Separate emergent/unplanned work into its own bucket in your work management system. I.e. if this is a service desk, you may have a normal “make a request” option that goes through the normal process and a separate “create an incident” or “ask a question” option that goes to a separate queue for the “pseudo-on-call” to review as emergent work.
3. How to respond to "Some work can’t be broken down"
I hear pretty often that “Some work just can’t be broken down into parts.” This can be translated to “Some work just hasn’t had a process created yet.” I recommend the teams that think something is not able to be broken down to create a ticket to define a process for completing this type of work. During the planning process discussions can be had to determine what completion criteria looks like. This usually ends up in a discussion such as:
“Well in order to complete this step we would need to email Jane in accounting. How do we account the time to wait for a reply into the our expected completion time?” Says Team Member A.
“What if we create a shared mailbox for the team, send the email to accounting from that mailbox and close the ticket? We can then use the response to that email as our queue to create a new ticket to continue with the next step of the process allowing us to break it into chunks.” Responds the Scribe.
Team Member B then chimes in. “How about we add the accounting team member to our Work Management software so we can create a subtask for them”
“That might be more than the Accounting team member is comfortable accepting. They have their own processes after all” says the Scribe.
“How about we schedule a call with accounting to identify all the required information they might need, so that when we get to the step of sending the email to accounting it will be a send-and-forget task; rather than something where we are stuck waiting on a reply?” Suggests the team lead.
No matter how your discussion may go, you have a team of competent professionals ready to problem solve. It may take a couple of suggestions and some trial and error to find a comfortable flow but all work can eventually be broken down. The process this article outlines is one that celebrates and rewards the effort put forth by a team into standardization, and who doesn’t love a good puzzle?