Enabling High Performance: Compelling Direction

I recently posted some reflection on growing high performing teams through the enabling conditions set out in the work of Richard Hackman. This post unpacks a little more of the detail around what is meant by a Compelling Direction, hopefully helping us to reflect a little more on the implications when working in our own agile settings.

A team with a compelling direction will ultimately find purpose in their work. In order to achieve that they will need to work in an environment which communicates a clear vision but where they are not dictated to in terms of how to get there. That's to say that the vision is ends specified but not means specified. In order to understand these concepts better we can look at two quadrant models.

A high ends specified and low means specified vision enables self-organisation and goal directed teamwork. The team will work together to examine the options available to them and make appropriate plans for moving forwards. The quadrant diagram below (source: Hackman) illustrates how such teamwork emerges in these conditions as opposed to possible disengagement when the means of the vision is specified but with little or no detail around the required end state. In these conditions teams will be following instructions with no real idea of the longer term vision or sense of purpose behind the work.

In other words a team can be considered to have a compelling direction when it has a real sense of commitment and meaning to its work and is operating in an environment where the work is ends specified but not means specified.

In terms of vision the team would ideally be working with a roadmap of questions or things that it needs to learn. There are no detailed requirements dropped into teams or giant roadmaps or backlogs of pre-determined outputs to deliver. The team is trusted to find it's own path and it embraces principles of transparency and feedback to inspect and adapt along that path as it moves forwards.

In order to understand the role of purpose further we can consider the degree to which a team is both committed to and finds meaning in its work. When a team is committed to work that it finds meaningful it can be considered to be in the purposeful zone, as illustrated in the second quadrant diagram below (source: Potentialife). For a closer examination of what it takes for a team to enter the the purposeful zone see the post Up a bit, right a bit.

In an agile context this will be a real team working towards outcomes over outputs. They'll likely have an owner of the vision in a role such as Product Owner, but they will work collaboratively with the team to communicate and explore the vision and map out appropriate options and plans.

Enabling High Performance: Real Teams

I recently posted some reflection on growing high performing teams through the enabling conditions set out in the work of Richard Hackman. This post unpacks a little more of the detail around what is meant by Real Teams, hopefully helping us to reflect a little more on the implications when working in our own agile settings.

A real team consists of interdependent members within a clear boundary and with a shared purpose for which the collective is responsible and stable enough to exploit differences and work well together.This means that the team works as a collective unit and fails or succeeds as a collective unit. The focus is a on the output of the team as a whole and not on the individuals within in. The various members of the team are dependent on each other and need to work together to get their work done, they're bounded by the need to collaborate rather than a loose application of semantics. The team is also clearly defined, it's clear who's in the team and who isn't and they're given the time and trust that they need in order to carve out effective working strategies.

A real team:

1) Has interdependent members. The members of the team depend on each other in order to complete their work and work towards their goal. They are not working in isolation of each other or as collection of distinct and independent silos.

2) Has a shared purpose. The team members are united in their reason for being. They are all working towards the same goal(s) and will succeed or fail together.

3) Has a clear boundary. The team members are clear who is in the team and the role they are playing. There is also a clear understanding of the wider community, key stakeholders and clear channels of communication between the team and those stakeholders. 

In an Agile context this will look like long formed stable teams, shaped around a product area with an accompanying and clear vision, a cross-functional focus and the empowerment they need to self-organise and shape their working practices. There are no back-end or front-end 'teams' passing work between themselves, real teams in an Agile setting are feature teams and can complete work and deliver value on an end-to-end self-contained basis.

Enabling High Performing Teams

The topic of high performing teams is a popular one in the agile community. Arguably, in part, because we often see organisations adopting agile practices as some sort of instant guarantee of high performance. Most of these efforts don't consist of much more than wrapping existing work and plans up into Sprints or the blind adoption of new terminology such as squads and tribes. They'll probably also have a tonne of post-it notes and whiteboards floating around and everyone will start standing up for the their morning status updates. Needless to say, not much comes from it.

High performing teams need to be cultivates, not just instantly declared into existence. 

This post takes a look at how we might grow high performing teams though enabling certain conditions. Specifically it takes a look at the model as outlined by Richard Hackman in his seminal 2002 publication, Leading Teams: Setting the Stage for Great Performances.

Hackman's work sets out five conditions for enabling effective teams, which we can also view as tidy and relevant areas of focus for any agile coach looking to unlock high performance.

Richard Hackman and Ruth Wageman in their 2005 paper, A Theory of Team Coaching, outline the following proposition:

