Easy in theory, difficult in practice

Scope creep is a very well known cause of schedule and cost variances, hence most project managers are vigilant about managing change.

Fewer project managers are conscious of the accumulative costs of change analysis and yet significant effort gets consumed by team members before a change request is ever presented to a decision maker. Baselines are the output of detailed planning and, if performed correctly, change analysis should provide impact estimates at the same level of detail as the project’s original baselines – this takes a lot of effort.

Sometimes it might be the cumulative effort of analyzing a large number of requested changes over a project’s lifetime whereas other times it might be the complexity of a much smaller number of requests that adds up.

The issue with this is that there is usually no cost or schedule allocation made within approved baselines for performing such analysis.

You might consider utilizing contingency reserves to cover such analysis but that would be like using your rainy day fund to get an architectural estimate on a new sunroom for your house – when you need that money for critical roof repairs, it will not be available.

You might feel that projects run using agile methods are immune to this, but even with those, if work item changes are large or frequent, team velocity gets reduced and it takes more iterations than planned to deliver expected business value.

So what can be done?

• It’s a good idea to have an open discussion with your sponsor and other key stakeholders at project outset to help them understand that no matter how clear they feel scope is now, there will be change and they can proactively address how it will be handled.
• As budgets and timelines are being estimated, consider getting reserves approved for handling an expected level of change analysis.
• Finally, if changes are frequent or of high complexity, make sure you are asking your sponsor to approve getting a “quote for a quote” and regularly reinforcing the message that there is a cost to change analysis.

On projects, change may be inevitable, but impact from uncontrolled change analysis doesn’t have to be.

(Note: no change requests were harmed in the original publishing of this article in June 2014 on kbondale.wordpress.com)

Recently I wrote an article about the potential for a Scrum Master to take on additional roles. While I was teaching a class this week, one of my learners voiced a concern about Scrum Masters who didn't possess deep technical knowledge of the product solution. He felt that without this expertise a Scrum Master would run into difficulties in building credibility with the Development Team. He also believed that a Scrum Master lacking this knowledge might not know enough to ask the right questions when trying to understand specific technical risks or impediments and hence wouldn't be effective in clearing hurdles from the team's path.

Having been posed similar questions in the past with regards to project managers, I believe the answer is consistent for both roles. Some technical knowledge is necessary, but given a choice between a technically savvy Scrum Master who isn't an effective servant-leader and one who has some technical competency but does a much better job of improving interactions within and outside of the team to enhance value delivery, I'll always pick the latter.

To keep myself honest, I decided to double-check my views against The Scrum Guide™. The only activity listed for the Scrum Master role which could be interpreted as requiring technical competency is listed in the Scrum Master's service to the Development Team: "Helping the Development Team to create high-value products". I take this as meaning that a Scrum Master has sufficient competency to encourage technical excellence but isn't necessarily challenging specific technical decisions or contributing directly to solution design or development.

A few years back I'd written an article covering the pros and cons of a project manager being a technical subject matter expert. The same risks apply to a Scrum Master such as the potential for the Scrum Master making assumptions based on their past hands-on experience or the likelihood of their butting heads with team members when they disagree on specific technical matters.

As with all Scrum Team members, I would encourage Scrum Masters to become generalizing specialists and if they possess the capability and capacity to help the team achieve sprint goals, they should, but making this a default expectation of the role suggests that the supporting organization is not able to form a "whole" Development Team. Quoting The Scrum Guide™ again, "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment".

Servant-leadership is a lifelong journey of self-discovery and personal development. Let's not divert focus from that critical path by requiring Scrum Masters to also develop deep technical expertise.

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:

• Reducing learning curve. One of the attributes of well designed products is that they can be used with minimal instruction.
• Reducing ongoing maintenance costs. To quote Scotty from Star Trek III: The Search for Spock - "The more they overthink the plumbing, the easier it is to stop up the drain"
• Reducing ongoing regression testing efforts. As system complexity grows, the points of interdependence between seemingly unrelated components makes it almost impossible to avoid regression defects.
• Focusing development teams on core capabilities.

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.

• Use more than one estimation method: Consider this a form of hedging your bets. If you derive close to the same estimated value using different techniques, the likelihood that your estimates are significantly incorrect drops. Consider combining bottom-up and top-down methods.
• Document and share assumptions related to the estimates: It’s always a good idea to have a second pair of eyes review estimates, but without understanding the underlying assumptions which those estimates were based on, it can be very difficult to provide quality feedback. If the assumptions are not documented, it eliminates your ability to identify proactively when internal or external changes might invalidate the assumptions & their associated estimates.
• An estimate should never be provided as a single value: Without some understanding of the variation in the stated estimate, it’s impossible to manage the uncertainty resulting from it. This variation could be stated as a range or a confidence level.
• Discourage multitasking during estimation: Estimation takes significant mental effort and if the subject matter experts involved are distracted, the quality of your estimates will suffer.  Consider breaking up the estimation process into more short meetings as one way to overcome this.  Also, avoid estimation right after lunch time or at the end of the working day as your team might be less focused.
• Evaluate estimates across multiple dimensions: Just as it is helpful to use more than one estimation technique, it’s also valuable to analyze estimates in different ways to try to identify flaws. For example bottom-up activity estimation will give us detailed effort data at the work package level. But aggregating these estimates by resource role or by project phase will enable us to evaluate whether the ratio between roles or phases is logical.
• Remove the person from the evaluation: It helps to have peer-level reviews of estimates without knowing who produced them. This sounds wrong, but no subject matter expert is omniscient and our positive biases about them might cause us to unconsciously miss estimation flaws.

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)