Today, I’d like to talk about the concept of “manage or be managed”. On our day-to-day life we handle hundreds of daily tasks. For example in our life: taking our kids to school, pay bills & etc. In our work, we design feature, we coding & from time-to-time handling customer or QA bugs. As you can see, there’re some similar lines: tasks that are part of our fluent day-to-day work & tasks that “interfere” our fluent work, sometime comes out of the blue.
So, more or less we all juggle between all of those tasks or more accurate try to get balance between fluent to non-fluent tasks.
Why this juggling occurring? –Making long to short: in scrum, on the one hand, the fluent tasks are a must. Think of fluent tasks as sprint content & as such we are committed to deliver content by sprint ends. Otherwise, team members won’t deliver the committed feature/ product/version. On the other hand, “interfering” tasks are needed to be handled. In most common way those task come due to breakage/outage of something with severe impact –but not always. Think about a bug from a customer or some issue that occurs after electricity outage. This ritual is taking place every time, meaning every sprint & every version. Think of a small ship during winter. The ship is leaving the home port toward distant port on very bad whether & sees. The question would this small ship deliver its content safely on time or not?
So, how should we approach such “Juggling”? What is the best practice?
The key answer here is who is taken the control. If the answer is “we”, such as: project manager, scrum masters & etc. We’ll be able manage sprint or version with some deviation but with reasonable balance between delivering content to “interfering” tasks. If the answer is like “we are not controlling our tasks…” this means that “interfering” tasks will impact our ability to deliver content.
But, how we actually do it? –As start product owner & project manager need to agree upon ratio between new content developing to issue/bugs handling. Yes, we all familiar with “Buffer”, however, actually since buffer is not define this ratio it can be “eat” as content or “interfere” tasks. Second, as scrum master we need constant monitoring for any impediment on new content or other issues, making sure toward that all committed tasks will be actually delivered by sprint ends. Yes, this means to “push” team members to raise issue fast & occasionally to connect between members with another team leader. Another, aspect is raising issue & theirs impact during projects meeting so all stakeholders will be sync upon what will be delivered by sprint ends.
You may now say oh…oh, this approach consume to much efforts & resources. Well, managing is taken resources but the outcome is a successful delivery. Alternatively, you can be managed & this means, we can’t say what will be the actual delivery by sprint end. As we said manage your scrum or be managed by others.