Competent coaching interventions (i.e. those that foster collective effort, task-appropriate performance strategies, and good use of member knowledge and skill) are more beneficial for groups that are well structured and supported than for those that are not; poor coaching interventions (i.e. those that subvert team performance processes) are more detrimental for teams that are poorly structured and supported than for those that are well designed.

In other words, coaching on it's own is not enough. With effective foundations (enabling conditions) in place we can expect to be better positioned to benefit from expert coaching. Moreover, we can also view the formation of these foundations as a function of coaching itself. 

1. Being a REAL Team

A real team consists of interdependent members within a clear boundary and with a shared purpose for which the collective is responsible and stable enough to exploit differences and work well together.This means that the team works as a collective unit and fails or succeeds as a collective unit. The focus is a on the output of the team as a whole and not on the individuals within in. The various members of the team are dependent on each other and need to work together to get their work done, they're bounded by the need to collaborate rather than a loose application of semantics. The team is also clearly defined, it's clear who's in the team and who isn't and they're given the time and trust that they need in order to carve out effective working strategies.

In an Agile context this will look like long formed stable teams, shaped around a product area with an accompanying and clear vision, a cross-functional focus and the empowerment they need to self-organise and shape their working practices. There are no back-end or front-end 'teams' passing work between themselves, real teams in an Agile setting are feature teams and can complete work and deliver value on an end-to-end self-contained basis.

2. Compelling Direction

A team with a compelling direction may have a clear vision communicated to them but they will not be told how to get there. That's the say that the vision is ends specified but not means specified.

This in turn enables self-management and goal directed teamwork, the team will work together to find the best way forwards, examine the options available to them and make appropriate plans for moving forwards.

In an Agile context this will be a real team working towards outcomes over outputs. They'll likely have an owner of the vision in a role such as Product Owner, but they will be part of the team and will work collaboratively with the team to communicate the vision and map out how to move forwards. There are no detailed requirements dropped into teams or giant backlogs or pre-formed outputs  to follow. The team is trusted to find it's own path and it embraces principles of transparency and feedback to inspect and adapt that path as it moves forwards.

3. Enabling Team Structure

An enabling team structure refers to a structure that facilitates effective team conduct, work strategy and task design. This covers not only the composition of the group but also basic norms of behaviour and conduct.

The general rule of thumb for an Agile team is that their size should be around seven, plus or minus two people. Anything much beyond this can lead to communication overhead and a level of complexity in individual interactions that can reduce the effectiveness of the team as a whole. 

Alongside team size is the issue of diversity. A real Agile team requires enough diversity in skills and competencies in order to effectively self-organise and facilitate the production of working, full tested and potentially shippable software  Glenda Eoyang in her work on self-organisation in human systems talks about containers, differences and exchanges as conditions for self-organisation. In other words, a high performing Agile team requires enough differences in skills, experiences, insights and human competencies in order to drive effective interaction within the team and thus  driving them towards high performance.

This enabling condition can also be seen to extend from an an enabling team structure to an enabling infrastructure. In other words, an effective agile team requires the provision of technical infrastructure which supports the continuous integration and delivery of working software.

4. Supportive organisational context

In order to be successful a team requires the support of the wider organisation and a desire by that organisation to engender an environment and set the conditions for success. Hackman outlines the following as specific success factors that an organisation should look to enable:

- Environment - One that rewards favourable consequences for good team performance.
- Information – Data needed for the work are available for the team.
- Education – Any training or technical consults needed are available for the team.
- Resources – Material resources needed for the work are sufficient and available to the team.

A real Agile team works for the team as a whole, not for the individuals within it. For an organisation 'going Agile' the decision needs to be one underpinned by investment (n people, skills, knowledge, tools, technology etc) and not just a mere empty declaration. As such an environment that encourages, motivates and rewards team performance and is supported by  sufficient and appropriate investment to give the teams what they need to get the job done is essential when looking to engender high team performance.

5. Available expert coaching

Available expert coaching is important but it's own it isn't enough. Research by Hackman and Wageman suggests that that effective coaching as the most benefit with well structured and supported teams whilst poor coaching is most detrimental to poorly structured and supported teams. On the flip side, teams that are well structured are unlikely to be significantly damaged by poor coaching whilst poorly structured teams are unlikely to significantly benefit from effective coaching.

In other words, when it comes to the provision of effective (or otherwise) coaching, the poor get poorer and the rich get richer.

