To achieve real Business Agility, focus on Purpose rather than Outputs

maze

Do we know why?

Enterprise wide Business Agility is the latest hot topic in the Agile space, from conferences to meetups. The challenge is how Agile can impact business strategy in the boardroom, to enable the entire organisation to become more adaptive, rather than be constrained to process optimisation in software delivery teams. Terms like OKRs and Impact maps, Outcomes and Outputs, are now the focus of attention. This is a significant step in helping us to rightfully consider Agile more as something you are, the values held; and less in terms of what you do, the practices and tooling used. To many though, these are alien terms and appear as competing ideas, resulting in inertia and a continuity of the annual cycle of feature laden projects delivering to fictitious business cases.

To clarify; all of these topics are various approaches to address the same issue, they all exist to attempt to address the following critical question:

“What is our purpose, and how can we ensure that everything we are doing is aligned to it?”

Or as Simon Sinek puts it, “START WITH WHY”. Once you approach Agile in the context of WHY, then you can start to be Agile with your implementation of Agile, avoiding a swathe of common errors from dogmatic imposition of methodologies.

 

A problem with a lot of “Agile Delivery” is that while the approach taken in the teams is healthily supported by Scrum or similar, it is based on implicit assumptions that often do not hold true. Scrum assumes you are building the right thing in that it doesn’t really talk about how the backlog is created, only that it exists, but what if you’re not building the right thing, what if you are just building “Something”?

Enterprise delivery, or for those in large organisations with multiple teams, departments and managers, will know it: NORMAL delivery, suffers terribly from dependencies and conflicts. Millions are spent on delivering new capabilities or features and millions more managing the conflicts between them, without really ever being sure that their efforts are delivering the intended results that triggered them in the first place. Whole departments slowly slip into the “Build Trap” as Melissa Perri refers to it, becoming feature farms, secure in their high utilisation delivering a never-ending stream of potentially pointless changes to their products.

 

How should we operate?

At BCG I am privileged to work with people who are passionate about helping organisations and initiatives within them, understand WHY they exist, and from that ensuring that the efforts they put in are directly associated to that. VALUE DRIVEN DELIVERY we call it. Unless an organisation can express the PURPOSE it serves, it is near impossible for it to have strong value driven delivery underneath.

There is a cascading nature to the expression of purpose within an organisation and how that should connect to the activities and ways of working that affect the majority of a workforce on a daily basis.

  1. What is needed to be achieved is the PURPOSE
  2. How progress against the purpose is measured is its METRIC
  3. Combining PURPOSE and METRIC gives an OBJECTIVE
  4. Objectives need a PRIORITY
  5. Progress is made against the objective through achieving KEY RESULTS / OUTCOMES
  6. Employees focus on OUTCOMES through aligned MEASURES / REWARDS
  7. Those Results/ Outcomes are delivered through a series of OUTPUTS
  8. Outputs are connected to Outcomes on OUTCOME BASED ROADMAPS
  9. And finally this hierarchy evolves over time through a cycle of INSPECT AND ADAPT

While this feels logical, when we really unpack the ways of working in many organisations we find a very different situation. Often the purpose is known to senior leadership, but the activities within teams are often poorly connected to it. The metrics the teams are being governed by relate to the delivery of the outputs, rather than to the Objective and there is too little, if any, Inspection or Adaption. Lots of activity, not so much VALUE.

 

How to shift from Outputs to Purpose?

One route to this is through the adoption of OKRs, Objectives and Key Results, at an organisational level. Created in Intel and popularised by John Doerr as he transitioned them into Google, they are a simple way to express the concept to senior leaders that improvements come from focusing on the why, not the what. OKRs are Purpose driven to bridge the gap between strategy & delivery and are proactive, in that they drive decision making in feature capabilities capacity management.

Note these are not KPIs which are always grounded and achievable, OKRs are more ambitious. KPIs are lagging indicators that are helpful to measure progress and assess the effectiveness of existing operations, but they do not assure the reasons behind those activities or processes. OKRs and KPIs should work together, they serve different purposes.

An organisation should only have a few OKRs and have everyone use them to understand how their efforts contribute. There should not be a cascade of OKRs per level or department unless the organisation is extremely large. Cascading OKRs risks reintroducing the original issue of a disconnect between the activities of the teams and the higher level strategic purpose.

An example of an OKR:

OKR

An alternative is to employ IMPACT MAPS, as introduced by Gojko Adzic which have a strong correlation to OKRs. Impact Mapping is a little more structured and really helps an organisation to understand how their sense of purpose translates into what they need to do.

Once again Start with, WHY?

