Why aren’t my teams the best?


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



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.



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



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.


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

Transformation? Here’s what you need:


As those that have read my blog before will know; I have had my fair share of software delivery transformation experience, I am growing increasingly reluctant to even call it Agile these days to avoid any kind dogma based resistance. Some of my efforts have yielded results, some I’d even be brave enough to say were successful; but there are others that were complete failures. By failure I mean that the real fundamentals of delivery and value were not improved, people may have felt better, those refinement sessions were better organized, but the things that really matter didn’t move.

So I’d like to reflect and share what I feel makes the difference between success and failure, between charting a course though a minefield and rearranging the deckchairs on the Titanic.


I believe it comes down to having three things:

  • Knowledge
  • Understanding
  • Trust

Knowledge is pretty fundamental, whenever there is a discussion or article espousing the virtues of soft skills there is always some precondition that you need to know what you are talking about first, and my experience backs this up wholeheartedly. The knowledge in my world is mostly about Agile theory, practices and the management models that support them. Things like Scrum and complexity theory, Kano analysis and TDD, Lean UX and the workings of those highly controversial scaling frameworks. However, the big differentiator here is that it is more than theory, more than what can be studied and parroted back from Wikipedia articles, the ability to know what theory to apply in a given situation, that is the real skill. The difference between tacit knowledge and explicit knowledge.

When I refer to understanding it is about context, do you really understand what is going on, how the organisation reached its current situation? The drivers that got it to where it currently is are likely to still be the strongest forces that will be applied to any of your transformational efforts. Ignore local politics at your peril. As they say “Culture eats strategy for breakfast”. It takes time and an open mind to really understand this, to hold back from fixing the “simple problems” until you appreciate why they exist – chances are they won’t seem quite so simple when you do. There is a tradeoff to be made here though, the longer you work in a context to understand it, the greater the chance of that context influencing you, you go native and become as much a part of the problem as everyone else.

Lastly and most importantly trust. Without trust then you won’t get to influence the people that really can make a difference. Trust is the difference between being heard and someone taking action. As a transformation agent we have a number of skills we can pull from, facilitation can be beneficial with limited trust, mentoring requires a stronger relationship and coaching even more. Trust is usually harder to win the higher in an organisation you go, the time you spend with these people is less and they have more to lose.

This quote by S Covey pretty much sums this up:

“You need to have a good idea, you need to know how to implement it and you need the trust to carry it through”.


Requiring these three things also implies a fourth, something that people may not like to accept: time. Building knowledge, learning about the organization and winning trust; all take time, the latter two require time specifically in the current organisation. You can’t hope to enable substantial transformation quickly, regardless of your potentially staggering intellect.

The best approach I have seen is to focus on achieving understanding and trust through small changes at a low level that enable slightly larger changes at higher levels, until you work to a position of being able to support substantial changes at the highest levels around the same time that you have a deep understanding of the organisation and the trust of those that are accountable for it.


Best of luck

It depends…

Woman Shrugging Her Shoulders - Isolated

Scrum or Kanban? Should we estimate using Story points? and if those estimates are clearly wrong once we start work, should we re-estimate them? Should the PO attend the retrospective? Design Sprints? Technical Product Owners and part time Scrum Masters…? the list of questions goes on and on. This is my life, fielding an endless stream of questions from well-intentioned inquisitive people looking to improve their lives and the lives of those around them.

The answer to all of these questions is the same, always the same, “It depends”.  Most questions I am asked are focused on the practices that teams or individuals undertake within some framework of Agile delivery, so these are questions of process or tooling; usually HOW or WHAT questions rather than WHY questions.


Dan North neatly explained a lot of Agile execution with the neat paradigm of

Practice + Context = Behaviours

“Agile is a culture not a process” – another soundbite, this time from Jeff Patton, and the point is that what matters are those Behaviours, that Culture. The Practices, the tools and processes that we employ, are being used to try to encourage those Behaviours that we are searching for. The deep difficult WHY questions are about these Behaviours, the HOW and WHAT questions are more typically on the Practices.