When undertaking an Agile transformation or initiative an organisation may focus almost solely on the provision of team coaching. The thinking above suggests that agile coaches should actually be focused on getting the other four pillars in place to enable the coaching to have maximum benefit. Arguably then, the first priority of an agile coach finding themselves in an ill structured and under-supported environment should be to get these foundations in place - only then can they, and the teams they work with, truly excel and enter the realms of high performance.

Scaling through Building Organisational Support.

As we kick off 2018 talk around scaling agile seems to have reached new levels  I've no hard and fast facts to support that statement only endless discussions of  the topic constantly filling up my Twitter and Linkedin feeds. Most of this discussion tends to be framework focused, pitching LeSS again DAD against SAFe and so-forth.

I'm not sure how productive this discussion often is, moreover it tends to just turn into one big slanging match. Not least though because when it comes to the topic of scaling agile I'm not even convinced everyone's talking about the same thing. Most of the time the discussion seems to be focused on the question of how to spin up as many Scrum teams as possible. How do you get fifty teams working seamlessly together? Or something similar.

A common response to such a problem often goes something along the lines of getting one team working well first. That seems like an eminently sensible position to take. If you can't even get single team Scrum working well then what is it that you'd be scaling to fifty teams?

The discussion often ends there, although perhaps there's something else we should be asking - how do you hope to even get a single Scrum team working well until you start scaling? It's important here to qualify that statement with a specific definition of 'scaling'.

In the above question the focus of 'scaling' shifts from how many Scrum teams can be instantly spun up to one of creating and scaling the conditions for effective agile practices across the organisation. Such a focus is represented as the fourth enabling pillar in  the team coaching model - a supporting organisational context. In other words, for a team to be successful then the wider organisation mechanisms and structures need to be in place to support the desired way of working.

In an agile context these organisational mechanisms and strictures will covering issues such as HR, performance and rewards, recruitment, architecture and product landscape etc. The fundamental question being asked here is that if such factors are not addressed at scale, i.e. at the organisational level, then will individual teams ever be able to realise meaningful and sustained success? If individual teams cannot realise success then what impetus will there be to start seeding activity more widely? Such a situation could be represented by the cycle below:

As such, if we take our definition of 'scaling' to mean simply replicating the practices of individual teams then perhaps we could be enabling a self-defeating cycle which works to discourage and prevent establishing effective wider practices and agility.

If we shift the focus of scaling to that of enabling supporting conditions then perhaps we can work to avoid this negative cycle and actually work to build a positive reinforcing one.

We can see from this why enabling organisational support forms a pillar in the team coaching model, because that organisational support is not just crucial for the performance of any one given team but also for the building of desire and momentum for wider change and improvement.

Perhaps therefore, the common question associated with scaling agile needs to switch from how can you scale until you've got single team Scrum right to how can you even get single team Scrum right before you start to scale, i.e. start to build the foundations for organisational support? In this context, good single team scrum can be seen as the result of effective scaling rather than being seen as the precursor to starting.

Often the focus of scaling seems to be a narrow attempt to increase the number of teams. If we consider scaling though to represent the appropriateness of the supporting organisational context, rather than simply the number of so-called Scrum teams then maybe we'll be better positioned to realise success.

Fearlessly Adapting to Change

As I experience more and more change initiatives of one form or another the more I see that most of the time they’re based on some sort of ‘hit and hope’ strategy. By that I mean they’re often driven by nothing much more than a lofty initial vision and then a lot of hope that that vision will somehow, perhaps magically, translate into a successful implementation.

In my experience these initiatives rarely result in the lasting change they set out to deliver. There’s a bit of brief initial energy and then things start to fizzle out. People don’t really fully understand or buy into the intended change, understand their role in the initiative or how they’ll help contribute to success. Such initiatives, it would seem, are setting out to fail.

Surely a better strategy is to set out to succeed, to take a considered and purposeful approach to change and maximise the chances of a lasting positive impact.

There are many tools that we can use to help with this including various change models and frameworks. One of the most well known in the agile space is the ADAPT model, an amended version of the more widely recognised ADKAR change model. The strength of this model, in my view, lies in its simplicity to understand and its effectiveness in practice. It recognises that lasting change requires a collaborative and motivating approach and sets out clear stages to help shape and realise that change:

Awareness that there is room for improvement

Desire to change

Ability – to work in a new way

Promote early successes to build momentum

Transfer the impact throughout the organisation so that it sticks

