Applying and Measuring Psychological Safety

By AgileBusiness, Teams No Comments

When the environment is highly unpredictable teams need to adapt and move fast to survive and thrive and enabling the right communication norms and team culture is critical in supporting the kind of collaboration culture that generates high performance, adaptiveness and high energy. You can’t move fast when you have a toxic work culture characterised by fixed mindsets and internal politics. These things are important. Now more than ever.

So what are the norms that distinguish high performing teams? Google have long been renowned for their research in this area, conducting comprehensive multi-year studies across hundreds of teams and aligning these with academic research to show that the kind of factors that we might expect to contribute significantly to high team performance are unexpected. Instead of team longevity, background, personality or team member skills, a study that considered more than 250 attributes of over 180 active Google teams demonstrated that there were five key dynamics that characterised high performance

  1. Psychological safety: The ability to say what we really mean, and take risks in the team environment without feeling insecure
  2. Dependability: Being able to rely on other team members to do high quality work on time
  3. Structure & clarity: Ensuring that goals, execution plans and roles of individual team members are clear
  4. Meaning of work: The work that is being done is personally important
  5. Impact of work: The feeling that the work being done actually matters

Psychological safety in particular, is seen as a powerful concept in supporting team performance, and one that I hear and use often in my work with clients. Professor Amy Edmondson from Harvard Business School has defined psychological safety as ‘…a shared belief held by members of a team that the team is safe for interpersonal risk-taking’.

Analyst Ben Thompson has described a culture of true collaboration as being one that is able to combine mutual trust and respect and comfort with dissent which is a good way of thinking about what psychological safety means in practice.

These factors are critical to teams that can learn well, move fast and adapt well. With all the focus on skills and team composition, we don’t pay nearly enough attention to how the team communicates and acts and so creating the kind of environment that enables trust, exploration, equality of participation and healthy conversations is essential.

So how is it possible to measure psychological safety? As Richard McLean describes, a good place to start is to regularly ask the team 7 simple questions based on those that Amy Edmondson used in her original study, and rate how strongly they agree or disagree with these statements:

  1. If I make a mistake in this team, it is held against me.
  2. Members of this team are able to bring up problems and tough issues.
  3. People on this team sometimes reject others for being different.
  4. It is safe to take a risk in this team.
  5. It is difficult to ask other members of this team for help.
  6. No one on this team would deliberately act in a way that undermines my efforts.
  7. Working with members of this team, my unique skills and talents are valued and utilized.

A simple survey using a 1–5 scale of strongly disagree through to strongly agree creates a practical way for teams to monitor their levels of psychological safety and take action to mitigate specific problems.

For more like this, you can order your copy of Building the Agile Business Through Digital Transformation and the new book from Neil Perkin, Agile Transformation: Structures, Processes and Mindsets for the Digital Age. You can also join our community to access exclusive content related to the book

Photo by Matthew Waring on Unsplash

Optimisation vs Transformation

By AgileBusiness, Disruptive Innovation, Strategy No Comments

transformation

There’s one metaphor that I’ve found to be particularly useful in my work with clients in helping to articulate the opportunity and challenge in making smart decisions around technology and transformation. Now, more than ever of-course, these kind of decisions are critical.

If we look for examples of change within nature perhaps one of the most obvious is that of metamorphosis. There are two key types of metamorphosis, incomplete and complete, both of which are good analogies for the true opportunity that technology can afford – the opportunity of both optimisation and transformation.

Incomplete metamorphosis: Like the grasshopper above, in incomplete metamorphosis a big grasshopper looks like a small grasshopper – it simply sheds its skin as it changes and grows. This is a good metaphor for optimisation. The opportunity to use technology to do what we did before but better, faster, more efficiently or in more scaled ways. There is huge benefit within optimisation. But a bad or outdated process optimised is still a bad or outdated process. So sometimes we need to do more.