How to use the practices is therefore dependent on the context in which they are being used. Context is critical, the context is also unique to your situation, and it is always changing, as a result the answer to those HOW and WHAT questions will always be different as the context is always slightly different.

One of the dimensions of explanation used with Cynefin are the concepts of Best, good emergent and novel practices. Complicated situations where context is predictable can employ Good practice, but in complex situations such as a team of people working together to build new software, then Emergent practices are favourable, which imply emergent responses to questions – that usually start…. It depends!

The downside of this is that discussions with Agile coaches can be very frustrating, those that see the role, and often by association the software delivery process, in the complicated space will find that they never get a straight answer. The coach will be seen as vague, elusive and non-committal.

Coaches have a responsibility to ensure that they are not seen in this light, to leave the situation in that state is to undermine their own capabilities because this damages trust. We should never say just “It depends”; it should always be followed up by some balanced contextual reasoning. Asking the opinion of the questioner is typically a good approach, it also puts the questioner into space of owning their own processes and practices, avoids the coach unwittingly doing the thinking for the team which leaves them open to adsorbing accountability and slowly disempowering the team.


Most coaches will agree with the sentiment in this article, as to whether it is useful to you, well that depends…

Tools, tools, tools – stop talking about tools!


I mentioned something about Agile tools on LinkedIn recently and my profile lit up like a  lightbulb; clearly this is an issue that people feel strongly about. The point that resonated most with my peers in the Agile community is that there is too much focus on tools – a little ironic, the thing that gets people talking is a comment that there is too much talking…. about tools.

JIRA, Github, Jenkins, Rally, Sonar Cube I could keep going for a while. These are tools that are used in the creation of software, often associated with the most current techniques, some of these are very “Agile organisation” orientated, others more targeted at the integration and deployment end of the cycle, but all of them help teams in their ability to deliver.

However you don’t get immediate results just because you have them. “We’re Agile because we use JIRA”, heard that one before? So why all the fuss, why all the focus? I believe this is simply because they are visible to management- their use can be identified by those who oversee delivery and are interested in any changes that are taking place within our teams. It is hard to see commitment increase a little, but easy to identify a JIRA board being used where previously work was tracked in a chain of emails.

What needs to be made clear is that tools are a means to an end; and as teams look to improve their ways of working they will likely encounter and experiment with some tools along the way, adopting a few that help, tweaking them to their context. The point here is that the team is looking to improve and chooses a tool. The use of the tool hasn’t driven the improvement – it is psychologically the other way round. Which is why the imposition of a tool won’t deliver any results independently and measuring the use of a tool can give misleading results. If the goal of your organisation is to have everything in Jenkins then a mass rollout and migration is just what you are looking for, but it is more likely that the goal of your organisation has nothing to do with Jenkins, probably more to do with selling something, and customers, and other much more normal stuff.


I’d like to look at these tools using the analogy of, err, tools. The kind of tools that people thought of when we said tools 20 yrs ago, the kind of tools that people outside our little software bubble still use the word for, like hammers and screwdrivers etc. I have quite a few of these tools in my house, and I consider myself pretty good with them. If you were to come to my house you may see the consequences of those tools all over the place, Shelves that are up, still up, and have never fallen down, Skirting boards that fit, units that have small modifications to fit into irregular gaps etc. What you are unlikely to see however, is any actual tools. You’d probably be quite surprised if you went to a friend’s house for dinner and they brought out their new 48 piece socket set to show off, or a box of screwdrivers with those nice rubberised handles you can get now. They might show you into the lounge with a large television on the wall on one of those moveable arms, and tell you they put that up themselves with a hint of pride, but the tools they used to do it, well they won’t get much airtime. The consequences of the tools are what we are interested in, maybe we used a hand drill and took hours over it, maybe it was a rechargeable cordless drill, maybe that old drill that you inherited from your grandpa and is still going strong – doesn’t matter really from the perspective of the person looking at the TV on the wall.

The choice and use of the tool probably matters a little to you in terms of how efficient you are with your time, and if someone asked how you put your TV on the wall because they quite fancy doing the same, then you might talk about tools, so there is a time and a place for those kind of discussions, but should be very much focused on the job in hand.

