Yearning for Simplicity

Stop complicating things

I was recently invited to contribute a talk to the Agile week hosted by Sainsbury’s. This was a wonderful initiative to share ideas and enthusiasm around their Agile journey supported by internal events and discussions and a few external speakers of high quality and industry renown, of which I was flattered to be in their number.

In the modern world our lives are increasingly busy, short term and digitally driven. We are bombarded by information and multiple demands for attention, however within this maelstrom of data, the things we still seem to value the most are the opposite. We value time, peace, small close human interaction with family and friends. We yearn for nature. We value the soothing sound of gentle waves on sand, the laughter of children or those heart warming yummy noises your friends make on sharing the meal you made for them. This is to conclude that, as humans, we aspire to simplicity.

I shared my thoughts on this with the group from Sainsburys, the beginnings of something I hope to put in more concrete structured terms eventually, whereas right now, although I can hold it for a moment, like rainwater in cupped hands, it drains away.

Broadly the premise is simply this: That hundreds of years ago people largely worked at a learned skill, likely familial, within small communities had a representative set of skills and collectively they were more than the sum of their parts. Typically there was a degree of craft and pride in the delivery of their work, be it farming, carving, furniture making or bread baking. The world was small.

Throughout history there is an ever present theme of the strong exploiting the weak. Landowners exerting as little effort as possible by coercing others to work on their behalf, reaching an extreme with slavery and plantations. It seems there has long been this battle between what is morally right and what is most profitable, where profitable is considered from the perspective of the very few who “Own” the enterprise. The industrial revolution is another excellent example, and is pertinent as it is the tail end of this period that created most of the operational and structural norms that govern businesses today. The Industrial revolution gave birth to the very concept of management.

At the heart of what was happening was the separation between thinking and doing. Thinking was the role of management and the doing was broken down into many pieces so that each operator only had to do something very small, but thousands of times a day to hone that single skill, looking for maximum efficiency. Basically, we turned thousands of people into machines, endlessly repeating a single task, a deeply dehumanising experience.

Fast forward to today, now those smoke belching workhouses have been replaced by efficient assembly lines, with varying degrees of automation from robots and computers. Increasingly employment has shifted toward more creative problem solving domains, more “thinking” work, less of the old school “Doing” work; however some of the silos adopted in that era remain. The principle that all work can be broken down, understood, sized and scheduled to be delivered with certainty for a fixed delivery date, still exists as the norm in many institutions. This may just about still hold true for the few remaining mechanical tasks, where there is little variability in the work, but isn’t, and has never been, true for creative knowledge work.

My entreatment to the audience was not to see our Agile labelled ways of working as something new, a natural evolution of professional progress, but rather a return to a simpler approach, much more aligned to how we naturally would operate in a group of people in a self sustaining community.

The most successful ways of working are optimised for the worker not for the product, and as such we should optimise for the opportunities to express our fundamental humanity. Work that naturally aligns to our human traits such as figuring out problems or creating processes rather than having to follow those foisted upon us will deliver greater results simply because those involved are more emotionally invested in them.

So I ask you, as I asked them, what is the most natural way to address the need you have? Not what does this framework say, or what does that so called expert say…? First, just what is the simplest most logical and ethical thing to do? Try that and then reflect on what transpires, maybe that is sufficient, maybe you’ll need to iterate a few times, but ultimately I believe that this simpler approach will bring better results.

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

Follow me on twitter: @philagiledesign 

or reach me on LinkedIn here

We need to respond to change, rather than change our ways of working to follow the plan

Processed with VSCO with a8 preset

In the light of the Cornonavirus situation organisations need to reconsider WHAT they are doing, not just HOW they are doing it. Just moving people to work from home is to play behind the curve, it assumes that the market that you derive your value from is unchanged – and that just isn’t true any more.

These are strange times, for many of us who are working in the professional services sector, there is a global move to working from home and there are many techniques and tools that are available to us such as Skype, Zoom, Google Hangouts etc. However I want to challenge whether just focusing on those working practices is actually the best course of action.

We know that in complex, human based environments, feedback and learning are essential for progress and the best approach for that is collaborative working that delivers frequently to your customer base. Switching to remote working is going to hinder this, whatever tools you use it will never be quite as good as it could have been face to face. Simply telling staff to work from home is a mitigation strategy that attempts to negate the impact of the change. This is attempting to catch up with a plan, rather than really adapting to the change.

