Easy in theory, difficult in practice

While speaking on the topic of psychological safety yesterday I was asked whether it is possible to create safety within a team if the prevailing culture of the department or overall organization is toxic.

We would all like to work for companies where leadership teams truly embrace people-centric values and principles but that is rarely the case, especially in organizations which have been in existence for decades.

It is common to find companies where the walls of their corporate offices are decorated with empowering, motivational posters of treating staff like their most valuable asset but this is usually a case of putting lipstick on a pig.

While organization cultural transformation cannot occur without the sponsorship and commitment of the management team, waiting for them to evolve is a cop out when it comes to creating safety within your team. As leaders, our responsibility is to create a safe haven for team members to work to their best abilities. While there might be stormy weather surrounding the team, we need to keep our team members within the calmer eye of the storm.

How do we do this?

It starts with building psychological safety between the individual team members. Even if they all represent different functional areas, roles and seniority levels, everyone wants to feel safe while at work.

Gain commitment from them as part of developing team working agreements and then reinforce the desired behavior by being a role model for how you want them to behave with one another. If they are not well informed about the subject of psychological safety, take the time to educate them about its importance. Recognize team members who act in ways to increase safety and coach those who diminish it.

But safety won't stick if it exists only between your team members.

Their work will likely require them to interact with those outside of the team, and often it is in those interactions where safety gets eroded. Until you start to see a corresponding level of safety being promoted by others, you will need to act as a buffer to protect your team members.

This will likely mean your having challenging conversations with senior colleagues who ridicule or threaten your team members, educating these stakeholders about the importance of safety, and escalating if necessary. It might also mean being more thoughtful about the planning of interactions between your team members and others, especially if the scope of the interaction is expected to be stressful, controversial or risky.

If you shy away from this, not only might you have to settle for mediocre performance, you may also risk losing the best talent you have. If you are successful at building safety, your team members will begin to reap its rewards and, in turn, will begin to demand it as table stakes for any team they join. They will become champions in their own right for safety and will help to build it within other teams.

And that is how positive cultural changes happen.

Emphasizing flow through the reduction or elimination of batching of work items is desirable but this is not always efficient or practical.

So what are some of the factors which might force us to batch work items?

Whether it is equipment, materials or people's time, constraints are a common reason for batching work.

Let's say we wanted to build a fence for a customer. While it might be better for the home owner for us to complete the full work for one section of fence at a time so that if the work spans multiple days the homeowner would progressively be receiving value, we might be forced to dig all the post holes first because we only have the use of an auger on the first day.

Maybe we are writing a software application which needs to have both English and French messages and we have no one on our team who can do the translation. If we only have access to a translation service for a week, we might need to batch the translation of all the screen messages and until that is done we can't ship the product.

Sometimes there might be a mandatory dependency that prevents completion of subsequent work activities till a preceding one is completed for the entire batch. When building a house, you would normally wait for the entire concrete foundation to be ready before we'd start building on top of it. When frosting a cake, it doesn't matter if half of the cake is baked - we'd wait till it is fully baked.

Economies of scale or a minimum requirement on how many work items can be efficiently produced might be another reason to batch work.

If I want to bake cupcakes, although the cycle time to bake and frost one cupcake is likely to be less than that of completing a dozen identical ones, the costs of wasted energy and ingredients from doing them one at a time would start to add up. Unless I have a customer who is willing to pay me that much more to justify producing single cupcakes, I'm likely to make them in batches.

This applies even if I'm trying a recipe for the very first time. While the volume of ingredient wastage would be reduced by baking a single cupcake, the benefits of baking a batch are still greater.

Or maybe I need to print some color business cards for newly hired staff from a printing agency. While there would be a per card cost, the overhead costs of setup, proofing and shipping might justify waiting till there are a few new hires rather that printing each set individually.

While some of these factors might present opportunities for continuous improvement to our delivery process, others are unlikely to be reduced or eliminated. We may wish to avoid batch work, but we do need to be pragmatic and accept that context counts.

A question which I'm asked regularly during my classes is what the best place is to start an agile transformation within a company? Given a choice, I'd prefer to use the cop-out (but correct) answer "It depends", but otherwise I usually respond that you'd want to do both a top-down and bottom-up approach simultaneously.

A common approach for major organizational changes is to start at the top with executive leadership, creating a coalition of commitment and support towards a shared vision for the future. This is critical with agile transformations for a number of reasons:

• Delivery teams don't work in isolation and hence buy-in to change how things are done will be needed from all supporting areas including human resources, finance and procurement.
• There will be the need for funding investments such as training, coaching, tooling and potentially even staffing new positions.
• Without changing existing portfolio intake practices and performance measures (e.g. shifting from a focus from maximizing utilization to maximizing value), it will be hard to achieve the full benefits of the transformation.
• To shift the established behaviors of middle management towards an agile mindset, the executive team needs to model the desired target behaviors first. Not only will the executives need to be coached to get there, they must also agree to hold each other visibly accountable to this new way of working.
• There needs to be a unifying vision for the transformation as well as a roadmap for how to get there. The executive team must be fully engaged in the creation of these key deliverables.

