This Dilbert comic strip provides us with a good reminder of the fine line which exists between reasonable oversight of activities and micromanagement. Dilbert has allowed sufficient time to pass before seeking an update on a colleague’s assigned task only to find that it has been neglected due to a lack of following up. When Dilbert attempts to get commitment on a revised completion date, he’s accused of micromanaging the activity.
What is deemed a reasonable amount of oversight by a manager may be perceived as micromanagement by team members.
While some teams might possess sufficient psychological safety to embolden team members to voice their concerns, the culture within other organizations or teams might actively discourage this sort of straight talk. In such environments, the frustration felt by the team members festers resulting in impacts to their productivity and slowly poisoning team morale.
And this can become a vicious cycle as team members become progressively more disinclined to share updates with their leaders which results in even greater degrees of oversight.
So how can we avoid this?
It has to start with the leaders and team members collaboratively developing work management practices. If these practices get imposed by leaders or solely developed by team members they will never satisfy the needs of both parties. Early in the life of a project if the objectives for both sets of stakeholders are put on the table and an honest, frank discussion is held about principles governing how those objectives can be met, a set of practices which both sides buy into can be developed.
It also helps to make the oversight process as seamless as possible. Use of visual work support tools such as physical or online Kanban boards can shift the model from assigning work to team members to team members signing up to complete specific work items while simultaneously providing transparency into what’s done and what’s left to be done.
Finally, reducing cross-initiative multitasking can enable staff to complete tasks quicker and with higher quality while eliminating the need for managers to have to constantly follow up with team members to ensure that priorities haven’t shifted.
Micromanagement is like Justice Potter Stewart’s famous description of the threshold test for obscenity : “I know it when I see it”. Given this subjectivity, it’s better to avoid getting being accused of it to begin with.
(Note: this article was published without micromanagement in March 2017 on kbondale.wordpress.com)
I'm reading Greg McKeown's book Essentialism: The Disciplined Pursuit of Less and many of the lessons within it echo the tenth principle from the Manifesto for Agile Software Development which is "Simplicity--the art of maximizing the amount of work not done--is essential".
In the past, I've mostly considered this principle as it relates to how we deliver value to our customers. It provides a constant reminder that practices, ceremonies, tools and artifacts are just a means to an end, and shouldn't be elevated as an end unto themselves. Minimal sufficiency should be our goal when expending effort on anything which doesn't create business value for our stakeholders.
But we can also apply this principle to our products.
While Greg's book provides a lot of insights, there's one line which really resonates with me: "If it isn't a clear yes, then it's a clear no."
Greg provides an example of the company Vitsoe which applies this filter when hiring new staff, but the same principle could be applied when deciding what to include in product backlogs. Let's consider the example of the mice provided with the first Apple Macintosh computers. The design team at Apple could have added multiple buttons and scroll wheels the way future generations of PC mice were designed, but a single button sufficed to allow a user to effectively use the Macintosh graphical user interface.
This principle is key when defining Minimum Viable Products (MVP). A good MVP should generate empirical evidence to support or refute a hypothesis and adding features which won't directly support that learning is waste.
But minimal sufficiency could be applied beyond MVPs to general releases. By doing so we can reap some of the following benefits:
To quote Greg, the next time you are considering whether or not to add a feature, ask yourself the question "Is this exactly what I am looking for?"
I’ve frequently said that project management is about bringing predictability to uncertainty and while a lot of my writing focuses on managing the impacts of uncertainty through effective risk management, estimation is another area where uncertainty needs to be addressed.
If you are fortunate enough to be managing projects where sufficient historical data exists to account for nearly all sources of variation then I envy you.
For the rest of us, here are some estimation principles which should be applicable regardless of the project’s domain or specific context.
Improving estimation is not a silver bullet to slay all sources of project schedule or cost variation but elevating project management capability is about evolution, not revolution!
(Note: this article was originally accurately estimated and risk reduced in July 2014 on kbondale.wordpress.com)
I've run into a few situations recently where Scrum Masters (SMs) are performing multiple roles and while they might have the capacity to do so, on any moderate sized initiative, it might be difficult for them to fulfill all the responsibilities of the SM role.
Some people may challenge this by stating that the SM needs capacity for daily standups, sprint planning, sprint reviews & retrospectives, but that should still leave them plenty of time to take on another role.
This perception is incorrect.
Agile ceremonies represent just the tip of the iceberg for an SM. As the intro to the SM role in The Scrum Guide states: "The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values." Notice the use of the word "everyone" instead of "the Development Team". Surrounding any project or release are many stakeholders who the SM needs to work with to ensure that their interactions with the Development Team are in alignment with Scrum values. And as any good Project Manager will tell you, effective stakeholder management consumes a lot of time! Removing impediments from the team's path will also take significant effort.
If the company does not have separate agile coaches to work on elevating organizational capabilities, the SM will likely spend effort on activities such as coaching executives, training functional managers and collaborating with their fellow SMs to identify patterns.
But let's say we have agile coaches and there are minimal stakeholders for the SM to work with. Couldn't an SM play another role?
Even if capacity permits, I'd still recommend avoiding either of these roles:
Focus is one of Scrum's five values. An SM playing multiple roles may not be providing their team with a good example of this value in action.
Resiliency is the ability of an object to return to its original form or position after being affected by a force. Change resiliency represents the ability of an organization or individual to bounce back after experiencing change.
Why is this an important ability to possess?
The cliché about change being the only constant applies to all industries, hence organizations with low change resilience are unable to adopt change at the pace required for them to remain competitive.
Some writers have used the analogy of a spring to describe this attribute – if you stretch it too far, it won’t bounce back, and if you don’t stretch it all, it will rust and also be unable to bounce back when pulled.
I prefer to use the analogy of a muscle.
A muscle needs to be fed, given the time to rest, but also needs to be stressed to the point of exhaustion and fatigue so that growth happens.
How do we know if we are feeding change resiliency well?
Check employee engagement survey feedback. If staff are indicating that they don’t feel engaged and believe that there is insufficient recognition of their efforts, the muscle is likely not receiving the nutrition required. Regular, right-sized recognition, coaching for development (and not just performance), and an emphasis on good quality talent management can help.
What about rest?
Ask any professional athlete what happens if they push themselves too hard for too long and they’ll tell you the same thing – their performance drops dramatically. It’s the same with change resilience. If staff experience a volley of changes with very little breathing room between to find their equilibrium, they will soon experience change fatigue and the good will which may have been built through well managed changes of the past will be lost.
So why do we need stress?
Although continuous change results in change fatigue, minimal change can reinforce a desire to maintain the status quo such that when a large change occurs, staff are unable to adapt in an agile manner. This is why it is good to have staff experience changes of different sizes and impacts on a somewhat regular basis such that their ability to cope becomes more dynamic.
Like all muscles, when properly treated, change resilience grows. Neglect it and you run the polar extremes of atrophy or fatigue.
(Note: Publishing this article in September 2014 on kbondale.wordpress.com boosted my change resiliency!)