The other point about DIY tools is that ownership doesn’t infer competency. Just because someone owns a drill, spirit level and a screwdriver doesn’t mean that they can be trusted to put up a shelf… If you want to know if you can trust them to put on a shelf, go to their house and put something heavy on their shelf….

The last point I want to make about tools is context. If you are putting together a shed on your own, and you have a strange star shaped screwdriver and a set of weird star headed screws, then you could work quite happily to produce your shed – and the resulting shed in terms of speed to build and quality would be the same as someone using a more standard screwdriver and screw head. However if there were 4 people building this shed and each person brought their own unique set of screws with matching screwdriver then it would be clear the kinds of chaos that would ensure and the inefficiencies that would result. In this slightly bizarre world of multiple screw types, it would probably be worth taking a minute before starting the construction to agree on a shared standard, and the more common the chosen standard is, the less discussion would be required and the simpler the adoption from the group.


So now, enough talking about tools…

Am I an Agile Coach?

A new year, a time for retrospection and ambition. There is no better time to ask those deep questions, what do I stand for, what do I want to achieve? I am sure many others are doing the same.


So, what do I stand for, what am I? Most people I think have a relatively easy time defining their job, Doctor, accountant, Traffic warden; but what do I do, what am I?

I laughed at the time when I asked my boss what he wanted me to do, and he said “Make things better”, but on reflection that is probably the best description of my role there is, implies a vague and varied scope but a clear intention. I get involved in team dynamics, quiet personal one to one chats, programme governance, Agile ceremony facilitation, process mentoring, training and business analysis support, a bit of this, a bit of that, things that I feel need to be done, things that others request of me; all of it with a view to transforming the current state to something better.

The broadest industry term for what I am doing would be an Agile Coach. There are some that would say that means someone that leads Agile transformation programmes, or someone that gives Agile theory instruction, or maybe only a valid title if you are actually coaching – as defined by the coaching institute.

I like Tobias Mayer and Jem D’Jeyal’s podcast where they discuss the nature of the term Agile Coach and state they like the term Agile Consultant – but they can use that term with less confusion than me because they operate as independents rather than permanent employees.

I used to get a little hung up on what an Agile coach is, and be able to argue that because what someone did, or didn’t do, that they weren’t really a coach. This is especially true in the rather philosophical argument between the Scrum Master and Agile Coach role. Now I am increasingly of the opinion that the definition of the term Agile Coach is really in the hands of the employers. If they say that person is an Agile Coach, then by definition they are, regardless of what we in the industry think. This is in part due to the power of the recruitment industry and the market place remuneration benchmarks that come with it.

The role of the Agile Coach is becoming standardized in terms of activities, industry experience, skills and reward. We may not like it but the wider society appears to have consolidated around a position that an Agile Coach is a progression from Scrum Master. Of course, many in our industry influence what those employers think, but the most powerful in the industry trend to be those that sell Agile rather than implement it – ultimately selling themselves.


So am I an Agile Coach – I guess that is up to you to decide.

Personal appraisals in an Agile team, hmm…

Early on in any Agile transformation there will be people talking about teams, the 11th principle talks about self-organising teams. Now there are lots of recommendations and articles about what the team should look like, how big, what skill, and how to address team dysfunctions, even I have got in on this act here, and I am not going to go down that path now.

But once you have this team, ready and willing, how do you keep them fresh and motivated; and importantly for the parent organisation, how do you manage these people? It is trite to say, “they need no management, they are self-organised”. That is to wilfully ignore the practical realities of their context, which will often be within a larger organisation with objectives, hierarchy, annual reviews, performance management, training budgets, bonus pools etc. Whilst it maybe noble to preach that such practices are antiquarian and should be swept away in the birth of a new utopia… many people will look around them and hunker down, painfully aware that the second coming isn’t coming anytime soon, and when it does arrive, it will knock on their door last…

Given the constraints of reasonably standard HR practices, what can be done to ensure that the performance management practices support your agile transformation, rather than work against it?