But there will also be the need to have engagement at the delivery team level. If individual team members are comfortable with how things are working and have no sense of urgency about the need for change, then their support will be superficial. Their buy-in is needed to:

• Develop the details of the new ways of working and inspect and adapt those over time.
• Feel comfortable designing and conducting experiments and having the occasional setback with those.
• Be willing to take on new roles and responsibilities.
• Be open to providing stakeholders with a greater level of transparency into their work and work flow than they have been used to.
• Collaborate openly with contributors from other functional areas whom they previously might have just cooperated with.

While these outcomes are needed, a key benefit of taking this top-down & bottom-up approach is that it will create a "sandwich effect" squeezing those middle managers who are unwilling to change how they work. Without that outcome, it is unlikely that an agile transformation will succeed.

I usually advise my students to encourage their team members to not provide padded work estimates, but rather to make schedule contingencies visible and tie these contingencies to milestones rather than to individual activities.

This is intended to counter the potential confluence of Parkinson's Law (work expands so as to fill the time available for its completion), Student Syndrome (let's wait till the very last possible moment to start an undesired activity) and Murphy's Law (anything that can go wrong will go wrong).

While this behavior might be true in some circumstances, it is based on a rather Theory X view of the world. Student Syndrome hurts no one other than the student procrastinating on starting their homework assignments or preparing for an exam. With projects, the impact of delays from one team member ripple downstream to others so with the exception of that small minority of Homer Simpson-like workers most of us want to do a good day's work.

So if the fault doesn't lie with the individual contributors, where else could we look for answers?

Today's Dilbert cartoon provides us with better root causes for this behavior - the system which people work in or the managers they work for.

How could the system affect work completion? Poorly thought out performance measures are one way:

• If staff are measured based on utilization, then completing work in less time means they are either going to be reprimanded or handed more work which they might not be able to complete by working a sustainable pace.
• If they are paid based on the hours they work, they could be tempted to work to plan to avoid being financially penalized for completing early.
• If they are measured based on the accuracy of their predictions (I.e. they are penalized for being early or late), then the work will tend to be completed exactly on time.
• If they are forced to fill out weekly timesheets and the process to do so is onerous, it might be easier for them to just copy planned time over as actual time within their time recording system.

Managers can also inadvertently cause staff to complete work on time, but rarely early by:

• Penalizing team members who complete work early on their future tasks by setting unrealistic target dates
• Giving them additional projects or operational activities to do rather than letting them use that slack time productively
• Breaking their focus by interrupting their work with urgent but un-important tasks

If we recognize that project activity durations are more likely to follow a lognormal distribution than the nice symmetrical normal distribution which we hope for, then we should praise team members for completing work early (within quality, safety, health and other constraints) rather than introducing impediments which discourage them from doing so.

Lean thinking encourages us to focus on maximizing value delivered to stakeholders rather than maximizing the utilization of the people, equipment or material resources contributing to value streams.

Two reasons for this recommendation are:

1. Systems which are run with no free capacity will have no tolerance for any impact which causes a greater utilization of resources than was planned, resulting in delays to the value we were expecting to deliver. While we don't expect such special cause variations when managing operational processes, with project work, Murphy's Law is often par for the course.
2. It is extremely rare that there is a perfect balance of the resources supporting every activity within a value stream. If we have one or more bottleneck, by insisting on maximizing the utilization of all resources contributing to the value stream we would end up overloading others or resort to unhealthy multitasking.

While managers might accept the above in principle, they might raise some concerns. If we don't maximize the utilization of our team members, how will they be adding value when they aren't contributing directly to the value stream or streams they are part of? After all, we are paying them for a full day's work so shouldn't we expect a full day's work out of them?

While some managers might worry that their team members' slack time will be misused for slacking off, there are multiple productive ways to use this freed up capacity including:

• Learning new things. When the focus is maximizing utilization for "billable" activities, learning often gets pushed outside of normal working hours. With down time during the work day, staff with spare cycles might use that time to increase the depth or breadth of their skills.
• Reducing bottlenecks. One way to reduce a knowledge bottleneck is to hire additional staff. This is a good short term fix but rarely does a company have sufficient funding to solve all of their bottlenecks that way. A better long term solution is to encourage methods for cross-training including job shadowing and non-solo work. Such approaches require that the existing staff have some free capacity.
• Making things better. Value streams don't improve on their own. When left unattended entropy increases within them. Staff need to have some free time to identify opportunities for improvement, explore possible solutions and run experiments.
• Enhancing organizational assets. There is a cost to developing and enhancing templates, playbooks and other forms of codified knowledge. In previous articles, I'd written that one of the common challenges with traditional approaches to capturing lessons learned is that practitioners rarely have the time to curate and refine the "raw" lessons identified over the life of a project.

Without some free capacity, your team members might be inspired to quote Scotty from Star Trek: "I've giv'n her all she's got captain, an' I canna give her no more."