The reason for making this distinction is because I fear many have missed what the change really is. It is easy to see is as: I was working with colleagues interactively in the office, and now I am working in an isolated environment trying to do the same job.

However this isn’t really the change. If you were the only one to be now working from home, then fine, get a crash course in remote working tools to try and do the same job almost as well, but you aren’t. In fact it isn’t just your team that is impacted; it is your company, your competitors and more than that, your customers too. This change is also not for a week, or a month, and it is highly likely that in some areas, things will never completely go back to how they were. This change is HUGE.


The reality is that the norms of human interactions have been turned upside down in a matter of a few weeks. Things that we valued before, like catching up with old friends, have been pushed aside and new things, that we didn’t value much at all, now seem to be essential, like bizarrely, toilet roll. The current approach appears to be: “To change the ways of working while maintaining the same output”.  Regardless of how we do it, I would challenge whether the same output is actually what we should be aiming for?


We should remember that it isn’t the fastest or smartest that survive, it is those most adaptive to their environment. There is little benefit in effectively working from home to deliver a new app for cinema listings when nobody is going to the cinema any more.

When confronted with a substantially new scenario we naturally go through a three step process:

1     Assess the situation

2     Evaluate options

3     Implement and learn


Assess the situation

Start by taking a step back, challenge all the assumptions and accept the world has changed. Establish what the new situation is and how this has changed especially from the customer’s perspective. What are their needs NOW? Focus needs to switch to what will deliver value now rather than how to maintain working on what previously was going to deliver value.


I suggest the following actions:

  1. Immediately review portfolios of work and stand down any deliverables that are unlikely to receive the immediate impacts they were predicted to have.
  2. The product development lifecycle to be restarted in as many places as possible. Instigate small discoveries followed by ideation phases to really understand the impact of the changing world on their customers. Typically the ratio of this backlog building product exploration work to technical delivery is proportional to the level of understanding of the market, and as that is changing rapidly, the need for investment in this area has just gone through the roof.
  3. Assess the changes in the use of the products / services that are currently being offered and consider removing or reducing services that have seen a drop-off in use so as to repurpose efforts elsewhere


Evaluate options

Organisations need to go back to their fundamental purpose and look to understand how best they can fulfil that need in the current climate, their options are going to be linked to how impacted that purpose has been. A key question will be that can you fulfil your purpose when your customers are staying at home. Could you, like a restaurant who is in the business of feeding people, instead of expecting people to come to you, go to them? Can you do the equivalent of rigging up a truck with a barista coffee machine and drive along suburban roads like an old fashioned ice-cream van? In a new world where people aren’t encouraged to come to you, waiting for customers to arrive is a dangerous path to take. If you don’t offer you products and services online, but could, then there is no better time to start this than now.

When there truly are no options other than to wait it out and look to mitigate loss, then this may be the perfect time to switch to internal programmes of work rather than maintaining a very high service level to relatively few customers. Cutting staff is a distressing decision to have to make to reduce costs to survive, and I trust that those companies looking to do this have no other choice.


I suggest the following actions:

  1. Look to offer previously face to face services either door to door or over digital channels. It may require the former while the digital channel becomes workable.
  2. Consider the new data that has become important to us, can you access that, can you leverage that? For example if an organisation is delivering financial data to markets, then those markets are probably very interested in new dimensions on companies where data isn’t currently offered, because until recently it wasn’t relevant.
  3. Move transactions and offerings that would previously be in person to online, serviced by the same people that used to do this in person
  4. Ramp up internal work proportional to external customer facing work. Maybe this is the time to upgrade the servers, refactor that codebase, develop the internal training programmes package, or even just refurbish the office (switch bank cashiers to painters – we’ve all done a bit of DIY in our time)


Implement and learn

How organisations deliver against these changing needs given the new constraints placed upon them needs to be considered, and, as mentioned, this is where companies are focusing on remote working tools for example. However the changes needed are larger than this. Organisations that relied on footfall are going to need to reconnect with their customer base. Organisations that rely on teams delivering work are going to have to change how those teams are structured and controlled.