Complete metamorphosis: The caterpillar transitions into the pupa or chrysalis stage where everything goes into a kind of biological soup, the physiology and functional structure of the animal changes dramatically, and out emerges a beautiful butterfly. This is a great metaphor for transformation. The opportunity to reinvent, reimagine, remodel because to realise full the potential of technology we’re required to redesign processes, structures, operations, and culture. The challenge with this is two-fold:

  1. The ‘messy middle’ stage of transformation which is typically characterised by higher levels of uncertainty and complexity
  2. The need to unlearn some of what we know in order to put it back together again in a different way. The need to avoid looking at the new through the lens of the old. The need to move on from what we were before and embrace the new. Don’t mourn the caterpillar. Be the butterfly.

Making smart decisions about the application of technology is about understanding where the opportunity is to enhance or to drive new efficiencies, and where we need to rip it up and start again. Optimisation vs transformation.

Dealing With Agile Team Dependencies

By AgileBusiness, Teams No Comments

When scaling agile working and small multi-functional teams through the organisation we need to remove the barriers that prevent teams from progressing and learning quickly. An important part of this is being ruthless about keeping the team small. But we also need to ensure that teams have the necessary support and input that they require, and that they can access what they need when they need it in order to generate and maintain real momentum.

The model of Agile team onions, originated by Agile practitioner Emily Webber, is a way of structuring dependencies which in a large organisation might include necessary functional inputs (perhaps ops, legal, analytics, compliance, finance etc) that are involved in some way in delivery but which are still situated in vertical silos, around the core team. The onion is a way of creating understanding about who is in the wider team, and inviting them in without disrupting the small (and effective) size of the core team. As Emily describes it:

‘This isn’t just a stakeholder map, it is about bringing the organisation in and having shared responsibility for what you are creating together.’

The onion is classified thus:

Core team:

  • Purpose: delivery of digital services
  • Communication: Daily (all stand-ups, retrospectives, planning, show and tells)
  • Co-located: daily, all day
  • Types of people: product owner, scrum master, developers, designers etc

Collaborators (who might be working with multiple teams):

  • Purpose: bring in specialist information to assist the team, assurance as needed, reduce dependencies and blockers (open doors)
  • Communication: regularly, they come to some agile meetings
  • Co-located: on a regular basis (as a guide ~2 days a week) — this also depends on what is needed and the phase of project — but enough to be able to not block anything
  • Types of people: other delivery teams working within the same portfolio, security liaison, policy liaison, portfolio manager, operations, suppliers etc

Supporters

  • Purpose: keep informed, feed into broad organisational priorities
  • Communication: every sprint / iteration (show and tells, ad-hoc when needed)
  • Co-located: monthly or as needed
  • Types of people: steering groups, senior leaders, wider organisation

Mapping out your team onion, inviting people in, agreeing expectations and protocols establishes the right footing for it all to work. So ultimately, an organisation may consist of many overlapping onions.

In this way, the core team is kept at a suitable size to maintain velocity, collaborators provide necessary inputs to maintain momentum, and supporters remove barriers and provide direction to empower agility.

For more like this, you can order your copy of Building the Agile Business Through Digital Transformation and the new book from Neil Perkin Agile Transformation: Structures, Processes and Mindsets for the Digital Age. You can also join our community to access exclusive content related to the book.

Agile Planning Cadence

By AgileBusiness, Strategy No Comments

In Building the Agile Business we discussed pace layering as a way to understand agile planning and the different cadence at which elements of an organisation change. In Agile Transformation I took this further into how to link organisational strategy (which changes more slowly) through to adaptive execution (which is faster moving and changes more rapidly).

The recognition of the different cadences at which organisational components, strategy, and execution operate mean that we can create greater impact in value creation and change, and understand how to link the layers together in ways that make sense. Stewart Brand, in describing pace layering, talked about how:

‘Each layer is functionally different from the others and operates somewhat independently, but each layer influences and responds to the layers closest to it in a way that makes the whole system resilient.’

All durable systems, he says, have this kind of structure and this is what makes them adaptable but also robust:

‘Fast learns, slow remembers.  Fast proposes, slow disposes.  Fast is discontinuous, slow is continuous.  Fast and small instructs slow and big by accrued innovation and by occasional revolution.  Slow and big controls small and fast by constraint and constancy.  Fast gets all our attention, slow has all the power.’

The Agile Planning Onion