What kind of people do you want working for you, and how can you assess people in such a fashion that the right type of people are rewarded and the development areas of each of them are identified? I really like this simple view:

People types

So how do you find your “Team Picks” – does your annual review process really highlight them?

Many companies have an annual review cycle which, with the best will in the world, suffers from both immediacy and confirmation biases. In other words, given all the information now available to me I will award you the grade that I was going to anyway, unless something dramatic has just happened. Consistent behaviour contrary to my preconceived notion, that hasn’t had significant recent impact, will be ignored.

To improve matters I advocate two practices:

  • Regular structured 360 feedback
  • Team based assessment

360 Feedback

Within teams, have each member give feedback on one other team member each iteration, on rotation. By year end there will be a comprehensive assessment of each person, where each contribution is from a different premise, and has only be focused on recent events. It turns the feedback collation activity from an “year end” exam into “ongoing coursework”. Making it a continual activity also means that you can start to consider it in the context of what it takes to sustain your team, ensuring that this process is as sustainable as your automated test approach or your technical documentation.

Having done this the only caveat I had to put in place is that each person was to be assessed at the end of the year on the quality of the feedback given, is it full enough, is it balanced, is it actionable etc, without this the feedback will tend to either mutually assured destruction, or a collective congratulation circle – usually, thankfully, the latter.

Team based assessment

Secondly, you can assess the team collectively, where the only individual measure is an assessment of how much effort they have invested in supporting the team. How “teamy” are you. How much focus have you placed on “teaminess” to use two invented words. (this is in addition to the individual feedback assessment mentioned earlier).

A team assessment means that the team either does well or poorly, they should celebrate success together, or share the learnings, usually a little of both. When your peer does something great, you not only feel good for them but they share that feeling with you, because they know that you had a hand in it somewhere. This collective identity is permissive and contagious, once it starts to catch on, it typically grows deeper. This isn’t to say that every piece of work is shared amongst everyone, that would be onerous, but that everyone is happy with everything going on around them and would be willing to put their name under it.

We are social creatures and the ways in which we interact with others is often more important to our ultimate success than any innate talent in a specific area. Practices and policies that reward positive collective interactions will be beneficial to the individual and to their ecosystem.  A team assessment will bring behaviours such as the most talented actively supporting the development of the least able and will help each individual ride out their own personal highs and lows. When you increase the sample size using an average, you will flatten out the peaks and troughs of success and struggle, and if you can get each team member to feel in line with the team, then you avoid any deep personal lows. Naturally you’ll also dampen the individual highs which might not be ideal for the person involved but can cause confidence / jealousy issues for their peers. In really mature Agile teams it is more than success that is shared, it becomes delivery, so at this point there is no individual high, because no individual acted or delivered without the contribution from their peers. This also helps avoid hero culture scenarios.


This type of approach really puts the hammer down on the kind of cultural ethos you are trying to promote and helps to show that you are placing equal emphasis on how work is conducted as much as the delivery result.


About me:

I am Phil Thompson, an Agile Consultant, have worked at many places in many industries and with many people, mostly in Europe, mostly in the UK, mostly in London. My opinions are my own, shaped and challenged by the people and companies I have been fortunate to work with over the past fifteen yrs.

You can reach me at @philagiledesign or LinkedIn

How company culture changes with product maturity

I recently attended a seminar with Kent Beck, a giant in the software delivery world, the father of eXtreme Programming. The topic was about the need to adapt our delivery approach based on where the organisation was within a growth pattern of, “Explore” to “Expand” and finally “Extract”. This progression was related to financial models: investment vs return, against risk.

3X diagramImage Credit to @antonyMarcano

The progression of the product connects to another standard of product theory, that of BCG’s Growth Share matrix which is a portfolio planning model used to divide up products on two axis, revenue generation and market share.

BCG Matrix

Credit @BCG