Impact Maps start with the Goal, which is broadly synonymous with the previously described Objective. Then there is a helpful division by Actor or “Who”. Who might contribute to the realisation of the Objective? This is useful in large organisations as it enables a division of efforts between those focusing on a goal targeting one group of users, while another division focuses on a different group. Then, for each Actor, Adzic breaks it down into tangible things we want to see happen which are similar to the Key Results, and lastly what Outputs will enable those Impacts to occur (important to note you rarely need to deliver all possible Outputs to achieve the Impact.

imapct map

In Adzic’s own words, “My understanding of OKR is that the KR part would map nicely to impacts on the map”. OKRs and Impact Maps are similar expressions of the same concept.

Within an organisation there are typically multiple Outputs being worked on, associated to multiple Goals. As long as no individual in the organisation is asked to contribute to more than one of them, then everything should run smoothly, however that is rarely the case. The Objectives, and the desired Key Results underneath them, need to be expressed as a clear set of priorities which are communicated to all employees. This will ensure it is clear which should prevail when there is ever a conflict for a person’s time. Those priorities will need to be reevaluated and recommunicated on a regular cadence by the senior leaders. OKRs are succinct so the communication effort should be relatively low. Where this does not happen we find teams competing with each other or at worst working against each other in pursuit of different goals. Shared capabilities will become stretched and expectations not met as people attempt to please multiple masters at the same time.

 

How to manage work by purpose?

It is one thing to create OKRs but it is easy to have this as simply an academic exercise that is quickly forgotten. Turning this into something that actually changes the ways of working in the organisation is where the benefit lies.  This is where OUTCOME BASED ROADMAPS come in (sometimes referred to as Goal based Roadmaps). Outcomes here are synonymous with Impacts on Impact Maps and Key Results within OKRs.

Traditional Roadmaps represent the planned delivery of a pipeline of features which leaves departments wide open to losing sight of the bigger picture and redefineing success to be software deployed or a process signed off. They also often assume a determinate system, where it is known from the outset what is to be done and how long it will take, which is highly unlikely.
Outcome Based Roadmaps are effective because they both accept the vagaries of delivering into complex adaptive systems and connect what is being worked (Outputs) to to a higher purpose that ultimately defines success or failure (outcome / Key Result). There is decreasing confidence of delivery  in terms of scheduling of the outputs. The next Output is likely to have an agreed delivery date within a few weeks range, while the Outputs six months down the line have a much wider date range to reflect the high degree of uncertainty that comes from projecting far into the foggy future of highly complex organisations and markets. A big distinction to more traditional ways of operating is that although teams are still working to deliver an Output (or learning about subsequent Outputs), their measures of success and reward are now taken against the Outcome. This approach helps to maintain a focus on the “Big Picture”, the reason why all the work is being done.

Outcome roadmap

This uses the analogy of Ice, Water, Steam. Things we are about to do are cold and solid, compared to things nine months from now that might cynically be described as “Hot air”. To keep the Roadmap relevant it needs to be refreshed on a regular basis, it cannot be done at the start of the year and left; we understand that the act of planning is more important than the plans it produces.

 

In Summary

Employees in many organisations are wasting huge amount of time, money and effort delivering changes to products and services without sufficient awareness of why they are doing what they are doing.  To address this organisations need to have a comprehensive answer to the question, “What is our purpose, and how can we ensure that everything we are doing is aligned to it?” To answer this organisations will need to adopt Value Driven Delivery and ensure they understand and follow these nine steps:

  1. Agree on Purpose
  2. Define the Metrics progress will be measured by
  3. Express the purpose with its Metric as an Objective
  4. Share the Prioritised objectives
  5. Establish Key results / Outcomes that support the Purpose
  6. Measure and reward people on the Outcomes
  7. Outcomes are realised though the delivery of Outputs
  8. Create Roadmaps that map Outputs to the Outcomes
  9. Inspect and Adapt

 

 

 

Credit to Dragan Jojic and Glenn Bowering for their contributions and support.

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter: @philagiledesign 

or reach me on LinkedIn here

Taking Pride in Psychological safety

Pride

Psychological safety can be considered to be the collective lack of fear of expression; we should look to emulate the aspirations of our society when considering the best working environments for our teams.

As the heat builds, heralding the start of summer, I have given thought to the Pride celebrations that are common in June. In the past weeks there have been two of the greatest in New York and London; and in an idle hour of sunkissed self-reflection I pondered why I found these explosions of colour and expression so uplifting. It isn’t the visual spectacle or the expression of differentiation that I find enriching, more what the staging of the event says about our society, and how it stands against the forces that seek to divide and label us. My joy at Pride doesn’t come from the pageantry of the participants, but rather the inclusiveness of the wider society that accepts and celebrates it.

It is freedom that is celebrated. Initially this freedom was legal freedom, and slowly it evolved to be freedom of thought and now approaches freedom from judgement. We are reaching a normalisation, a situation where my eight year old sees our married gay friends no differently to any other couples he knows.

At the same time, yet on an entirely separate mental track, I have been involved in facilitating discussions on psychological safety with colleagues at BCG. These sessions began with an exploration of the concept – a definition. The ability to speak up with a contrary opinion was suggested, this then progressed to a sense of collective trust and then ultimately to an agreement on an environment free from fear, and explicitly the fear of judgement. This is not the absence of judgement; quite the opposite, it is an acknowledgement of objective criticism that appreciates, and actively seeks feedback.

I explain psychological safety as when someone, even if they do not have the full context, feels comfortable in raising a concern. Their concern being heard and discussed with no loss of face with the person who raised it feeling exactly the same regardless of whether they were shown to be right or wrong.

If trust is something that exists between two people, then psychological safety is the group equivalent. It is a characteristic of a collective rather than of an individual. You can’t take someone from a safe team, drop them into a group of strangers and expect them to behave as they did before. Psychological safety fills the gap between people; like mortar between bricks, it binds them together and enables them to build great things when individually, even as a large group, they are weak and easily fragmented.

The parallels between extravagantly colourful dancers in the streets of London and senior executives discussing team dynamics in a conference centre, are as stark as they are unexpected. They are both exploring a very deep emotional question, “what do we want from our environment?” Those executives were considering this from the compartmentalised perspective of a team working with a client; but this is a wider topic that belongs more to philosophy than business: What are the traits of a society we would desire to be part of?

In response I assert that freedom from oppression is one of the foundations of a world we would choose to inhabit. At the heart of oppression is the consequence of judgement. The more severe the judgement, the more restrictive the society becomes. It is no surprise that LGBT rights is a common yardstick for a society. When criticism of a regime is personally catastrophic then public protest ceases almost completely, but criticism only ceases openly. Those opinions still exist, seething under the surface like a buried blanket of malcontent. Within what most would consider to be a progressive society, we need to be tolerant to everything other than others’ intolerance. We aspire to universal psychological safety.

Stepping back from the immensity of sexual equality, these principles are replicated in teams, like microcosms of the world around them. The brilliant TED talk here from Amy Edmondson makes the case in simple terms with real world consequences. It is unfortunate that the situations that have the most severe consequences of failure look to mitigate them through penalties which repress the actions most likely to prevent them, repressing that lone perspective that that isn’t the wire to cut, or that isn’t the right incision to make, or that civilian isn’t a terrorist. The consequence of repression of opinion in unsafe environments is hugely damaging because it robs us of the only weapon we have to combat the volatile, uncertain, complex and ambiguous world to which we are now struggling to adapt. It robs us of feedback, it steals the opportunity to learn and therefore improve. Being wrong isn’t a failure of learning, it is the very essence of it. The only real failure is the failure to learn, and without a conscious effort to engender and sustain a psychologically safe environment you are risking everything to protect the sensibilities of others. This isn’t just theory, the much lauded work environments of Google and Spotify explicitly call out psychological safety as critical to their success. Effective delivery is found between people: it isn’t the efforts of the individuals that bring moments of brilliance but in the marrying of minds and ideas between them and psychological safety enables those minds to connect.

It is important to address a common misconception, a false association with niceness that enables some to dismiss the concept as an abdication of responsibility for delivery. The author Allison Vesterfelt addresses this elegantly when she compares niceness to the much more powerful concept of kindness.

Niceness stays quiet. Kindness speaks up. Niceness is toxic. Kindness is healing. Niceness lies to keep the peace. Kindness knows the only way to make peace is to tell the truth. Niceness holds back. Kindness moves forward with humility gentleness, and grace.

Psychological safety enables kindness, niceness is the antithesis.

Unfortunately psychological safety is not something that you can purchase or achieve though participation at an expensive training session. Like happiness, it is a lagging trait. Like a seed, you can’t make it grow through sheer force of effort, you need to create the right environment, and step back. It will grow slowly and steadily but like a seedling, it is most vulnerable when just a young tender shoot. Teams are most at risk when they initially open up to each other, a misjudged word then will cause more damage than had the team not started to open up in the first place..

It is easier to bring about psychological safety as a member of the group rather than as the courageous activist, “Be the change you want to see in the world” and hold back from countering alternative opinions. It starts with vulnerability and stepping back from the trappings of power and authority. A desire to retain and enforce hierarchy is one of the most insidious enemies of a safe environment. Leaders need to step back from the trappings of power and authority to prove to teams that they genuinely welcome free expression. They must allow themselves to be vulnerable to having their suggestion countered or even dismissed, and when that happens they absolutely must react positively. In the long run it is better to be loved than feared. Rewards and recognition are at the centre of changing behaviours and culture. Those that speak up deserve kind words and respectful listening. Ultimately if a team can agree it is everyone’s personal responsibility to make everyone else look good, or even better than themselves; then psychological safety will flourish.

I am fortunate to have worked in teams where I could speak up, and I am proud to be able to say I have had my suggestions countered, been hurt by the criticism and managed to let go, prioritising the team dynamic over my own fragile ego. I have felt the infectious enthusiasm that comes from a safe team, it was a wondrous sensation that enabled fantastic delivery.

However I am prouder still to live in a society that celebrates my liberty to paint a rainbow on my face and not only does not judge me for doing so, but does not even assume that I am LGBT. I wish everything could be this psychologically safe.

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter: @philagiledesign 

or reach me on LinkedIn here

How Strategy Consulting firms are addressing their most complex problem

journey

It is the journey,  not the destination

 

Today’s business world is deeply complex. Complex as distinct to complicated. The distinction between these two is absolutely critical and is at the heart of the biggest challenge the consulting industry has ever faced.

Simply put; complex problems are those where the consequence of cause and effect is understandable but not precisely predictable, whereas complicated problems are entirely logical, and by extension fully predictable, which makes for a much more prescriptive approach to solutions and estimates.

There is nothing more inherently complex than the relationships between people, which, when combined with the premise that the best delivery comes from high performing teams, brings a slow realisation that the ultimate goal is how to enable and sustain these amazing teams.  Complicated problems, in contrast, do not last long, for the reason that once solved, they remain solved. The solution, by definition, can be repeated, and importantly for our modern digital age, anything repeatable is automatable. The rise of the machines has enabled our society to focus on the complex problems that remain, like a sunken settlement revealed by the draining of a lake. This change is occurring rapidly, certainly more rapidly than our business culture and management models have been able to adapt to. As a consequence we still approach these complex problems with the same mindset; question: answer; Problem: solution; Clear cause: precise effect.

Companies turn to external consultants for their expertise, for their ability to help solve problems but ultimately to obtain a solution. There is a huge expectation to have an answer, or better still the answer.  Here is the consultant’s dilemma, the ultimate in complex challenges:

How to give a successful complicated response to a complex problem?

Prescriptive answers to complex problems will inevitably fail, and the greater the timeline and scale, the poorer the result; but the alternative is a commercial minefield. How can you sell an idea that you haven’t had yet? How do you sell an operating model that can’t be defined other than through an emergent collaborative experience? It is a difficult response to give, instead of answering the question, suggesting that the question is wrong. They are being asked “What do I need to do?”, whereas it needs to be turned round until it becomes, “How do I learn what to do?”

 

The concept of Agile transformation has progressed a lot over the past few years, it has done so not through moments of genius, but the same way that we progress with all complex problems, through emergent discovery with as many learnings as successes. However it is important to acknowledge there have been successes. Some fairly enormous enterprises have really seen substantial shifts to a more Agile approach to business including such seemly unlikely candidates as banks and airlines. So what is the solution, what is the magical silver bullet? It is tempting to analyse what was done, collate findings, examine the end state and advocate those ways of working and commoditise it as being “the solution”.

Unfortunately it doesn’t work quite like that. The moral buried in each tale of success is that each is unique. If something worked it’s because it was carefully created and continually adapted to match the combination of culture, people and market conditions of that organisation and those conditions will never be repeated.  It is the journey, not the destination that was successful.

The challenge all B2B service companies have, is how to build trust. If the offering is expertise to help an organisation address their problems then that organisation is going to want some assurance that the partner’s skills and experience will be beneficial. Having some manner of playbook is the shortest, fastest and has been the most successful means of doing this. It reduces the client’s perception of risk because they believe they know what they are buying, but it exposes them to a risk of a pre-defined solution because playbooks tend towards artefacts and standardised process, they are designed to enable repetition, they are designed for complicated problems. They are yesterday’s solution for yesterday’s problem.

 

There are many playbooks, models or frameworks incorporating process, practice and method out there, all suggesting that their version is different and a little better than the others. They advocate that their approach will deliver the utopian business agility desired by business leaders everywhere.

There is merit in these models, at least some of them, or to be pedantic, some of some of them. The phrase, “All models are wrong, some are useful” was coined from statistical models but applies equally well in this context. The weakest models are those that lead organisations to believe that they can achieve business agility with no reference to organisational design and its supporting constructs of HR, finance and culture; but even those that are process heavy and customer light, can help in certain contexts as a good first step out of confusion. Any model that prescribes a formula of process and practice to achieve success will ultimately fail because it can’t adapt to the responses of those affected by it.  The big distinction to look for in Agile models is between those that prescribe an approach to learning and change, versus those that look to implement process and practice.

The best models are those that look to frame conversations rather than offer clear answers. What is needed is something that highlights the need to hold discussions on a plethora of topics; dialogues, not lectures. Some of those conversations will be short as the participants learn that things are in a good place, others will be long and difficult as they mutually discover there are significant differences between where they are and where they would like to be. Just discussing where they would like to be is hugely important. What is needed is a companion for a journey, not a guidebook for a destination. Models that give direction and purpose are much more likely to be effective than those that articulate a detailed solution.

 

To navigate out of this awkward dichotomy between undeliverable solutions and unsellable learning, the approach the strategy consultancies are now taking is to bring years of experience in navigating difficult journeys into a communicable format that their clients can buy into. What they have is an initial proposal of something that can be tried together and learnt from, where the learning is more important than the actual output. It is the learnings that help both parties better understand each other and where their journey will lead. Experienced consultants have taken many journeys, each has ended in a different place and each has had unique challenges but there will have been many pitfalls that were avoided with the aid of those experienced guides.

While Agile transformations are occurring in a very wide range of industries, every problem is a “people problem” and the ability to recognise those human challenges early is important for success. Experience is more valuable than theoretical knowledge here, it is the speed to learn that is important, the speed to recognise situations encountered elsewhere and adapt. This breadth of exposure to human challenges is behind why most Agile Transformations are supported by external staff, either expert independent contractors or consultancies.

There is one more element that is absolutely critical, and without which things flounder and the rich harvests from fertile ground slowly wither. It is not enough to seek learning, it must be enabled. Organisations are amazingly resilient in their culture, and will automatically protect themselves against changes that threaten the status quo. There are processes and rules which exist to perpetuate the observance of the processes and rules. For any substantive change to occur it requires those that are seen to own the status quo, to be actively involved in the change. This provides a safe space for everyone else to learn and importantly act upon those learnings to make the organisation a better place. It is the role of senior leadership to facilitate all other employees to learn, change and adapt; through their participation all others will feel sufficiently liberated to act. Once leaders are seen to value experimentation over compliance then the vast learning potential of the organisation can be tapped. It is this last piece of the puzzle where the strategy consultancies really have the edge over many others of equal talent in the market place. They have the relationships, and consequently trust, from senior leaders necessary to make clear the need for their involvement. They have the opportunity and the experience of supporting, coaching these leaders in making those journeys.

 

In summary; whilst the challenge of addressing complex problems to those that expect complicated solutions remains, strategy consultancies are uniquely positioned in being able to address the underlying issue. Success in this domain requires three things:

  • Comprehensive technical knowledge of Agile values, principles, associated progressive leadership techniques, and the many Agile models; what has worked elsewhere and the strengths and weaknesses each
  • Extensive experience in learning and adapting to address the human challenges that occur when trying to instil unfamiliar concepts and principles on culture, leadership and value centric delivery
  • Deep relationships with the leadership of organisations with the ability to express the changes and investments that are needed from them, not just their teams, to ensure understanding that Agile is about business values not IT processes

There are few players that can claim strong capabilities in all three areas. The challenge will always remain for the Strategy consultancies in balancing the complicated demands against the complex reality but their learning centric approach has the capability to deliver faster and with better results than anything else. The question that remains for these companies looking to embark on their journeys is, who do they want as their guide?

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter: @philagiledesign 

or reach me on LinkedIn here

Scrum Master! Who are you to tell me what to do?

talk-to-the-hand

I am regularly asked for help from people with a distress call along the lines of, ” I am a Scrum Master now, apparently, what do I need to do?” This is roughly my response:

There are some teams that have chosen to adopt Scrum, and I wish them the best, although they probably won’t need my well-wishes. Merely the fact that they have CHOSEN to try scrum exposes all manner of values and behaviours. To start they clearly have a degree of empowerment over their ways of working, and they also likely have a sense of commitment and passion about what they do, enough to try something to improve their situation. If they have chosen Scrum, it is likely that they have considered their context and their situation and believe that either it is a good fit, or that they can make some internal changes to enable it to be a good fit. Either way they will either look to recruit a Scrum Master or one of the team will look to adopt the role with a view to, if it works, make it a permanent full time function.

There are some teams in an even better situation, they are formed as Scrum teams in a context that is suitable, often referred to as “Agile by birth” and will often be supported by dedicated Scrum Masters – I had the good fortune to work in a team like this – the most rewarding experience of my career.

 

In my experience though, this is not the norm, due to their size many, many software delivery professionals find themselves inside large corporations where the freedom of working practices are more than slightly constrained. Often there is a degree of close interaction between teams that rewards aligned working practices within a value stream (for adaptive organisations – or skill based departments for others). Now in this context the choice to use Scrum hasn’t really been taken by the team, it has been suggested, encouraged, expected, requested or mandated depending on the culture of control within the organisation.

This brings interesting and typically unconsidered challenges, especially for the unfortunate scrum master who has been unwittingly appointed. In the type of organisation that has imposed Agile there is likely to be the expectation that the Scrum Master will impose the practices of Scrum. Typically this is in service of a wider Agile transformation imposition, and we are now looking at command and control from the top, through the departmental level and down to each and every team member. Attempting to achieve Agile values through rigidity is unlikely to be successful. People choose to do things, people choose to change or adopt new things and whilst they may do this in light of new information, it remains THEIR decision. You can’t forcibly change someone, attempting to forcibly impose working practices is deeply destructive, the team need to choose to adopt them. Here is the heart of the challenge of the expected / imposed scrum, because the team didn’t actually CHOOSE Scrum, it becomes very hard to hold people to its practices.

My suggestion in this situation is simply, not to. I think it is reasonable to have someone explain what Scrum is, and how it is different to their current operation, but then shift the focus of this coerced Scrum Master from working within Scrum guidelines to working within “Team Agreed Practices”. The role of the Scrum Master then becomes an enabler of continuous improvement rather than some Agile process police.

 

The role of a Scrum Master that was appointed, not aspired to, in a team that has Scrum requested of it, rather than chosen by it, is this:

To be the voice of conscience, to hold the team to account against how the team has chosen to operate; and to facilitate the regular discussions of how the team should operate.

When we start to talk about how things SHOULD be, then you’ll trigger questions like:

  • Why are we doing stuff?
  • What is going on?
  • How can we be better?

With a little support the teams will start to increase transparency, value delivery starts to become more important. The team will reflect on what they are doing and look to change, to inspect and adapt. The team will slowly build up to something pretty close to Scrum, and if they don’t it will ultimately be because they have found something better than Scrum given their unique context.

Remember that Agile is not the goal, Agile and all the practices and terminology that come with it are just other people’s ideas that helped them be better. Try to enable your scrum masters to be “betterment people”, rather than “enforcers of a process I didn’t choose”. This approach will encourage your people to be proactive about improvement, rather than instruments of repressive control.

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter: @philagiledesign 

or reach me on LinkedIn here

Why should I have a Retrospective?

Retrospectives: one of the first terms you’ll encounter in the weird and wonderful world of Agile delivery; but what are they and why are they important? Didn’t we cope well enough before without them?

So first a little definition, the term really entered our lexicon through the widespread adoption of the Scrum framework, in the scrum guide it is defined as follows:

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

I am increasingly finding that Agile-y terminology is a barrier to understanding and adoption. Unfamiliar terms can make us feel inferior or foolish, and new “In Vogue” practices can feel threatening because we may feel judged for not being part of the “In Crowd” which in turn can result in people rejecting these ideas as a matter of principle to avoid loss of face. Whilst this definition is technically correct, Retrospectives are far too useful to be constrained within the Scrum framework, and can be beneficial to people not in Scrum teams and not doing things in Sprints, or even in Software delivery….

looking-up

Retrospectives are really just an agreed time to focus on improving. Taking a step back from being down in demands of delivery to consider how things are being done; look up for a while.  This could be alone, reflecting on how you are responding to your situation; something that is significantly undervalued, but typically, retrospectives are a group activity, an opportunity for a group to reflect on how they interact.

 

To start it is helpful to discuss what a Retrospective is not, to clear up common misconceptions you’ll encounter. It is not to decide how to deliver a specific output, that would be a planning or design session. It is not to review something we’ve done, that would be a review. It is not about WHAT are we doing; it is very much focused on the HOW are we doing things.

It is important to appreciate why we need them now, when we didn’t really need them before, and really this is a recent solution to a recent problem. Historically organisations had strong hierarchies that existed to “command and control” large workforces; to ensure everyone did as they were instructed. As the work became harder to define and understand, we moved away from structured formulaic industries and towards an adaptive creative economy. We’ve seen the fundamental principles of scientific management collapse as we’ve delegated the decision making to where the information lies – which is rarely at the top. However, if those operating practices have been delegated to teams, then they need some opportunity to define and refine those practices. Put simply, we didn’t need retrospectives before because we told people what to do.

Any group of people that are engaged together, with collective ownership and responsibilities to deliver something, that requires a degree of creative thought will benefit from Retrospectives.

 

I still regularly encounter teams of people working together that resist having anything akin to a retrospective. If you are free to choose how you work and the work is in any way creative then I am going to stick my neck out and say there is no good reason not to have one.  The two most common defences I hear are:

“We are too busy”

“We don’t need to change”

I will rephrase the first as “we are running so fast we have no time to reflect”, which clearly is an unsustainable business model.

tobusytoimprove

The second is also rather short sighted, we don’t need to change means we don’t need to improve.  Either improvement, hence performance, doesn’t matter, or maybe, just maybe your delivery unit or team and the interactions you have with your wider context is perfect. Perfect… Maaaaaaybe.

bullseye.jpg

Usually though, these defences are excuses for something much more troubling. I don’t want a Retrospective because I don’t want the team to think for themselves, because I want to retain control. If you are in this situation then you need to engage at a level higher and talk about principles.

 

When it comes to retrospectives there are three things I recommend:

  1. Have it on a cadence as frequent as pragmatic
  2. Try to make the attendance as consistent as possible
  3. Try to make the retrospective as different as possible each time within the two previous constraints

A regular cadence (the regular interval they are scheduled for) will ensure that they actually occur,  Like the difference between saying you’ll go for a run, and actually going for one… Retrospectives are playing the long game, immediate return is unlikely – but in the long term beneficial. It also helps to keep the conversations balanced and not drift into crisis management. You really want to be talking about the way we do things under normal circumstances, on boring Tuesday afternoons in March, rather than be overly influenced by extreme isolated incidents. The frequency will dictate the topics you are needing to cover and needs some balance; infrequent retrospectives can be overwhelming because of the amount of content that comes up, too frequent and the administrative overhead starts to creep up.

Consistency is important, you want everyone’s opinion but also the ways of workings you are trying to optimise will be related to the relationships within your delivery. If you keep changing those relationships then you keep changing the target you are trying to hit and you’ll forever fall short.

My third recommendation is where I see the biggest opportunity to improve with most of the teams I encounter. They have tried something, and it worked, so they have repeated it. There is merit to this normally, we practice and refine until we perfect. Retrospectives are curiously different and the expression, “if you always do what you’ve always done, you’ll always get what you’ve always got” is more appropriate. The principle is that by approaching the challenges the team faces in new and interesting ways each time, then the results and the suggestions you are going to get are likely to be different. Many retrospective techniques pull on expressing issues through different mediums, imagery or metaphor, this is to try to stimulate different neural pathways which will enable new viewpoints. There are many great retrospective techniques that you can use, and for me the best one, is the next one. I have a few that I fall back on when asked at short notice, but for a team I have worked with a lot, I typically try to do something different each time.

I am often asked to work with a new team and I only ask for one thing to be present before I accept, that the team is willing to run Retrospectives. If that is declined then I would strongly suspect that my involvement with the team will not delivery the results that are expected.

 

So, if you are a team, and you are not running retrospectives, why not? What are you afraid of?

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter: @philagiledesign 

or reach me on LinkedIn here

Is SAFe safe?

 

Stay safe

Recently I was at a Scrum discussion group hosted by Tobias Mayer. Noel Warnell posed the question, “Why scale?”. That was about as clickbaity as the title to this article and certainly attracted attention; and the conversation led me to the following realisation.

When we talk about scaling, we fall into one of two camps: either we are looking to grow our delivery capability and realise we will have too many people for a single team, or we already have lots of teams and are looking to make their delivery better. These two situations are enormously different and SAFe is suitable for one, but not the other.

When there is only a single team, likely collocated and cross-functional, then things are probably working well. The relationships within the team will be strong enough as to not require any compensating processes and you’ll find the Scrum guidelines will be a fairly comfortable fit. With this situation, if you need to grow, then your focus will be to not break things. You want to increase delivery rate BUT maintain all the great stuff you have with that engaged team.

In contrast, consider a situation with lots of teams all working together, in a borderline anarchic system, chances are things have grown organically or possibly as a result of an acquisition. I would expect multiple locally optimised groups, possibly clustered around technical components that are drowning in dependencies and technical debt. Having seen this many times and find it often stems from a misalignment of objectives and a “too busy to improve” culture. Commonly there is failure to appreciate it is attitude and relationships, not individual talent, that make great delivery. In this situation the objective is to fix the system rather than grow it.

When we talk about scaling we need to be clear whether we mean to GROW something, or FIX something, and the solutions to that challenge are likely to be very different. This brings me to SAFe.

Returning to that single team, all keen and dynamic and you put the SAFe picture on the wall and proclaim proudly that one day we’ll be a huge machine all using this approach, chances are you’ll get some strong feedback. There are very clear and understandable reasons why not a single signatory to the Agile Manifesto currently endorses SAFe, and many are vocal opponents; it isn’t really very “Agile” in the original context (and for more context and a few rants, Google is your friend). What you’d probably be looking for is something more like a hive mind, a network of highly engaged teams each swarming over their own challenges, connecting over common values and simple clean components. Pretty sure that isn’t SAFe.

However in the other situation, if you have an anarchic system with a lot of effort but little value, high utilisation but little alignment, then the introduction of something with significant structure and assurance for those that are trying to make sense of the madness is not the worst thing to do.

We need to consider how we naturally would look to improve a complex system. I suggest we’d take the following steps:

  1. Impose order to understand the current state
  2. Identify opportunities to divide the system into simpler parts
  3. Ensure a simple interface between potential parts to ensure they can separate without immediately rejoining or breaking
  4. Reorganise to break the system into smaller parts
  5. Improve each part in a custom fashion for what you need it to be

If you consider that Scrum is a delivery framework for solving complex problems, then this approach isn’t too far from that. Apply order (sprint), break work down with clear interfaces, deliver…

Realistically if you discussed the situation with senior management, the chances are they would like to reach stage five for their teams but are very nervous as to how to achieve it. The challenge is always to be able to improve whilst maintaining delivery expectations; change the plane’s engine while keeping it in the air. Very crudely, the LeSS framework looks to get to stage 5, but rather optimistically looks to leap to step 4 and hope that through strength of character things will pan out well. SAFe, on the other hand, is a lot less disruptive and so compliant to the status-quo governance and culture, that it really doesn’t have ambitions beyond the step one above.

If you are on a building site and it is on fire, it doesn’t matter how spectacular the architect’s plans are, what you need right now is a fire extinguisher. That is how I see SAFe: it is a coping mechanism. Once the fire is out, then you can start building. Awareness is a critical prerequisite to change, and SAFe brings that clarity, however it won’t really fix the situation. SAFe also comes at significant cost to surface and manage all those dependencies, and doesn’t really suggest how to remove them, but once you have visibility of what is happening, what value each role adds, or could add, then you can appreciate how to improve further. The real benefits come from moving beyond SAFe, not moving onto it.

So SAFe is safe as long as what you have is already broken, but only remains safe if you don’t stay SAFe forever.

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter: @philagiledesign 

You can buy Agile, but should we sell it?

Here is your Agile Transformation sir, I even put a ribbon on the box…

11092_ff2b6714-3be6-46f3-95f2-2bdf8f4c2180_grande

I enjoy reading the opinions and debates within the Agile community on social media, even contributing from time to time. Of late a few articles have stood out, maybe it is because I am seeing a growing trend of concern, concern for ourselves. The deepest concerns focus on the topics of “selling Agile” and “imposing Agile”, although I feel the question of imposing agile is related, in part, to resenting a revenue stream that others are achieving through “Selling Agile”.

Agile, at its heart is about feedback, about giving back and learning. Those who initially consolidated their ideas down into a written manifesto did for the best of intentions, the second line of the manifesto even states “… and helping others do it”. The point here is that the concept of Agile approach is a gift, for all. It was never created to make money.

There are very few things that have been created and given away for the betterment of the world, Penicillin is the poster child, but the concept of the internet could also be considered. The problem is what happens next – look how much money is now made from the internet. Wherever there is the opportunity to make money, someone will attempt to, and the more successful they are at doing it, the more others will be encouraged to follow.

Tragically Agile has moved from a theoretical ideology backed with a reasonable description, to a commodity. There are many many people bemoaning this slow transition, nearly all of whom are culpable – myself included. As they invested their time and efforts to gain skills and experience in this new concept, they needed to feed their families and pay their mortgages and started to sell what they had; in the knowledge that was “valuable”… You can either sell a service or a product. A service is customised to the client and is typically high value but being so customised is not very scalable,  it can’t be resold. Products on the other hand are consumer agnostic, one iPhone X is the same as another. Products are much cheaper than services, but they leverage economies of scale to enable huge profits. This is what has slowly happened.

There is now an “Agile Industry”. This used to be a few independent consultants contracting into organisations to support their self improvement along Agile principles, that work slowly morphed into what we call an Agile Coach. Then came engagements with larger organisations that required more work and the concept of the Agile transformation started turning up and that introduced the money pot of Agile training. The final step in the transition to a commodity was the certification; which is really an attempt to patent an idea. Now we have a multi-million pound industry ranging from independent consultants to large dedicated organisations selling transformation. The ultimate Agile product is the “Scaled solution” a highly comprehensive, easy to understand, standardised, easy to pitch, silver bullet offering rainbows and unicorns to all….

The problem with the product of “Agile” though, is that while most know of it, and everyone wants it, very few really know what really good feels like. We are now in the incredulous place with some massive multinationals investing in “Scaled solutions for Enterprise Agile Transformation” not because they really know what it is or means for them, but because other companies near them are investing in it. These companies are buying into their competitors decisions without actually having any competitor results to compare against. All companies want to improve, but few will naturally invite change because that is disruptive and risky, so if someone offers improvement, without making any necessary changes clear, then it is tempting to buy it. People are buying a transformation where nothing changes, a real twenty-first century emperor’s new clothes.

This is the salesman’s dream, the ability to sell something to someone who will buy it only because someone else has. If you can sell something without needed to tie a value return to your product then you can make millions, and millions are being made.

This is not to say that I don’t believe that an organisation becoming more Agile will be beneficial to them, I am just deeply uncomfortable that I can sell promises and dreams, and retire rich; free from the responsibility to ensure that those promises come true. If you don’t have to worry about the success of your product then you can afford to tailor your offering to maximise profits, which typically will mean to standardise the offering, shift it from a service to a product. To refer to a great Dan North quote, “Behaviours are practices in a context”; to get the desired behaviours you need to tailor your practices or change your context, or ideally a bit of both. However if you are selling a standard product then you need to be context agnostic, which means the results will be extremely variable.

Having worked in numerous organisations trying to make things better, I have concentrated on introducing practice at the bottom and changing my context through engaging at the top. If you can’t engage high enough in the organisation then you’ll struggle to impact the context you are working in, and the culture slowly erodes your efforts. If you only engage at the top, then the practices you are advocating will feel imposed and inappropriate which will manifest as resistance and failure. In my experience the lasting changes come from bottom up activity, enabled with top down intent based leadership, you need both. Importantly both come from within. It’s really quite hard to do this from outside and impossible to do without a locally customised approach.

I recently have had the opportunity to discuss Agile transformation with some of the most prestigious strategy and management consultancies. They are rightly reluctant to engage in snake oil promises to their prestigious clients, their reputation is worth too much to risk and they have seen their more delivery focused competitors flounder and suffer through overly commoditised transformation initiatives. However all are now feeling there is opportunity here; whether they all have the sufficient business agility to adapt their typically structured engagement models to support the more adaptive, immersive approach necessary to achieve real value change, I am not certain, some do for sure. If you start with the premise that we can do a rapid assessment followed by some predetermined structural and process changes from a standard playbook where the constraints to success are your own innate talent and efforts, then I struggle to believe you be successful. Things are likely to be different, but better?

If you want to help an organisation to become more Agile I firmly believe you need to have skin in the game of the improvement, you can do this as an external contractor, or a team of consultants but in both cases these people need to get inside the organisation, to be part of it, mutually learn with it. It is more of an experience based model than an assessment based one. Change comes from within, you can’t impose it from the outside. If you as a person want to be happier then that comes from within, from the outside I can dress you in jolly colours and paint a smile on your face but on stepping back, I now just have a sad clown.

The Agile industry isn’t really selling Agile, what is being sold is an ingredient in a recipe for success that also requires a lot of time, a lot of effort from within and no small amount of discomfort, but that doesn’t seem to sell quite as well. We aren’t selling cakes, we are selling flour, and the buyers need to be informed they’ll have to break some of their own eggs to get any benefit.  

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter or here at @philagiledesign

 

For supporting perspectives and related ideas read these excellent articles:

https://blog.agilityscales.com/can-big-consultancies-deliver-agile-transformations-56bd3c54c87f/

https://guntherverheyen.com/2019/01/07/the-illusion-of-agility-what-most-agile-transformations-end-up-delivering/

https://www.leadingagile.com/2019/01/raise-no-more-devils-improving-organizational-capacity/

https://www.linkedin.com/pulse/rethinking-transformation-tobias-mayer/

https://www.linkedin.com/pulse/adopting-agile-youre-aiming-wrong-target-tim-snyder/

 

Own your feedback

There is the highly quotable phrase: “Own your process, or your process will own you!”, well at least highly quoted by me… I have used it as a segue into pragmatic and value based discussions to avoid the worst consequences of dogma driven transformation. The premise being that the process should be adopted, not imposed; chosen by the people for the people (insert other inspiring taglines accompanied by images of eagles soaring over glaciers here). Jokes aside, there are some important principles at stake here, mostly around the benefits of empowerment and the importance of context to complex systems.

I believe that the underlying point of empowerment and context should be applied to other areas of our product delivery. If we want to consider our approach to be Agile, to enable the organisation to achieve business agility, then we have to focus on feedback. Feedback is at the heart of all things Agile.

I would advocate that we, “Own your feedback, or your feedback will own you.”

What do I mean by this? Well that if a product delivery system is proactive in its approach to feedback then it can use this data stream in an incredibly powerful manner. It will learn through iterative delivery to build a better product or service than could ever be initially conceived. Delivery that takes the strategic direction of the company and leverages real world feedback to adapt that vision to maximise value return. However, if we are reactive rather than proactive, then we either continue blindly on, or are led by the nose by a vocal minority to a destination, potentially far, from our original purpose.

 

To elaborate step by step: below is product delivery in a waterfall world. Assuming implementation into a simple environment where the consequence of our delivery is absolutely known from the outset, where the output leads unequivocally to outcome.

Feedback1

Here there is no feedback, there is no need for feedback, we know everything already. Delivery like this, is one of: rare, lucky or foolish, depending on your industry. Large scale technology delivery has been proven repeatedly to sit in the complex space where output ≠ outcome.

To be able to manage delivery in a complex adaptive system we have introduced iterative feedback led techniques, within technology we invented the term Agile although the concept of empirical adaptive processes was born long before. W. Edwards Deming (1900 – 1993 to give you an idea of when this dates from) advocated the use of what he referred to as the Shewhart cycle from Walter Shewhart (1891 – 1967, so even earlier) for which we now use the term “The PDCA cycle”, or Plan Do Check Act.

 

If you apply the PDCA approach to product delivery then you get something a little like this, where each iteration delivers output and you repeatedly revise that output based on contextual feedback until you confirm you have achieve a desired outcome.

Feedback 2

A slight tangent but it is worth noting that delivery continues until “A” desired outcome is achieved, rather than “THE” desired outcome, as good product delivery is cognisant that we drive to a direction rather than a destination.

Now consider the types of feedback that are available: I choose to split them into two groups:

  • Feedback we solicit
  • Feedback directed to us.

 

Feedback 3

Feedback we solicit

When the product delivery was initiated, it would have been to address a problem, a need, which needs to be able to be continually understood / measured so as to ensure that the changes are alleviating the problem / meeting the need. So this understanding or measure is a type of feedback that we proactively solicit. The feedback will ideally be a lot more sophisticated and built into the product, giving a lot of information about user engagement to the product. Product owners are typically all over the following information:

  • When is our product used?
  • How long is the product used for?
  • Are some workflows used more/less than expected?
  • Are there points with significant dropout?
  • What are the workflow completion rates (conversion for a payment)?
  • Proactive discussions with representative users on their opinions

Then on top of this, close user research would be maintained to observe first-hand the use of the product.

All of these pieces of information can be aggregated to paint a rich picture of the outcome of the delivery – as distinct to the output.

 

Feedback directed to us

This is feedback from users that are so affected by the introduction of the latest output that they expend the effort to inform the organisation about how they feel. They might be going out of their way, interrupting their day job, to let you know how awesome the delivery is, or, more realistically, that the latest changes stink, how much they stink and why they stink. They may be cordial enough to limit their frustrations though agreed formal channels – or they may just choose to vent their fury on social media. Critically however, the feedback is only from a proportion of the user base – a self-selecting proportion. It is fair to say that if some people contact the delivery organisation to say they are unhappy, then there are others that haven’t reached some critical “annoyed enough to complain” threshold; but it doesn’t mean that some don’t actually quite like it – and that “some” could be the majority.

 

Both these types of feedback are important, the former gives a full picture, the latter shows areas that are likely to be disproportionately impacting the users. These two feeds need to be balanced against each other. If 90% of the users are getting on really well, deriving value, and 10% have issues, then the delivery should focus on that 10% to either adapt a custom offering or provide training and support. whilst progressing on with the 90%. Consider what would be a likely scenario if only one of these streams were available?

Realistically one of these streams is always available, if users are unhappy they will make themselves heard, eventually, and the longer you leave it to listen to that feedback stream the more serious the consequences, until their final piece of feedback: “Goodbye”.

A product delivery not investing in their own proactive feedback is much more common. This is represented below and can easily trigger the reactive feedback stream to grow in importance – the delivery starts to believe it has a solid feedback approach in place because of the strength of the user comments.

Feedback 4

In this scenario, response to user comments becomes a delivery measure, addressing vocal problems becomes more high profile than delivery that doesn’t cause any. The initial strategic direction starts to be clouded by the “angry mob” to whom there is no data driven counter, and slowly but surely, the delivery descends into firefighting. It is like navigating through a hay barn with only a burning brand for light.

 

There are many reasons why the product delivery could end up here. It could be due to a naïve belief that they have the right solution up front – a refusal to accept the complexity of their environment. It could be due to a lack of skills or lack of capacity in product ownership, or more troubling or a lack of genuine ownership. I believe that the cost of not having a solid proactive feedback stream exceeds any involved in addressing skill or capacity issues. A lack of acceptance on complexity or a lack of ownership are more fundamental challenges to address however.

When initiating or looking to improve product delivery, shortly after owning your process, make sure you have established how to own your feedback, ideally before having to call the metaphorical fire brigade.

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Tweet me at @philagiledesign

 

 

 

Why aren’t my teams the best?

hands

I have worked with many organisations, both large and small, in house and as an external consultant, and one question that is common is, “What was the best delivery you have seen?”, usually with the hope of emulating it.

Identifying examples of good delivery is relatively easy as long as you have sufficient experience. Eventually you’ll stumble on something good, you may even have had the knowledge, skill and luck to have enabled that “something good” to have occurred. What is much much harder is to find the common thread in them, what made them good? Or maybe the question should be what made the others less good?

 

The “best” teams in my experience used Scrum for the most part, so it would be tempting to say that because they used Scrum they became a good team. Personally I do not think this to be the case. I believe that they had some characteristics already which enabled Scrum to be effective. The Scrum framework and its underlying Agile principles would likely positively reinforce those characteristics, but the effective use of Scrum is a consequence not a driver in my opinion.

This also gives a counter corollary that if those characteristics are not present, then a team will struggle with Scrum, it will be seen as “A poor fit”; “Doesn’t work here” will be a common opinion.

The existence of these underlying characteristics can be considered to be assumptions that we make when looking at undertaking an Agile transformation. I don’t believe these are sufficiently understood or validated before people start talking about manifestos and associated principles and frameworks.

I would summarise these assumptions as the following:

  • Our people work in teams
  • Our leadership set an example
  • Everyone is engaged to a common purpose

 

Teams

I have not encountered an organisation that would say they don’t deliver in teams, but often their definition of team doesn’t align to mine. A group of people under a common line manager does not constitute a team. Tom Loosemore, from GDS, I believe captured the essence in saying, “the unit of delivery is the team”. Simply a team is a group of people that have a common sense of success and failure; the success of one is defined by the success of all. If you operate in this manner then other characteristics such as collaboration will be a natural consequence.  For a team to identify with collective success they need a common purpose. If different team members are pursuing different goals then you will have a situation where some team members can feel they have achieved and others haven’t; at this point the team fractures, it is not really in their best interest to support each other. You can see how Scrum will grate on this type of delivery; there is little benefit one team member sharing what they did yesterday and will do today, if their peers do not have vested interest in that delivery.

Ideally teams will be cross functional, that is to say that they have all the skills needed to provide value within them. When some skills needed are outside the team, either you’ll build up dependencies to these external teams with the finger pointing that comes with it, or the team will look to do their best in that area with the skills they have; thereby bypassing the external team as much as possible, creating poorly used ivory towers of siloed skills.

We need to provide purpose,  and reward and recognise delivery at the team, rather than the individual level, if we want more than groups of people with a common line manager.

 

Leadership

What we want from our leaders is for them to set a direction, a vision, and series of goals and then enable everyone to be able to do their best, be their best to achieve it. When you hear tales of heroism in the military they are often justified with the phrase “they would do the same for me”. That is exposing the presence of real servant leadership, where the leaders primary concern is to bring out the best in their people and demonstrate the practices and behaviours that we should all adhere to. Our leaders shape the culture which defines the organisation. If we are looking for Agile principles to be adopted by our delivery teams they must first be adopted by our leaders, so the culture can be seen to be aligned. We can’t expect team COLLABORATION over team CONTRACTS if leadership are holding the delivery to a fixed time + scope contract. If we are looking to reduce work in progress at a team level, we must first look to reduce work in progress at a leadership level. As an example; I attended a presentation on an Agile Transformation within a UK high street bank at a MeetUp, this was floundering with a lot of process change but little benefit until they managed to show an Agile approach was being used at the board level to manage priorities and show transparency of effort, from that point on it became the path of least resistance (not no resistance mind).

We need to to be transparent about our Agile adoption at the highest levels of our organisation if we want the culture to align

 

Engagement

I have left this one till the end because it is the most powerful and the single biggest factor in my opinion between a successful team and one that isn’t. There was a Carnegie Institute of Technology study of successful people that gave the results that: success was 85% attitude and only 15% talent. The best team I have ever worked with wasn’t the smartest or most experienced, it was the one than cared the most.

I worked in a reasonably large multi team delivery some years back and one of the common complaints was “They don’t see the big picture”. I didn’t really understand this at the time, there was a lot of effort to explain the wider operation of the organisation and this project within it – with little result. I now understand the real issue was, “the teams delivering the system don’t seem to care as much about it as I do”.

In EVERY large multi team delivery system I have seen, this is a problem. Those systems are usually made of interdependent component teams where the concept of value is split across multiple teams. Here you have a separation of VALUE and DELIVERY. Many teams do not have the benefit of a personification of purpose within them. Their purpose is expressed as a contribution towards a goal owned somewhere else, by someone else, to be delivered at some point in the future. In this scenario is it very easy for heads to drop and a pervasive enterprise apathy creep in. At the heart of Agile, and facilitated by Scrum, is the concept of empirical improvement, if perpetual mediocrity is permissible then why go to the efforts of improvement?

Fundamentally Scrum works when you have something to deliver, if the consequences of lack of delivery are not felt personally and emotionally by the team, then the efforts required in Scrum will be resisted because the benefits aren’t really valuable – nobody really cares enough. Management may counter this by saying that they have been provided deadlines – but so are students for their end of term essays, which are typically started late and rushed, doing just what was needed, and this example matters a lot more than “someone else’s deadline.

One of the big differences between these large delivery systems and the smaller single team approach is how that Value or Purpose is personified. This is referred to as the Product Owner in Agile terminology –  someone who is emotionally, and ideally, physically present with a team through the delivery; not just at the start and the end.  They continually provide commitment for the team and are rewarded by commitment from the team. We may see the role in terms of their activities of requirements definition or prioritisation, but their greatest contribution is that they provide passion; they provide the team with drive – and simply – they often just aren’t there for each team in large delivery systems.

The problem is that drive is hard to measure and we naively assume that because the value can be articulated by a single person, then just one person is sufficient across the multiple teams involved to sustain the passion needed.

We need someone in each and every team who really cares about the outcome of the work if we want to sustain the maximum intensity in our delivery.

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me at @philagiledesign

 

 

 

 

 

Can a Teal society ever survive?

Elven city

I recently attended an interesting talk on the nature of what it means to be a Teal organisation using the concepts from Frederic Laloux’s 2014 work “Reinventing Organizations”. If you aren’t familiar with the model then have a look at a good overview here The Future of Management is Teal.

 

I appreciate the premise that we can look to classify an organisation, or at least part of it at any moment in time, based on the levels of collaboration found within it. Classifying things is rewarding, we are not programmed to revel in chaos, small steps to push back against the entropy of the universe gives us a feeling of control. Simple classification however is a blunt and brutal tool and much of the conversation I listened to wisely warned against this. The world is not made up of purely Red, Orange or Brown companies with some Green ones looking enviously at the smug Teal one in the corner, it is much more nuanced than that, companies change and often demonstrate multiple behaviours within them at once.

There was an undercurrent in the talk that the progression through the colours to reach Teal was in someway more, “good”, representing a better citizen, and if we imagine a world where all companies were Teal then the world would be a better place – and it is hard to stand opposed to that. There were sensible points made that some functions within companies are well served by a more autocratic operation (distinctly not Teal), emergency triage, legal etc but it was clear that Teal is something to be aspired to. My point is that I am sufficiently pragmatic, grounded, realistic, cynical, bitter and twisted (depending on your perspective) to not believe that we will ever get there – and this is why:

 

There was one contributor that raised the concept that hierarchies will always exist, that really resonated with me. The response to this was that we should consider multiple hierarchies at once, varying by subject; so, I’d look to you in matters of finance and you’d look to me in matters of marketing. This inspires visions of a beautiful harmony of thoughts and decisions, swirling round an aspirational idea of mutual respect and oneness with others. It only takes a couple of steps for this organisational psychology to cross a line into spirituality and I think this is where I felt the conversation crossed an invisible line of pragmatism into ideology.

One of the other talks I attended made reference to the distinction between our primitive “Red” mind (cerebellum and limbic system), keeping us alive and giving emotion, and our thinking “Blue” mind (neocortex), giving us curiosity and reasoning. Our Red mind has been around for thousands of years whereas our Blue mind is a very recent development. I believe Teal organisations cater to our Blue mind, but what of our Red mind? The theory that gave this distinction also identified that the blue mind can only operate if the red mind is satisfied.

It is overly simplistic to see the world in terms of good and evil, but seeing as Laloux felt ok to categorise to make his point, for the purposes of making my point, I’ll carry on! In my experience people have immense capacity for goodness but equally the willfully destructive actions of some can have horrendous consequences on many. The more we ignore the opportunity for evil then the greater harm it can inflict, this is one reason we have a military even when at peace. The idea of a Teal state ignores the evil in us all, the desire for status, power and control. My concern is that the aspirational Teal state cannot be achieved because it requires a level of consistent goodness in us that we cannot sustain; there will always be at least one that succumbs to baser desires to the detriment of the society around them. This is not to mean that we should not aspire to this state, but not to be disheartened when we fail to achieve it, or sustain it.

In the image below I have crudely overlaid Laloux’s progress of organisations with humanity, where the lines cross represents the point beyond which the evil in society corrupts sufficiently as to prevent an ideal state. Clearly this is a graph without scale or metrics but I feel those lines cross well before we reach universal adoption of Teal behaviours.

image1

Jessica Prentice’s excellent article, The most dangerous notion in “Reinventing Organizations” offers some solace. In it she reminds us that our culture has a depressing habit of after understanding something, believing we’ve invented it – the way that Christopher Columbus apparently discovered a new land, even though people had been living there for thousands of years already.

What she advocates is that societies long since crushed, using the example of Native American peoples, valued truthfulness, wisdom and community, and operated much closer to the Teal living organism paradigm than our capitalist societies of today. Therefore maybe it is something about our current society that enables the evil in us to run sufficiently wild as to prevent Teal being seen to be sustained. It is interesting to note that ideal state societies in literature such as the Elven kingdoms in Middle Earth or the Eloi in The Time Machine are very much more Teal than our current reality.

This isn’t to say it hasn’t been attempted, there have been multiple attempts to create a hierarchy-less collaborative “good” society. This has occurred in pockets, but small ones and usually not long lasting. A classic large-scale failure of this has to be the rise and fall of Communism in the twentieth century. The premise of the society is laudable, equal and harmonious, everyone working for everyone in a self-sustaining utopia; but when you remove the protections we have against humanity’s darkest capabilities the more terrifying their imposition becomes when inevitably they surface.

 

So where does this desire for status and control come from, if we consider that earlier societies didn’t have it to the same extent. Peter Drucker is purported to have said “you manage what you measure”, what if we take that to a societal level? Our current capitalist society measures, and by consequence judges, based on power and wealth. In such a society can a Teal organisation ever survive and thrive? A Teal organisation is likely to generate much goodwill and collaborative behaviours because that is what they are looking to optimise; but when pitted against an Orange “Machine” type organisation, according to the wider society’s measures of power and money, they are likely to lose out.

 

In conclusion while I will proudly state that I believe Teal characteristics as desirable and will continue to reward and nurture them where I find them; I am accepting, with a heavy heart, that I am unlikely to ever see this become the norm until the society I am in replaces power and money with collective fulfilment, as its measure of success.

 

Comments welcome

Phil Thompson

follow me on Twitter at @PhilAgileDesign