These stages help to provide focus to a change initiative by telling us what to focus on. They don’t however tell us much about how to achieve the desired outcome for each of the stages (Mike Cohn does offer some suggestions in his Succeeding with Agile book). It was through reading the Fearless Change and More Fearless Change books by Linda Rising and Mary Lynn Manns that I realised the patterns contained within make an ideal companion for the stages within ADAPT.

Rising and Mann describe their patterns as strategies for enabling change to happen, iteratively through small steps. If we view the stages within ADAPT as the what of enabling change then we can perhaps view the Fearless Change patterns as the how. Each pattern is based on real world observations and experiences, practical to use and theoretically grounded. Rising and Manns present 63 of these patterns in total and are clear about the nature in which they should be used:

“It’s not a recipe book for change. It is a book of patterns – nuggets. It’s up to you to decide if one or another nugget would be helpful in communicating your particular idea campaign within your organization”.

That said, with the sheer amount of information it can become difficult to maintain a considered view of what patterns you might use and when you might think about using them. It struck me that the stages in ADAPT might help bring some shape to this.

This is obviously always going to be a subjective view and some patterns will have a clear relevance to more than one ADAPT stage but here’s my initial view of how the Fearless Change patterns might fit with the stages of ADAPT (click image to view a larger version).

I realise that without the details of each pattern the above can seem a bit meaningless. Even though, perhaps such bringing together of strategy and patterns can help to evolve our understanding of change management more broadly.

In their 2012 paper, Back to the Future, Revisiting Kotter’s 2006 Change model, Appelbaum et al note that:

“Theories and approaches to change management currently available to academics and practitioners are often contradictory, mostly lacking empirical evidence and supported by unchallenged hypothesis.

Studying major change management projects is inherently difficult, due to their sheer complexity. Obstacles include difficulties encountered in evaluating the level of implementation of the steps and the challenge of corroborating implementation level with implementation success level.”

Could an approach of viewing potentially disparate change patterns through a strategy lens such as ADAPT help us to better understand the complexities of change initiatives, how to respond to them, the various steps and actions involved and the effectiveness of any patterns applied?

In other words, could bringing a new perspective to viewing and understanding change patterns help us improve our view and understanding of how to approach change and, in turn, of change itself? At the very least, the combination of ADAPT and the Fearless Change patterns might be a useful tool to help us review, consider and apply the various options available to us when setting out on a new change initiative.

Shaping the Strategy: Consultative Coaching

Hackman and Wageman (2005) posit that there are three fundamental functions that determine the level of team effectiveness. The second of these is the appropriateness to the task of the performance strategies the group uses in it's work. Coaching that addresses performance strategy can be seen as consultative in character.

Self-organisation is at the heart of how Agile teams work. Teams are empowered to make, own and execute plans for getting it's work done.

In doing so, and in line with the theory of team coaching, the effectiveness of a teams performance strategy will be influenced by two key factors. Firstly, to minimise mindless adoption or execution of task performance routines in uncertain or changing task environments and secondly to foster the invention of ways of proceeding with the work that are especially well aligned with task requirements.

Hence, in order to shape an effective performance strategy understanding the nature of the task at hand is of critical importance. The use of sense making frameworks such as Cynefin may be of help with this, but specific frameworks aside, the key point is that different situations require different responses. Although self-organisation will be at the heart of that response in an Agile setting, consultative coaching functions can help a team recognise the nature of the situation with which they're faced and to tailor their approach and practices accordingly.

Consultative coaching is best placed at the mid-point of performance cycles when teams have existing data to reflect on and are arguably more open to altering their performance strategies. The multiple feedback loops in an Agile context again give rise to multiple opportunities for the reflective improvements that consultative coaching can help deliver.

Sharing the Knowledge: Educational Coaching

Hackman and Wageman (2005) posit that there are three fundamental functions that determine the level of team effectiveness. The third of these is the amount of knowledge and skill members bring to bear on the task. Coaching that addresses knowledge and skill can be seen as educational in character.

At the heart of Agile approaches is the concept of continuous improvement. Moreover, the process of a team continuously improving stems from the team continuously learning. Effective teams will continuously develop new knowledge and skills, seeking opportunities to learn how to work better as a team in pursuit of their given task.

The Agile concept of a cross-functional teams and members with T-based skills strives to enable members to make a valued and continued contribution to the output of the team. Creating and maintaining an effective cross-functional team and T-based members though requires continued investment. Knowledge and skill need to be fostered both in terms of how to work well as a team and the individual task skills required within it. This is where educational coaching delivers.