I suggest the following actions:

  1. The typical Amazon “Two pizza team” used to gauge team size is based off an assumption of human interaction that is no longer true. The emotional and bureaucratic cost when everyone is working remotely, rises considerably. Consequently organisations look to reduce their team sizes. I would suggest that teams in the region of four to five are likely to be able to work remotely much more effectively than larger groups.
  2. A centralised organisation that looks to control the actions of its people will struggle due to the reduced effectiveness of communications, the pressure needs to be on  how to delegate more. Empower teams that have the necessary information to make the decisions that they need to, and have leadership switch from making decisions, to ensuring decisions are being made.
  3. Arrange regular online or telephone based interaction purely for the purpose of interaction. We are social creatures and our mental health deteriorates when isolated. During a normal working day a large quantity of time is spent just talking to each other, laughing and smiling. These simple human interactions put us in a suitable frame of mind for doing the real work.


In summary, during these uncertain times we all need to be on the front foot about how best to adapt our business strategies and working approaches. To just focus on how to execute the same work as before, but from home, is akin to battening down the hatches in a storm. This is no simple storm, there has never been a storm like this before; what is needed is the ability to learn to thrive in a world of high winds.

Leave no one behind

arm in field

When seeking to support an organisation on the journey towards business agility, a more value centric, feedback driven approach, it is all too easy to overlook the reasons behind the resistance shown from some of the people affected. It is often not appreciated that they are a product of the system they have been in, they have been literally taught to be this way. The urge to want to brush them away needs to be resisted, as these people are just as important as those driving the change. If an organisation is looking to change, then it should not be leaving anyone behind. Their only failing is to be upholding the values the organisation gave them, that, until yesterday, were universally appreciated.

It isn’t hard to imagine the situation: you have been brought in to deliver an Agile transformation for an organisation; this is the opportunity you have been looking for and you are feeling positive. The request has come from the top this time, so even the cultural and organisational design issues should be on the table…..

You are working hard with both delivery teams and senior leadership but sometimes it feels like there are forces working against you. Don’t they see that this is a once in a lifetime opportunity to make things better? It seems like there are people who just don’t want to change, don’t want to see delivery being faster, more value centric; people who clearly don’t have the best interests of the organisation at heart and as such, probably should be weeded out. This is to say nothing of the swathes of people who clearly don’t have the suitable skills for working in a fast-paced cross-functional team environment. They are going to need to either adopt a steep learning curve or look for alternative employment where the expectations are lower.

Does this seem vaguely familiar? It is an easy trap to fall into, driven by conviction, a notion of moral righteousness about these ways of workings. We have seen the improvements elsewhere, not just to delivery but more importantly to people. To witness a lacklustre disengaged workforce metaphorically wake up from a foggy malaise and realise their full potential, is a genuinely uplifting experience; and it is what motivates us to continue our efforts. What is awry here is that the transformation isn’t all about US, this isn’t OUR moral crusade. We are enablers, a support function. Ultimately we are trying to make their world better, but not for us, for THEM.

Years ago there was a clear separation between the thinkers and the doers within a company, a small highly skilled group directing the activities of a large workforce of low skilled, and usually replaceable people. In this Taylorist view of the world, people really were a commodity, a resource. As the nature of work morphed into the creative or knowledge domain, then the people delivering the value have became essential to it. Now the purpose of the organisation is typically intrinsic to the people delivering it. The employees are no longer a means to an end, they are not a fungible commodity to be used and exploited. People are not resources. The employees, the people, ARE the organisation.

In this context, when looking to improve an organisation we are really looking to improve it for the employees. If the view on that improvement is that some employees need to be “Weeded out”, or “Lack sufficient skills to remain” then what is being said is that for the best interests of the people, some people need to be removed.

Take a step back from that and repeat it:

For the best interests of the people, some people need to be removed.

If we scale this premise up, to a societal level, then there are examples in history, some which relate to the most abhorrent acts that have ever occurred.

This isn’t to say that in groups there is no need to protect the masses against the destructive acts of the few, this is why we have performance reviews, gross misconduct policies and in a wider societal context, law enforcement and prisons. However, cultural norms are relatively static; the moral codes that govern day-to-day acceptable behaviour change very very slowly. Something which was socially acceptable today will not become repugnant tomorrow, or even next week or month. Within the context of Business Agility there is an attempt to move much much faster.