The progression from “Question Mark” to either “Star” or “Dog”, with the “Stars” finally becoming the “Cash Cows” (the dogs having been killed off along the way) is shown on the diagram. I believe the flow of “Question” to “Star” to “Cash Cow” is somewhat analogous to “Explore”, “Expand” and “Extract” and in both cases is a reflection of product lifecycle. What Kent Beck has explored is the consequence on organisational psychology in having products at the various phases.

In both models what is happening is a change of risk appetite, reflective of the changing balance between investment and return, and the consequence of failure.

I have merged the two ideas to make:

  • Exploring Questions:  Where we experience an unlikely very high return on low investment for a growing product with a small market share
  • Expanding Stars: Where we see a reasonable likelihood of a substantial return on significant investment, for a product that has a rapidly growing market share
  • Extracting Cows: (An unfortunate mental model) Where we see a very highly likely, small return on a large investment, for a product that is a stable market leader

Given this framework; Product development on Exploring Questions is typically undertaken in such small groups that the relationships between team members can be sustained without any process framework and the association between business and tech, between demand and supply, is so tight and immediate, that even most light touch Agile frameworks appear cumbersome. The best practices here are those that weed out the Dogs quickly, User Centred Design and Experience, fail fast experiments etc.

Most of the practices that we see in an Agile delivery I would describe as being suited to the Expanding Star world, rapid gains with constant feedback to ensure we on track. The key here is sustainable delivery, staying ahead of the pack. It is said that success is always a surprise, because if it wasn’t someone else would be doing it, and in this phase product development are trying to increase revenue and market share to ensure the idea, the surprise, remains theirs.

I see the Extracting Cow phase as markedly different, the risk profile and consequences of failure here are much more akin to traditional engineering disciplines. You can’t add decide to add a swimming pool to the 30th floor of a building after completing the first 28 storeys. Product delivery in this phase is much more likely to adopt frameworks and governance that avoid failure than aim for rapid gain, and we say hello again to our old friend Waterfall.

To use a different analogy, to see the changing behaviour against the consequence of failure consider the following epic conflicts:

  • In the novel, “Lord of the Rings” you have a plucky few to take on an uncountable near unstoppable foe, with a slim chance of success but a massive return of saving the world. They are gung-ho in their exploratory approach making it up as they go along. The consequence of inaction is fatal. They have everything to play for, and in the scope of middle earth, not a lot to lose.
  • The Roman Empire between 150BC and 50 AD, had one of the finest fighting forces on the planet and certainly superior to anything nearby. The gains from conquest were substantial and the likelihood of victory high which lead to an enormous expansion. They expanded because if they didn’t someone else would, they didn’t risk losing what they had, they risked losing the opportunity for more. They were systematic, organised and effective. Their only downfall was the sustainability of holding onto the new territory, grow too far, too fast and the cost to operate without sound investment can exceed the returns, and you fall.
  • In the 1983 film, “War Games”, a computer responsible for nuclear war simulation eventually accepts that the only viable course of action, is to take no action. The only winning move is not to play. The consequence of failure is too great.

For an Agile Coach it is important to understand how this product evolution impacts on our ability to work with organisations. How the mindset shaped by the product lifecycle stage transcends the product, and comes to dominates the parent organisation. Typically small fast companies grow on the back of a successful product and become large, risk adverse corporations. It is as if each company has one product and slowly changes their organisational psychology to match that single product’s evolution. Facebook changing its motto from, “Move fast and break things” to, “Move fast with stable infrastructure” is a clear example. If a company was structured along product lines then it would be reasonable to expect that the area owning an Expanding Cow would be slow and reserved, whilst an area associated to an Exploring Question to be fast and dynamic, but that isn’t the case.

What happens is that the organisation “matures” with its first product, loses that innovative capability and is trapped either trying to innovate within a highly constrained system or not innovate at all – innovation becomes a timid extension of a secure product. In an attempt to reduce risk, a mature company typically chooses to split out certain components to specialists, silos are created, technical component teams propagate, swathes of middle management appear to ensure that nothing goes wrong – and stagnation sets in.


At this point an organisation in this state, paralysed and inert but still sustaining huge revenue, many consider an Agile transformation as a possible route out. Many coaches work in this environment – and most find culture the biggest barrier, most of the Agile practices are not suited for this risk adverse mindset, many Agile coaches have cut their teeth in Exploring Questions or Expanding Stars and are lost in the face of the corporate governance of a gargantuan Extracting Cow, the frustration has prompted so called “Scaling Frameworks” to appear which ape agile values while remaining compliant to the NOT SAFE TO FAIL, siloed environment.

But should the main focus of delivery even be happening there anyway? Back to BCG’s model; Cash Cows should be milked, extracting profits and investing as little as possible. The cash that is derived should be used to fund the next set of Questions and to propel those Stars. Are the mature organsiations doing this? Aren’t they all too often ploughing the cash from their Cows back into their Cows, costing a lot for low return? They hold their market share though economies of scale and the value return on effort spent, is often so low that they deliberately choose not to measure it, so as to not own up to their wastefulness.

I believe large organisations with mature products need to have a strategy that focuses on introducing exciting new products funded by revenue from their established ones. The investment should be high in the growth areas and cut to a minimum on those products that have reached the Extract Cow level. Whilst it may be prudent to have a risk adverse approach to the operation and maintenance of the Extracting Cow, that mindset, those organisational dynamics, MUST NOT be replicated in the other product development areas.

Extracting Cows die, eventually. There are plenty of case studies of huge products that have ceased to exist, some have taken their parent companies with them, some haven’t. The BCG work has shown that for companies to survive the death of an Extracting Cow they must innovate, diversify their product portfolio, use the revenue of their Extracting Cow to fund their next set of Exploring Questions, with a few being successful. Invest in tomorrow, rather than hope that today will never end. Kent Beck’s work helps us to understand that the organisational approach across the portfolio needs be variable. Through combining the two I believe it is not sufficient to diversify your portfolio, you must diversify your approach and governance, maybe even culture to match. For your Questions to become Stars you need an Explore based mindset and approach.

Organisations need to reinvent themselves, not just their product offering, in order to survive; the mindset and governance honed to operate and maintain a mature product is an impediment to discovering its replacement.


About me:

I am Phil Thompson, an Agile Consultant, have worked at many places in many industries and with many people, mostly in Europe, mostly in the UK, mostly in London. My opinions are my own, shaped and challenged by the people and companies I have been fortunate to work with over the past fifteen yrs.

You can reach me at @philagiledesign or LinkedIn


It is a matter of opinion


Pick a contentious topic, Brexit, Trump, Climate change, religious extremism or even the merits of Justin Bieber and the chances are you have an opinion. In the IT industry there are many contentious issues, Agile, Scrum, Emergent architecture; all emotive topics that are filling up the comments sections of blogs all over the internet. But what makes your opinion right and what makes other believe it?
For your opinion to be “right” your hypothesis should logically fit the situation, and that really means YOUR understanding of YOUR situation. Our context, environment and relationships are what shape our understanding of a situation; two people in vastly different situations can correctly hold widely differing opinions on the same topic, because to each of them, their hypothesis holds true in their environment; “Behaviour is a product of practices in a context” (Dan North).

This approach supports the neat little adage that opinion is a matter of perspective. We should go one further, opinion is a PRODUCT of perspective. When we wish to debate between opinions there is no merit in focusing on the opinion itself, that is to try to deny the rational logic of localised cause and effect, instead our attention should turn to the perspective, to that person’s context in which the opinion has been formed. “Understanding context is important before you draw any conclusions” (Dave Snowden).
Someone’s opinion that, “everyone that voted for Brexit is a racist” could be formed if they have heard a number of people state they are for Brexit using racist terminology, and critically they had no contact with other Brexit voters that did not express such ideologies. Supporting opinions is data, here the data is, ‘the number of non-racists encountered that support Brexit’. Edward Demming alluded to this in his much quoted line, “Without data you’re just another person with an opinion”, which Jim Barksdale, former CEO of Netscape neatly expanded with, “If all we have are opinions, let’s go with mine”. The point here is that you can’t argue with the opinion, the argument has to be taken with the data that underpins it. There are millions of people that believe what Donald Trump says about the Washington establishment, because they have no contrary data.
Critically, to form the most educated opinion, the best opinion, we should seek out data from as many disparate contexts as possible, we need to consciously seek to put ourselves in other people’s shoes, something we don’t usually enjoy and hence rarely do.
Now here is the really challenging point for all of us that hold an opinion: if we agree that opinion is a product of perspective, and perspective is a function of our context, then we accept that our opinions will change if we change our context.
If I change your context, you will change your opinion….
Stating that your opinion won’t change on a topic is to state that you will ignore new data that would logically draw a different conclusion. To say you will never change your opinion on something is to be a zealot. To hold a position based on faith, dogma or belief is to deny rational logic. This is quite a problem today where changing opinions are seen as a function of weakness not learning. An “expert” that changes their opinion will have their “expert” status questioned or derided, even though it is their expertise that has enabled them to learn more on a topic and be open to drawn new logical conclusions to their now wider data set.
This can be seen in the Dunning Kruger effect, as people’s experience grows, so does their exposure to differing contexts and there will be a point where people have started to change their opinions, and being aware that they could change further, are less likely to forthright about them. Do not trust the Agile coach that states operational process changes without seeing the teams at work, it belies a narrow contextual exposure.
Our society is becoming increasingly polarised, many have used the term ‘post-factual‘. This is a reference to widespread opinions that are unaffected by new data. Our opinion  strengthens when we receive new information that aligns to our existing data and weakens in the face of contrary data, although we have a tendency to favour the status quo. We all suffer from confirmation bias, where we will disproportionately listen to information that supports our ideas, but it can be overwhelmed, we also have varying levels of trust for data sources. So for opinions to be unchanging, it means that information being received by people is sufficiently supporting their existing context  so as to suppress any contrary data, especially from untrusted sources. Of course, which data is trusted is an opinion itself…
The problem is that we seek out the company of likeminded people and increasingly our human relationships are being sustained through social media which is underpinned with algorithms that prioritise interactions of demographically similar people, because that will generate more content/revenue. This means we are increasingly exposed to a defined subset of data, separate groups of people consistently reinforcing their opinions with separate datasets. This is referred to as being in an Echo chamber.
Echo chambers are dangerous because they are comfortable. It is reassuring to be surrounded by people that agree with you and you become blind to alternative contexts. Echo chambers are where innovation dies due to lack of disruptive challenge. They are invisible ideological prisons.
We need to constantly challenge our opinions; be open to the fact that they will change and be open and honest when they do. Seek out different perspectives, speak to people who don’t agree with you and try to understand the situations that they find themselves in. Be measured when giving your opinion and support it with data to help others to understand your perspective. Strongly asserting unsubstantiated opinions rarely achieves anything , either you are speaking to someone who already agrees with you, or someone that can’t understand you.

What’s your opinion?

About me:

I am Phil Thompson, an Agile Consultant, have worked at many places in many industries and with many people, mostly in Europe, mostly in the UK, mostly in London. My opinions are my own, shaped and challenged by the people and companies I have been fortunate to work with over the past fifteen yrs.

You can reach me at @philagiledesign or LinkedIn

Agile is consuming itself

The biggest threats to wholesale agile adoption within our business society don’t come from a counter proposal, they come from within. The failings of previous approaches are well known and well documented and in fact have been since their inceptions, but everyone muddled through for lack of alternative. There isn’t going to be resurgence in support for the “Good old days”, too many people can prove it wasn’t that good. Nor do I imagine a new way, a utopian enlightenment to dawn upon us, from which point all programme delivery becomes risk and issue free, there just aren’t sufficient unexplored paradigms in our approach.

If the agile movement is to die, to collapse, it will do so inwards, on itself and from within. It will suffer the fate of Robespierre, the French revolutionary who rose to power through a fervent belief in equality and support for those that had been excluded and repressed under royal tyranny. His passion and success made him increasingly blind to the consequence of his unyielding beliefs and the presence of those that coveted his position. Eventually those that would usurp him turned the populace to revile the fanatical dogma that had wrought so much terror in the name of social progress, and he met the same end that he had brought about for the late king, a short drop from Madame Guillotine.

I suggest the dangers lie in three areas, the ignorant, the exploitative and the manipulative. In all cases the issue is misinterpretation of sound decent values, either innocently or more malevolently.

The first case is ignorance. This is a hard truth I had had to admit to myself, and I am reassured to read postings from other thought leaders I admire, who have humbled themselves in a similar fashion – see here, that has given me the confidence to come clean. Years ago I probably was this person, the well-intentioned but ignorant zealot; armed with too little understanding or experience of Agile Values and human politics, and too much theory and process definition.  I was that guy howling into the wilderness standing on Dunning-Kruger’s mount stupid. You’ve may relate to these kinds of transformation attempts; process and terminology centric backed by dogma and rhetoric that is applied through contextless retrospective coherence. Trying to change behaviours and practices through process, like trying to turn the quiet shy girl at the back of the class into the lead cheerleader by tossing her a costume and couple of pom-poms.

The second case is where the revenue generation consequence of those talented individuals working in organisations to support an agile transformation becomes a motivator for themselves and others. When the Agile philosophy becomes a commercial opportunity, then predictable but none too pleasant behaviours start to emerge. Pyramid style certification schemes, and an attempt to commoditise processes and supporting tooling for the purpose of revenue rather than stakeholder value. The worst excesses of this can be seen in those offerings that do little more than relabel existing familiar enterprise operations with new “Agiley” terminology with a supporting license fee. This undermines the Agile principles by dragging it down to something much closer to the status quo for the purpose of profit.

The last case is the most dangerous, those that speak in our name to further their own agendas. The butt of many a Dilbert joke – “Welcome to Agile – stop documenting anything and now you can work faster”. This is the wrecking ball of Agile, or more usually Scrum, wielded by paranoid power-hungry, non-technical managers who feel they now have a weapon to use against their intractable, awkward IT colleagues. Teams have been made to work longer, harder, with less control, fewer standards and more interference all in the name of Scrum. New developers have been born into this environment and are left believing that this is normal, and the more experienced developers resent the dumbing down on their industry and rage against the framework because they are powerless against their management. There are hundreds of comments on blog boards of people decrying Scrum through valid complaints about business practices that bear no resemblance to Scrum.

Now imagine all three together, well-intentioned but ignorant scrum masters being manipulated by untrusting and overly ambitious management to deliver the impossible, at the expense of the developer workforce, being cheered on by a process, tooling and certification industry laughing all the way to the bank. The end result will be a profitable industry of failing projects and people in a slightly different way to twenty years ago, and critically no real improvement in the enterprise project success rate.

So what is to be done? As a consultant working on Agile Transformation; are we like a few conservationists, trying to save what is left with the grim knowledge that it won’t be enough against the rampant consumerism, selfishness and apathy of humankind?

We have to continue, to give up would be dereliction of duty, and most of us have skin in the game ourselves now, we are part of the problem even as we try to point the finger elsewhere. Firstly we should point out misrepresentation of Agile wherever we see it. We need to stop preaching and learn a little humility, for those that teach Agile theory and concepts end each class with this statement – “you now know  a lot less than you think you do and are now capable of a lot more damage than you can imagine”. For those that are working in environments that are Agile in name only, then call this out, transformation to Agile may be beyond your means but at least stop calling it Agile so as to not further tarnish what was once a noble ideology. We need to focus on delivering value, on return for our clients not for ourselves. Be honest and ethical about the contracts we take and the companies we work for.

I like the proposition that someone attributed to McKinseys (I don’t know if correctly) that we should focus on delivering value to our clients rather than to ourselves and through that the money will flow anyway.

About me:

I am Phil Thompson, an Agile Consultant, have worked at many places in many industries and with many people, mostly in Europe, mostly in the UK, mostly in London. My opinions are my own, shaped and challenged by the people and companies I have been fortunate to work with over the past fifteen yrs.

You can reach me at @philagiledesign or LinkedIn