Educational coaching is best placed at the end-point of performance cycles when teams have collected as much performance data as they can. With the task in hand complete and armed with maximum data, teams are arguably best positioned to reflect on their performance and internalise any lessons for going forwards.

Growing the Effort: Motivational Coaching

Hackman and Wageman (2005) posit that there are three fundamental functions that determine the level of team effectiveness. The first of these is the level of effort that group members collectively expend carrying out task work.

Coaching that addresses this level effort can be seen as motivational in character. The aim of motivational coaching interventions is to build a commitment to both the group and it's work. This commitment needs to be shared and maintained amongst all group members.

In practice this involves building an igniting purpose and a shared reason of being for the group. This is the area where we can see the importance of giving teams problems to solve rather than solutions to deliver. The problem presented to the team gives them something to unite around and a base from which to collaborate and derive a solution. This in turn builds a shared ownership around the problem and solution and an increased commitment to the team's work.

We can look towards collaborative specification approaches and tools such as Impact Mapping as examples of ways which can provide a team with an increased understanding of desired outcomes and input into possible solutions.

Due to it's character, motivational coaching is best placed at the beginning of a performance cycle. The different levels of feedback loop which operate in an Agile setting present multiple opportunities for the application of such motivational levers, e.g. at the individual feature level, at a Sprint level or higher at a release or project level. Moreover, with the use of multiple feedback loops the team will be presented with a range of opportunities to benefit from the increased engagement and commitment that motivational coaching interventions can help deliver.

Expert Coaching

Hackman and Wageman's Team Coaching paper outlines a functional approach to coaching underpinned by a temporal focus. It's this functional and temporal approach, combined with Agile and Lean thinking which forms a core component of the Expert Coaching pillar in the Agile Coaching Circle.

Hackman and Wageman base this functional and temporal approach to expert coaching on two key propositions and it's easy to see how they lend themselves to an Agile setting:

Proposition 1: Coaching interventions that focus specifically on team effort, strategy and knowledge and skill facilitate team effectiveness more than do interventions that focus on members' interpersonal relationships.

Within an Agile setting we clearly value a focus on the output and effectiveness of the team rather than of any particular individual within in. A model then that focuses on the team as a collective and building it's effectiveness as a whole is clearly one which lends itself to working with Agile teams. Coaching functions that focus on team effort, strategy and knowledge and skill can be seen as motivational, consultative and educational in nature.

Proposition 2: Each of the three coaching functions has the greatest constructive effect at specific times in the team task cycle. Specifically, (a) motivational coaching is most helpful when provided at the beginning of a performance period, (b) consultative coaching is most helpful when provided at the midpoint of a performance period and (c) educational coaching is most helpful when provided after performance activities have been completed.

This proposition offers obvious relevance to an Agile setting in way of the defined performance cycle and the distinct points within it. Agile teams seek regular feedback on their work, constantly going through performance cycles of their own and thus providing apt opportunity for the timely utilisation of the three coaching functions.

Combining motivational, consultative and educational coaching functions and their temporal application with a standard PDCA action and feedback loop gives us a clear and practical illustration for how we might consider and apply these coaching functions in an Agile work setting.

For more information on each of the coaching functions and their relevance in an Agile setting see below:

Motivational

The team coaching model posits that there are three functions that determine the level of team effectiveness. The first of these is the level of effort that group members collectively expend carrying out task work.

Coaching that addresses effort can be seen as motivational in character. The aim of motivational coaching interventions is to build a commitment to both the group and it's work. This commitment needs to be shared and maintained amongst all group members.

More on motivational coaching.

Consultative

The team coaching model posits that the second function that determines team effectiveness is the appropriateness to the task of the performance strategies the group uses in it's work. Coaching that addresses performance strategy is consultative in character.

More on consultative coaching.

Educational

The team coaching model posits that the third function to determine team effectiveness is the amount of knowledge and skill members bring to bear on the task. Coaching that addresses knowledge and skill is educational in character.

More on educational coaching.

Bang, and we're off!

Well it's taken a while but I've finally got myself down with the cool kids and started a blog. You may be wondering what's it all about? Well, let me tell you.

Essentially I'm going to be writing about all things related to Agile software development and project management. When I say all things what I actually mean is things that I've encountered and find interesting, enlightening or fascinating for one reason or another.

So what's piqued my interest enough to actually decide to start blogging about this stuff? I've been working in software development for ten years now and during that time have experienced a range of roles, approaches and environments. From a software developer and tester through to project manager through to ScrumMaster, from hardcore Prince 2 through to all things Agile, from a multinational FTSE 100 company through to smaller privately owned enterprises - I've undergone a bit of a journey.

For the past five years of this journey I've chosen to work with Agile projects and teams. The reason for that is quite simple. Of the different ways I've worked I enjoy this the most. I find it the most fulfilling and rewarding. A large part of that fulfilment and reward comes from the fact that I believe an Agile approach to be a great way in which to develop software. I should probably emphasise the last two words of that sentence though - develop software.

I recently met a self-proclaimed Agile coach who claimed to be the proud father of two "Agile children". What the heck?? How many software development professionals have you ever met that described themselves as a father, or a mother, of a couple of structured development lifecycle children? Hopefully, none!

For me the above represents an unfortunate tipping point. Working in a certain way because it makes sense and produces great results is one thing, letting that approach develop into a religious and overarching way of life or belief system is quite another. So as soon as I start preaching Agile's ability to bring peace to the Middle East or you find me at the alter praying to the great god Zen to come and pick us up in his Agile spaceship to fly us off to the planet Scrum and help us all become better human beings then I wan't you to call Tom Cruise, 'cos I reckon I'll be ready for the big league!

Despite a certificate to the contrary (a topic for another post) I also don't consider myself a master of anything. I hope that this blog will aid my learning, helping me to reflect on my thoughts and experiences to date and allowing me to learn from the input and experiences of others. All helping to guide me as my journey continues.

So, let the blogging commence!

Up a bit, right a a bit. Towards the Purposeful Zone.

The team coaching model posits that good coaching is most effective and poor coaching is least detrimental when teams are well structured and supported. Integral to being well structured are the notions of being a real team and that team having a compelling direction.

However, what does being a real team with a compelling direction look like in practice? The following quadrants are a simple tool that can help us better understand where our own teams might sit, taking into account the levels of meaning and commitment in their work.

A team in quadrant 1 has high meaning to their work but they lack a whole team commitment. This means the team fundamentally enjoys the work its undertaking and gets satisfaction from it yet ultimately they aren’t united on where they’re heading or how they’ll get there. A team in this quadrant can be characterised as dreaming. They’ll have ideas of what they’d like to be able to achieve and yet no joined up desire or plan on how to get there.

A team in quadrant 2 has low meaning to their work and a low whole team commitment. This means the team is lacking enjoyment and satisfaction in their work. The team struggle to relate to the work at hand and don’t see it as important. As such the team lacks a unified vision or understanding of where it’s heading. A team in this quadrant can be characterised as drifting. There’s work to be done although no clear desire or plan for moving forwards.

A team in quadrant 3 has low meaning to their work although they have engendered a strong whole team commitment. As with the drifters the team struggles to find personal meaning in their work and as such it can feel arduous with the effort to complete it somewhat forced. The team do however have a plan in place, they ultimately know where they’re going and have developed a strong team commitment to move forwards towards their goal. A team in this quadrant can be characterised as grinding away. They’re moving forwards but the journey lacks meaning and enjoyment.

A team in quadrant 4 has both high meaning to their work and a strong whole team commitment. Their work is important to them, they can relate to it, get enjoyment from it and understand the value that’s derived from undertaking it. The high level of meaning helps engender a strong whole team commitment to their vision and goals. A team in this quadrant can be characterised as purposeful. The high levels of meaning and commitment lends purpose to their work which in turn helps move them into the realms of high performance.

Where does your own team sit in this quadrant, are they in the purposeful zone? If not, how close are they to the purposeful zone are they and is it meaning, commitment or perhaps both that they’re currently lacking in their work?

Understanding where a team currently sits can help us better understand how we can help a team move forwards. As a general rule our role as coach should be to help teams move up a bit, right a bit in these quadrants. Work with the team to help them find increased meaning in their work and a stronger sense of commitment to where they’re heading and we can help move them towards the purposeful zone and world of high performance.

Another interesting exercise might be to see where you personally sit in this quadrant. How meaningful is your current work and how committed are you to it? Is there scope for moving yourself up a bit, right a bit? 

The Crystal Clear Tree

A little while back as part of an organisational merger I need to facilitate the coming together of two groups of agile coaches and agile project managers.

One group came from an organisation that was more Scrum focused and the other group from an organisation that seemed to be somewhat anti-Scrum, with scepticism around the defined levels of process and control within the framework. Both organisations however had a strong underlying alignment to agile values and principles and as part of the merger it was important that we identified these commonalities to provide a common ground for moving forwards.

There were also questions around how the teams at each organisation were working in practice. The two groups would need to come together and find a way of working in the new organisation and to do that we needed to explore and develop a shared understanding of each organisation and group’s current ways of working. For this to be an effective exercise we needed to avoid becoming bogged down in philosophical debates of Scrum, vs Kanban or any variation thereof and remain focused on exploring and understanding our practical commonalities and differences.

To provide a framework for that exploration I looked towards Alastair Cockburn’s Crystal Clear methodology and the properties contained within. For those unfamiliar with this approach Crystal Clear is part of the wider Crystal family of methodologies based on Alastair’s research of successful teams at IBM. Crystal methodologies are characterised by being human-powered, ultralight and stretch-to-fit (http://alistair.cockburn.us/Crystal+methodologies). That’s to say that they work to enhance the work of the people involved, to reduce overhead and bureaucracy and to start with something just smaller than you think you need and then grow it just enough according to context.

Crystal Clear is described as a human-powered methodology for small teams. It provides a highly optimised way to use a small, collocated team, prioritising for safety in delivering a satisfactory outcome, efficiency in development and habitability of the working conventions (http://alistair.cockburn.us/Crystal+Clear+distilled).

As such, Crystal Clear is a process agnostic approach to work which outlines the properties that characterise successful projects rather than prescribing a particular process or tool. This seemed like an ideal foundation on which to base our discussions, removing the potentially distracting topic of processes and tools from the equation and providing a neutral and focused container to explore how the software teams in each organisation strive to successfully deliver.

As part of using Crystal Clear in this context I gradually developed a way of illustrating the methodology in a concise and easy to understand format. In the spirit of agile growth and evolution I developed a Crystal Clear tree metaphor which is quick and easy to both deliver and understand. You can run through the metaphor with a team in just a few minutes and deliver a concise and powerful message. I thought it would be useful to outline here as an approach for outlining this lesser-mentioned approach or as inspiration for developing your own learning metaphor. I also happen to be a big fan of Crystal Clear and the thinking contained within and keen to support new ways of sharing that thinking.

*Apologies for the crudeness of the drawing

Roots

The roots of the tree represent the priorities of Crystal Clear. The priorities are essentially the outcomes that Crystal Clear seeks to deliver and they form the roots of the tree as everything else stems from them. Each priority is represented by a person symbol to emphasise the human-driven and people-centric nature of the approach. Crystal Cleat isn’t driven by process or tools, rather success is achieved though enhancing the work of the people involved. Each person represents a single priority; safety of outcome, efficiency of development and habitability of working conventions (whatever the ways of working, the development team needs to be able to live with them).

The Tree

With strong human-focus roots in place a strong a sturdy tree can grow.

Branches

The branches of the tree represent the Crystal Clear properties. There are two sets of properties in Crystal Clear, three properties that should be found on all projects (core) and four properties that are optional, although still important. It’s the branches that give the tree its shape just as it’s the properties that shape the success of a project.

The core properties are represented by the sturdiest, thickest branches whilst the optional properties are represented by branches that are thinner although still integral to the shape and balance of the tree.

The branches also provide a good way for the teams to measure their situation by gauging their alignment to each property. Teams can shade the branches according to where they think are with each one and use as a visual tool to focus and adjust their efforts.

Core properties:
1. Frequent delivery – The most important property of any project is to deliver working software frequently. Crystal Clear doesn’t dictate how frequently although greater frequency delivers higher project safety.
2. Reflective improvement – The team should regularly take time to reflect and improve on how it’s working. There’s always a better state to find.
3. Osmotic communication – This takes close communication to the next level. Team members are located so closely that they pick free-flowing information as though by osmosis.

Optional properties:
4. Personal safety – In order to truly improve a team needs to be able to speak out and address it weaknesses. In order to do this team members need to be able to speak out without fear of reprisal.
5. Focus – knowing what to work on and being able to work on it is essential to making progress. Teams should have clear goals and work items with minimal distractions.
6. Easy access to expert users – Rapid feedback is essential to gauge whether we’re heading in the right direction.  Expert users can be a valuable source of expert feedback.
7. Technical environment with automated tests, configuration management and frequent integration – Surprisingly still not embraced by all teams but all-important for safe and efficient software development.

Canopy

The canopy of the tree is made up from the smaller branches and leaves which represent the special eighth property in Crystal Clear; collaboration across organisational boundaries. This is property has special status because it’s a property in its own right providing additional project safety but also offers partial evidence that some of the other seven safety properties are being achieved.

It doesn't magically appear but comes from a strong sense of personal safety and working with a sense of honesty, amicability and integrity within and outside of the team. It can therefore be seen as a sign of a healthy ecosystem with the canopy being connected to and dependent on the branches of the tree.

Although clearly not an artistic masterpiece I find the simple tree metaphor works well to communicate the core messages at the heart of Crystal Clear. Hopefully it can be of use more widely and help spread the thinking further. In the meantime I’ll work on my drawing skills.

Flying Blind or Flying Blinded?

Transparency is a central principle of agile working. However, the pursuit of transparency can physically manifest itself in many forms and they're not always necessarily good or useful. In practice I often see the two extremes of the spectrum, a total lack of transparency through to possible sensory overload from overly excessive, illy considered and poorly implemented visual management and other techniques.

The former is a case of flying blind without the ability to see how things stand, the current state of play, where we've been and where we might be heading. In an attempt to counter this teams often find themselves in the opposite space of flying blinded where there's just too much information and detail to absorb. The outcome though is similar, a lack of ability to see and understand where we are and what's going on around us.

Flying Blind

This scenario is pretty straightforward to spot. Take a walk into the team area, take a look around and there's probably not much to see. No visual indicators of what work is in progress or board to indicate the status of the work. Furthermore, there might not even be an electronic or tool based visualisation you can take a look at. The team are simply drifting along, although some of them may profess to have everything stored in their head.

"We don't need any boards or anything else, we know what's going on" they might say.

At the very least most members of this team probably have a unique interpretation of what's going on and of where things are heading.

Furthermore, in a wider context, the organisation also has little idea of what's going on. There's no view of work in the backlog, priorities, estimates, progress to date or anything else.

"You'll get it when you get it" is often the extent of any progress reporting in place. Sure, that may technically indeed be true although it's not particularly useful. In return I've seen organisations react to this by demanding all sorts of measures and artifacts, most of it as equally ill considered as providing no information at all; detailed backlogs, detailed story breakdowns, low level estimates for everything, burn-up, burn-downs, throughputs, task counts, actual vs forecast and just about anything else that can be fudged together.

If not able to effectively push back on this the team and organisation that's flying blind can quickly find themselves transitioning to flying blinded.

Flying Blinded

A team and organisation that's flying blinded still has little idea of what's going on. For the uninitiated this seems somewhat more difficult to spot, although seemingly obvious for the more experienced, or just half-thinking, practitioner.

Blind adherence and cargo-cult thinking are prime drivers in this area. "We're agile so we need our reporting represented on burn-down/up charts" or something similar will often be heard, even if it isn't clear what the charts are showing. I've seen all sorts of horror shows in action. Charts with more lines on it than a motorway atlas, a mixture of measuring units and indecipherable keys. As an aside, this is more often than not a case of using some electronic tool that automatically produces the chart and an example of putting rubbish data in and getting rubbish data out. The point stands though that such an artifact still tends to be published or provided to the organisation because that's what "agile reporting" looks like.

Another manifestation of flying blinded can be seen with a team task/scrum/kanban/anything-else board that tells you nothing much more than the number of different coloured index cards the team possesses. The point here is that the board is there primarily as an agile artifact, the team has one because "that's what agile teams do". If there's no real consideration behind what the board is displaying and how it is being used it will likely evolve into something that displays a bit of everything but  doesn't really show anything. Anybody looking at such a board is likely to be blinded by detail and colour.

I have three simple principles and three rules for providing effective transparency:

- Principle 1 - You should be able to see what's been before.
- Principle 2 - You should be able to see what's currently under way.
- Principle 3 - You should be able to see what's possibly coming up next.

- Rule A - There should be a single source of truth for the above and everybody should know where to find it.
- Rule B - Anybody can quickly look at the information and figure out what they need to know without anybody else having to explain it to them.
- Rule C - The information should be value/business focused.

Transparency means that everyone involved needs a common understanding of what's going on in order to support decision making around optimising value and controlling risk. It's impossible for this to exist both in a state of total blindness and in a state of being blinded by over-powering and extraneous information.

It's time to push back against the "mavericks" who would wish to visualise and radiate nothing and time to sack off the cargo cult tendencies and requests of others. It's time to reclaim the middle ground and provide true transparency by the provision of information that is appropriate, easy to find, useful and value-adding. Sometimes less really is more!