Søren Raaschou‘s concept of Agile Planning Circles is a nice build on this. Seeing planning as a layered discipline is an ideal way to navigate and reduce complexity. He references Mike Cohn’s ‘planning onion’ as a basic layered structure where planning is iterative but iterates at different cadences from annual strategic planning through to daily execution.

Image result for nike cohn planning onion

Image source

The idea of the agile planning onion is that the cadence and cycles become faster or more compressed as you go deeper with the inner three layers likely happening in the team environment – release planning works at the rhythm of the release cycle but it may take more than one iteration to fulfil a release cycle, and one iteration will likely comprise multiple daily standups. But planning like this enables the team to have good visibility and focus on what’s important across multiple horizons without getting tied in to an overly linear plan.

The outer three layers of the agile planning onion look further ahead. In product planning the product owner can look further out than the current release to consider the longer-term evolution of the product or system. Portfolio planning examines the potential of products to bring to life the vision of a business through its strategic planning, and where investment and effort should be made. Again, that link between organisational strategic planning and portfolio and then product planning is critical in implementing the strategic vision.

Some organisations (including some that I’ve worked with) fail to prioritise the creation of a product strategy that is closely aligned to the organisational or business strategy. The result is a weak or even non-existent product strategy which is not only poorly aligned with the needs of the business, but which can also result in product teams becoming very reactive and tactical, executing against the whims of multiple business stakeholders, leading to poor prioritisation and poor delivery of the company strategy and vision. In order to link business and product strategy well you need business stakeholders that understand the importance of product and product managers and owners that really get the business needs and strategy.

Søren Raaschou makes the point that a traditional Product Backlog can work well to contain what’s inside an Agile release cycle but if taken beyond this into product and portfolio planning can lead to challenges with maintaining the adaptability and true user focus that’s required. Breaking work down into Initiatives, then Themes, Epics and User Stories (work-breakdown structures) can be a useful way to link strategy with execution but it’s important to be wary of the kind of linear thinking that can creep in whereby in order to complete a Theme for example, we believe that we need to deliver all Epics within that theme. This belief about completing everything before continuing on can conflict with the agile principle of delivering the maximum value for the minimum effort. It’s not necessarily predictable up-front which User Stories or Epics will contribute the most value so we need to remain adaptive and able to re-prioritise at every stage.

Raaschou also notes how tempting it is to map a hierarchy of Themes, Epics and User Stories to organisational hierarchy and allocate ownership to descending levels within a business. The danger here is again that the delivery team become very executional and lose the autonomy that they need in order to make the best prioritisation and re-prioritisation decisions. Team members may also then lose the passion and motivation that naturally comes with the ability to really make a difference in the area that you are responsible for and in the visible contribution to and progress towards larger goals. Internal politics may also then skew the delivery of value towards individual interests rather than what is really needed.

In Agile Transformation I frame this as a top-down-bottom-up melding of business goals with customer needs. At the team level the flexibility is needed to reprioritise around customer need and feedback and do what is most valuable for the minimum effort. The organisation still needs to pursue its strategic direction, but in a way that prioritises customer need and value.

Agile Planning Circles

Image source

The Agile Planning Circles that Søren Raaschou describes is a way of representing this and features three connected circles that operate at different cadences. The team, he says, should be responsible for both exploration and development with the team iterating in the green loop representing the classic build-measure-learn loop of lean start-up, and periodically moving into the blue loop perhaps using design thinking to explore new possibilities. The changing delivery and understanding can in turn inform the red strategy loop when needed but this of-course requires the engagement of the broader business in a deeper way.

The loops don’t always follow a strict sequential order with the team doing what is necessary in order to deliver maximum customer value aligned to business goals. In a separate article Søren then goes on to detail the artefacts that may be used in each of these loops.

This is a really useful and practical way of linking business to product strategy to customer need and team delivery. It embeds an appreciation of the different cadences and layers of planning but also how they connect together. All the way through the process it is the interlinking of these circles that enables truly adaptive strategy and delivery.

For more like this, you can order your copy of Building the Agile Business Through Digital Transformation and the new book from Neil Perkin, ‘Agile Transformation: Structures, Processes and Mindsets for the Digital Age’. You can also join our community to access exclusive content related to the book.