Systems of people do change, but they change slowly. You may have an opinion on the system, wish to change it and through your actions, usually supported by others, manage to instigate one; but this change will be gradual. People change at the rate that they choose to, not at the rate that others tell them too. The deeper the ideology, the deeper the emotional connection to the principle in question and the slower the change. Just because something is morally “Right” does not mean that people will adopt a new value set overnight, especially not if the RIGHT thing to do, is NOT the EASIEST thing to do. To look to “Weed out” people who do not change to a new value set within weeks or even a few months, is to misunderstand the fundamentals of how we, as humans, accept and adapt to change, and by association could be considered unethical.

To go full circle, when we encounter someone who is resisting or countering moves towards an Agile transformation, instead of looking for ways to go over or through the individual, we should look to understand what is driving their beliefs and actions. It is highly likely that their behaviours are linked to the system that they are in, and have been in for quite some time. Some of the people that will struggle the most are those that have the most invested in the current system, they are the greatest advocates for what WAS valued.

The system they are in has defined their role, their contributions, what is valued and helpful, and what is not. This system has processes within it that may have been in place for years. It is possible that the process has a longer tenure in the organisation than the employees that execute upon it. This person’s career may have been shaped and optimised against the execution of this process and likely their future trajectory planned against it. In this situation, a suggestion to remove the process is catastrophic to that person. You are removing their current purpose, challenging their prior value and removing their opportunities for growth and progression. The skills that they have spent years learning and honing are now redundant, those years of intellectual investment have been potentially wasted. This person deserves empathy not scorn and dismissal. Consider this another way, at some point in the future, it will be our world that is changing, how quickly will we be able to adapt, and how would we wish to be treated?

The capabilities, beliefs and behaviours of people who seem to resist change are a consequence of their participation within the system for years, and to suggest that they will be able to change these as fast as an organisation can change its processes and structures is naïve. The challenge of change towards business agility is ultimately one of culture, and each person within that organisation is a fractal manifestation of that culture. Now you can change processes and policies overnight but it won’t change the culture immediately. This is akin to putting on boots and a Stetson, it might make you look like a cowboy, but it doesn’t mean you are one.

Therefore if the organisation, through the permeation of its culture, has shaped the individual to be what they are today, then it has the moral obligation to help its employees through any change it attempts. For an organisation to “Weed out” people who are not supportive is to punish people for being what the organisation has created them to be.

There will always reach a point when persistent behaviour associated to a prior values will no longer be acceptable. This occurs once the whole organisational culture can be said to have changed, not just the visible elements of it, but the principles and values beneath them. Patience will always run out eventually, but it needs to have been demonstratively shown.

The most extreme situations of resistance I have encountered have been understandably associated to organisational design changes to remove the walls between the traditional siloes of business and technology. People who have status, power and a career path associated to a managerial position within one of these pillars are enormously threatened. A possible path in these situations is to switch the perception of importance and respect to be associated to the ability to influence a decision and to provide support, rather than direct control or line management headcount. For this to work however, it needs to be a widespread cultural value. The individual in question will not self-actualise through these values if their peers around them do not follow suit. This is a great example of why a full shift to business agility needs to involve the whole organisation, not just cherry picked departments, to ensure that the whole management team experiences the same discomfort and adjustments rather than it becoming a game of winners and losers.

The decent approach is to invest in these people and provide them with support and coaching. Someone will need to understand their personal context, opportunities and losses with what is being suggested. Those losses need to be accepted and compensated for. Each affected employee needs to have the opportunity to find purpose and understand the value that they can contribute. Their learning and career path within the organisation will need to be recreated and agreed by both parties. It is the responsibility of the organisation to make the clear case for the change and how the employee fits within the new world. If they fail to understand the drivers behind the change so as to still not support it, then it is as much a failing of the organisation as it is the employee. It is fair to say that none of this will be easy or swift, but then successful systemic change rarely is.

Ultimately this is a question of empathy and responsibility towards the people that organisations have created. If we are in the situation of striving to enable an Agile transformation, what would it take for use to be able to see people as a product of their system and treat them accordingly?

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

Follow me on twitter: @philagiledesign or reach me on LinkedIn here

Credit to all those that provided comments and editorial support – you know who you are.








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


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:


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


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


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?


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….


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.


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.


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 I 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, rather than 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. Constrain delivery to identify the issues
  3. Identify opportunities to divide the system into simpler parts
  4. Ensure a simple interface between potential parts to ensure they can separate without immediately rejoining or breaking
  5. Reorganise to break the system into smaller parts
  6. 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…


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: