Easy in theory, difficult in practice

by
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

Does a Scrum Master have to be a techie?

Are you just following up or are you micromanaging?

Essentialism is agile

Reduce risk by enhancing estimation

Because "It's there" is not a good reason to pursue agility!

Are you just following up or are you micromanaging?

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)

Posted on: October 17, 2018 08:47 AM | Permalink | Comments (11)

Essentialism is agile

Categories: Agile, Project Management

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?"

Posted on: October 14, 2018 07:00 AM | Permalink | Comments (14)

Reduce risk by enhancing estimation

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)

Posted on: October 11, 2018 06:59 AM | Permalink | Comments (20)

How many hats should a Scrum Master wear?

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:

  • Product Owner: Even if an SM has sufficient product domain knowledge, an effective PO has to spend a fair bit of their time interacting with all the stakeholders who have needs and wants related to the product and the effort required to distill these requirements into a clean product backlog is significant. There is also a potential conflict of interest by having the "what" and the "how" intermingled.
  • Technical Lead: I know that a true agile team is "flat", but for organizations going through their transformation journey, until quality development practices have been institutionalized and the shift from specialists to generalizing specialists is well underway there will be a need for senior technical contributors to review the work of more junior team members, mentor them and make key solution decisions. It might be difficult for one person to balance the servant-leadership and coaching stances of an SM with the more directive nature of a technical lead. When an SM is providing guidance to a team member, will that team member know which hat the SM is wearing?

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.

Posted on: September 30, 2018 06:59 AM | Permalink | Comments (18)

Change resiliency is a muscle

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!)

Posted on: September 26, 2018 06:59 AM | Permalink | Comments (12)
ADVERTISEMENTS

"Nothing defines humans better than their willingness to do irrational things in the pursuit of phenomenally unlikely payoffs."

- Scott Adams

ADVERTISEMENT

Sponsors