Agile types within the community?

Over the last few years I have been undertaking some action research around Agility and what we might possibly mean by the claim of an ‘Agile community’? Are there, like most other professional/social communities distinct sub-communities? Can we trace or recognise smaller grouping(s) that seek to collectively make sense of the notion of ‘Agility’ in its broadest sense? And does this naturally mean that Agility is understood in different and even competing ways? And, if so, how can we, and do we, make sense of that multiplicity of meaning-making, for want of a better term? What method lends itself to understanding?

One approach I like is that proposed by Carl Jung and his use of ‘types’. This is a first-class resource for those wanting to read/study a little more

Stated simply, Jung made the claim that humanity share a collective unconscious. Our collective unconscious was inhabited by a range of characters that he called archetypes. I guess then, I am wondering if these characters are shared symbolically by the agile community? Can you recognise any of them? Do they resonate? We each then using this framework can be ‘activiated’ by an archetype and act-out in the ways described. Of course, this would be unconsciously, rather than consciously given the nature of an archetype. What types can we recognise?

On Method
Following quite extensive individual and small group interviews; and then reading primary and secondary resources, I think I’m in the position to postulate the following typology. I have attempted to condense the complexity to a rather simplified 4 core types, but of course, I am in the process of making-sense of my own, rather limited, direct lived experience. There are therefore, I am certain, more that can be re-searched and shared, expounded and I hope, in a life affirming manner, debated too.

For each of the 4 types I have attempted to analyse sameness and difference. I’ve also looked at some of the main metaphors that resonate for each type. Next I’ve looked at some of the main ways by which they tend to ‘act-out’ in terms of power-relations. Lastly, I’ve examined some of the unconscious ‘shadow side’ of the types so as to provide psychological space for humility, reflection, insight, and possibly more self-awareness.

As I write that last sentence I make the candid declaration that I am a ‘flawed human’ with a need for my own ongoing ‘inner work’. I am grateful for my coach, mentor and friends to this end.

What are the 4 types?
I have carefully traced the following 4 types:
• The Radical
• The Reticularist
• The Retro
• The Romantic
I’ll address each in turn and then a short summary table for ease of reference etc.

The Radical.
With the Radical type of character there is an inherent impatience with the rate, or pace, of progress. If their dreams were actually realised; then there would be a massive, unmeasured and rapid change to their ‘way’. They seem to desire an over-idealised Agile image that forever seems just ‘out of reach’. Consequently, their preferred modus operandi is the on-going challenge, the critique. This is what Cooperrider refers to as ‘the deficit model’. They have ‘weapons of mass destruction’ and they are willing to deploy them if deemed necessary. Their preferred metaphors for Agile teams are ‘squads’ based on a military/conflict model. Thus, they speak and think in terms of war; fighting; and competition. For them to win then others must lose on their imagined Agile ‘Crusade’.

Their psychological narrative is binary: good/bad; in/out; friend/foe. They prefer in-groups where all the members share their future ‘end game’ when, presumably, they have ‘won’ and anyone that does not share their own (rather narrow view) of organisational Agility has lost? Thus, Agile ‘coaches’ caught-out by this character might spend over 80% of their time, energy and persuasion on ‘challenging the status quo’. As you might have guessed the Radical struggles with multiple, competing interpretations of reality. Thus, he sees things in a single-minded manner. They are very stubborn and fixed.

Of course, there is as with all types more positive aspects to this type. They have deep personal resource ‘wells’ of energy, resilience and massive drive. This role can be seen in some circles as a ‘necessary mavericks’ and by a smaller number as ‘heroes’ taking forward and representing the Agile cause with ‘passion’.

When things are not moving as fast as they deem realistic then their impatience reveals their shadow-side. This shadow-side includes all the military undertones of actual warfare: propaganda, guerrilla attacks, and psychological injuries. Next, given that they often have strong group boundary norms they can be given-over to darkened shades of group-think. The advice? To keep this in check this sub-community would do well to keep connected with other sub-groups and more especially the Romantics. (NB:- They would need to be careful with the Reticularist as the latter may simply be seen as an ‘intelligence source’ for their next ‘campaign’).

The Reticularist
I’ve blogged previously around the role of the Reticularist. Stated simply, the Reticularist is sometimes referred to as a ‘boundary spanner’. This Agile archetype is a ‘whole systems’ actor, thinker and planner. Therefore, within the organisation (and more especially the IT department) she/he is seeking to understand work flow. Questions arise such as: How does work flow through the organisation from product conception right through to the release stage? Where are the blockers to flow?
With whom do I need to make allies with and, quite literally, ‘see’ work from their perspective in an appreciative way? The Reticularist seeks to co-create with others incremental improvements to flow, and so share successes across teams.

The guiding metaphor for them is an organic or ‘living’ system. This is because such systems move, change, shift and therefore, new patterns emerge from the interactions of the parts. In this way, the Reticularist is a collaborator par excellence as they act on and with the ‘edges’ of different interfacing teams and departments. As an example: If product releasing is a current challenge- then a collaborative group would seek to co-create a solution.

Whereas for the Radical the temptation would be to challenge and then release the product from the direct Scrum team and then more simply watch and ‘see what happens’ which could well include fall-out and tensions…the Reticularist would systemically foresee the tensions arising from such unilateral decision-making and seek to circumvent it via a more collaborative method (e.g. a small cross-group experiment).
The shadow-side for the boundary spanner is gossiping. This is because when you are seeking to understand all the ‘parts of the whole’ of necessity this means engaging with the teams within those parts.

Consequently, there is a genuine risk of information-sharing for understanding in transit/translation, losing its ethical value, as gossip. The downside of gossiping are likely to include damaging trust, as well as negating possible future relational reciprocity. To mitigate this risk, one ought to state one’s own intentions for Agile improvement as the contextual discussion background. Thus, you cannot be ‘all things to all people’ if this means in professional practice you are left without any ethical ‘grounding’ from which others can evaluate you intentions for good or ill.

The Retro.
According to the online urban dictionary the Retro is a ‘contemporary style containing elements but not the replication of a previous era’. Thus, there is a sense of looking back in time or history, for the Retro. They hold in especial respect and regard the ‘Founding Fathers’ of the Agile movement. The Retro often have applied longevity with the application of Agile methods in various types of organisations. Many of them are seen as current leaders themselves. A smaller sub-set have taken the opportunity to incrementally develop, refine and market new tools, techniques and methods. The Retro has a deep and genuine sense of respect for the ‘Giants of the Past’. They will have taken the considered care and time to study their words and often memorised their key concepts and suggestions, and applied them too.

Whereas for the Retro there is respect and even reverence for the Founding Fathers this is often at the business or logical level. The Retro deeply understands marketing, branding and profit margins. This can be contrasted with the Radical as the latter actively seek to challenge the ‘Old Timers’ for even better methods; innovative breakthroughs and new models.

The shadow-side for the Retro is most often witnessed by a degree of arrogance, pride and a somewhat ‘closed mind’. Therefore, on many dimensions the Retro can be contrasted with the Radical. Whereas for the Retro ‘wisdom’ is a core value; for the Radical disruptive innovation is of a higher need/value. Many current and previous Agile community arguments can thus be framed using this interpretative lens or schema.

The guiding metaphor for the Retro type is honouring the wisdom of the collective past as incremental improvements are made moving towards the visionary future. The future vision, of course, would seem consistent with the Founding Fathers, whilst accepting and even celebrating a sense of building on their foundations.
Key words: vision, values and wisdom. In terms of power-relations the Retro views power and residing in the empirical evidence-base underpinning their Craft. Therefore, they look back to the philosophical Greeks not just for wisdom; but also for their technical Craft or techne. They are keen to learn the ways by which to persuade, cajole and bring others along in a relatively harmonious way to a more Agile organisation.

The Romantic.
For the Romantic type the Agility journey must engage meaning. It is essential for the Romantic they can see their role and the ways by which this is connected to the Agile journey for the organisation. For the Romantic, Agility has everything to do with increased job and team satisfaction; a more life affirming and innovative work-place. Whilst they appreciate all the empirical data ‘under the sun’ such as: efficiency, effectiveness, productivity and outcomes; the Romantic longs for something more: meaning. Therefore, and this is very important their emotions must be engaged.

The Romantic will have emotionally internalised the Scrum values, for example, and seek to work and be ethically guided by them as part of their working intuition. They may even internalise them as self-embodied values within other areas or life domains. Thus, they will enjoy experimenting with agility in their personal lives. Thus, when these values are ‘crossed’ there will be a deep sense of disappointment and even shame and regret. The Romantics are therefore, captured by a participative ‘Mission’ that must have an ethical sense of direction.

The Romantics are looking to carefully, and at times, patiently build the ‘Agile City set on a Hill’. Given their need for emotional connection and meaning; when senior leaders fail to make their connection for them by organisational discourse, metaphor and mission statement the Romantics symbolically (and perhaps in reality) ‘lose heart’ and they consequently disengage. The Romantics are deeply connected, on an emotional level, with the ‘Founding Fathers’ and they are seeking to be as true to those initial values as the Founders were. Respect is a key word in their psychological lexicon. Indeed, they are less interested per se, in new ‘brands’ or emergent markets, but rather to co-create new idea, and to solve new problems if and only if, they are underscored by the correct set of values.

Their shadow-side is revealed not be naked resistance (as marked-out so obviously by a Radical), but rather, by ‘going through the motions’. When the shadow falls over the Romantic they somehow seem emotionally ‘hollow’ to their team mates and wider colleagues. It is this sense of an accompanying emotional numbness that psychologically signifies the denial/rejection of things that really do matter (deep down in their soul) to them.

In this blog I have sought to explore and understand the notion of an Agile community and posited that there might be a number of Agile sub-communities. Why? I have done so in the hope that by articulating the ‘contested space’ of Agility that more harmony, collaboration and legitimacy can be taken-up by different ways of living and indeed being Agile.

It is beyond the scope of this current blog to work through how many of each type are the optimal ‘mix’ given any organisational agile journey. I would imagine that the organisational culture is a key factor?

Jason is a Certified Scrum Professional. He is also a Business Psychologist, as well as a full member of the Association of Project Managers.

Agile Testing: The Test Flight.

There is something really #Agile about the ways by which this successful and very extreme testing resonates with me as a Scrum Master and Certified Scrum Professional.

This film is worth watching as you can see and hear the ways by which Boeing test pilots have subjected the new 747-8 Freighter to extreme testing.

Watch and you can see, hear and experience the ways that the plane has been dragged, dropped, soaked, forced to hover, shudder and flutter. This testing has costs millions of pounds. The testing takes the plane to the most extreme limits of what is to be expected when in the real world, or in software terms, the ‘live environment’.

Interestingly, there are a number of  what in software development we call ‘negative Use Cases’ such as deliberate stalls and flutter tests. The testing from what in Agile we call beta testing. Way before live!


It might be worthwhile where I am ‘coming from’. I work in the civil service and we have this fab team at the GDS that undertake the research and shape policy so that we can be the most effective in delivery. To this end, we are all Agile teams most of us use Scrum, Kanban or Scrumban.

Government Digital Service: UK Policy

Beta Outputs

Notice the similarity with the testing of the plane and the UK Government policy around what constitutes the end of the beta phase:

  • delivered an end-to-end prototype of the service (including SIT, stress and performance testing)
  • a collection of prioritised work to be done (your Product backlog)
  • a user testing plan (UAT)
  • accurate metrics and measurements to monitor your KPIs (given the above for performance, stress and integration)
  • fully tested the assisted digital support for your service
  • a working system that can be used, for real, by end users

Because it is an #Agile design notice that component testing, performance, load, stress and continuous integration run all the way through the software product lifecycle. We would also ensure a full regression test at the end of the cycle.

This is because we want to identify and fix any bug as part of continuous agile improvements and not wait until the end of all the software development has been finished and have a large ‘testing phase’ at the end delaying delivery and be reliant upon a small team rather than having those skills (and availability of automated technologies) in each and every Scrum team.

Once you have this concept, then notice the shift as we Go Live:

Going live

To provide a fully resilient service to all end users the service should now meet all security and performance standards. You have configured your analytics to accurately monitor the key performance indicators identified in the building of your service.

I write this in the hope of looking forward we can get a deeper sense and appreciation of the fantastic ways by which Agile (when understood and implemented properly) ensures the highest quality. It also ensures the most effective use of resources and flexible responses to feedback from customers- this ensuring that time, quality and costs (the ‘holy trinity’) are maximised.

Take care Jason



Fixing the project deadline: Agile choices.

There are legitimate reasons why a project would need to have a fixed deadline and although the Agile community would rightly counter this with a range of sensible reasons why you might want a more flexible approach, on occasion a fixed deadline is a non-negotiable contractual characteristic.

What is fascinating is that Scrum, as a method, seems to me to be more effective when there are relatively known quantities (such as Requirements or Features) and then during the course of a number of short iterations and shipping of completed and usable/working code empirical comparisons can be made between expectations and actual. Of course, we can make this comparative analysis between actual and forecast costs in both types: capital and revenue as part of budget analysis.

One of the headlines that grabbed my attention this week was this one:New British Airways direct flight from London Gatwick to New York’. This is good news for those of us that have friends, family and colleagues in New York. It is fair to say that the BA have turned the proverbial corner with the latest fiscal analysis suggesting that AG (the firm that to all intents and purposes own BA) have reported a 25% rise in profits to a new level of some £315 million for the 3-months (quarter) up to 30th June 2015. This is an impressive set of business results.


Chief executive Willie Walsh told the BBC that the impressive changes to the airlines operating model highlighted the “underlying strength of the airlines” which is encouraging.

But what about agile working? How does this fit? Does it play a part?

We need to go back in time to make sense of the Agile change. Back in 2009 BA were facing a horrendous situation and the time for tough and testing decisions to be made. At that time BA CIO made the statement that both “lean and Agile as part of continuous improvement will help us beat the downturn”also expressed as the global recession.

BA then cut around 2,500 jobs in 2009. It then addressed an outdated operating model that was fit-for-purpose historically, but was found ‘lacking’ in these new and testing times. Interestingly, in 2010 Paul Coby, the CIO when addressing a business conference in London made the following key announcement and observation “We need smart innovation and smart change leveraged by technology. Lean and Agile are becoming key enablers”. Notice that back in 2010 and then read again the rise in 25% quarterly profits. There is something close to prophetic in Paul’s words. #leadership.

But what of the staff that had to be re-trained, coached, and deployed in Lean and Agile methods. A few years later the new Head of IT delivery, Mike Croucher made two observations of their journey of transformation that created a more flexible, agile and successful business operating model enabled by IT:

“The first thing I’d point to is the value that we’ve driven for the company, because that’s the reason why we’re in business.

And the second thing is the way it has motivated many of our people in IT. Some have said it has changed their lives.” #changedlives

What many people are less aware of is that BA typically run fixed-term projects of around 6-months. This helps co-ordination as well as ensuring that the ‘time-boxed’ Sprint philosophy runs all the way down into the governance framework and light touch paperwork across the portfolio. #light:tight

In this way, the maximum business value and wider benefits are the central discussion point. The Agile team via the Product Owners prioritization of the Stories are focused on value. Let’s get the maximum value or return on our investment (ROI). Release management is a little easier to co-ordinate too. This has built confidence in Agile across all the business units and within the wider culture.

Can you imagine the conversations that start with: How do we maximise the ROI? That is an exciting place to contribute… that’s where the edge truly is.

I enjoy those conversations in my own work-place. I’ve witnessed the changes in behaviour, attitudes and collaboration when conversations are ‘framed’ in this way. From the largest Epic down to the smallest and elegantly sliced Story let’s ensure ROI is up front and central. Agile is all about value. And if we need to fix the deadline to help our thinking then let’s do just that.


As this important case-study has demonstrated having a fixed project deadline can be a successful methods for implementation and co-ordination for IT transformational programmes and projects.

Take care Jason

Business Agility: What’s the added value of Senior Management Coaching?

The role of senior management in setting the business strategic design, development and implementation is well researched with a firm evidence-base. What is less well-known are the ways by which cultural change is enabled by coaching when it comes to a stated aim to become ‘more agile’.


Thankfully there are resources which add insight, challenge and case-studies from which we can learn. But before that it is worth briefly stating the subtle difference between an espoused value and an actual value. In the past I have worked in organisations were there is a total contradiction between the two which creates all manner of professional headaches. Consider a healthcare provider claiming that they genuinely care for their patients; and then receive patient complaints and feedback that in reality they are consistently rude, dismissive and unkind.  That’s a contradiction.

I’ve also worked in organisations where there is a distinctive, but more of a degree, of difference between their espoused and lived values. For example, several years ago one organisation claimed that our people are our most valuable asset and yet their staff satisfaction surveys were in the lower quartile of their industry benchmark. In this case, there was an organisational development programme to ‘close the gap’ between the desired and actual state. This, to be fair, is not uncommon. It is why cultural transformation for genuine practitioners takes time. There is no ‘quick fix’.

But what of agility? There is little doubt in my mind that agility might well be, or yet become, another management fad or fashion. There are several reasons for this possibility, and I will address one. In a previous blog I have looked back and traced various management ‘fads and fashions’ as well as shifts and movements in management theory, practice and aims. I will not be repeating that analysis in here. However, just to make the point that a stated aim is not reality. Cultural analysis aka Edgar Schein (1987) makes the point that one of the key points of analysis is the actual business policies, practices and staff attitudes.

How do we go about improving agility? Having trained Scrum Masters and teams is without doubt a significant investment with identifiable and quantifiable returns. That’s one key intervention.

The next has to be senior management as their role (leadership) as key ‘influencers and shapers’ of cultural change has, in my professional experience, a three-fold impact when compared to team investment alone. Yes three-fold! If you are looking to increase understanding, practice, pace and collaboration across all business Divisions or Units-then this is an intervention worthy of merit and serious consideration.

(If you happen to be a public sector organisation then I’ve also had a Non-Executive Agile Lead. This is also a good idea. It can complement the Coaching).

But what of the leadership coaching approach? What are the leadership behaviours? Thankfully, there is a first-class resource by Brian Wernham that has, through careful and considered case-study research, identified a set of 9 leadership behaviours that can add value to any Coach.

I have found these to have face validity and genuine added-value practice. Well worth a serious study and reflection. There is also this fab webinar that the APM invited Brian to discuss some of his key ideas in:-

So if you are looking to ‘close the gap’ between your strategic values and your current business operating model/practices what is stopping you? Is it time for senior management Coaching?

Take care Jason


Jason is a Business Psychologist, Scrum Master and Registered Project Manager.

Minimum Viable Product: Ignoring the Call of the Sirens

One of the most fascinating stages for any Agile product is working through what constitutes the Minimum Viable Product (MVP). 

It seems to me that all three signifiers, or words, have equal weight or importance. The process determines or ‘locks in’ at least for a point in time that which makes something of sufficient substance that we can recognise it as a ‘product’ per se.  Next the analysis concerns itself with what the minimum number of features the product has so that from a market perspective we can successfully have a product to release or take it to the market as part of a new product launch. Finally, the second term the viability becomes critical in at least three ways:-

  1. In terms of our market segmentation strategy and market research this meets or fulfills our customer demographic needs
  2. If for an internal customer, or business unit, then in a similar way- the product needs to meet a similar set of needs- at least for the point in time for the Release date (as by definition later releases will meet future needs that may well change, emerge or become redundant as a function of time)
  3. Finally, viability has a keen association with the business case. The latter will normally have the ‘golden triangle’ of classic project management tools and include analysis around time, quality and costs.

What can we learn from depth psychology? I’ve pondered this recently and think that there are some lessons from the Odyssey (Homer) and in particular the episode with the gorgeous Sirens.


You may recall that the poem centres around the hero Odysseus and his long-winded adventure and journey home after the battle of Troy. On their way home his skilled and brave crew are faced with mortal danger in the form of beautiful women called the Sirens. The Sirens lure sailors to their deaths by a fatal combination of the most enchanting, beautiful and hypnotic songs as well as their gorgeous beauty. They were seen as daughters of the god Achelous.

By their physical beauty, and melodious songs they, if successful, get the ship to change direction and shipwreck on the rocky nearby coasts. Thus, to this day, the Siren song refers to an appeal that is hard to resist but that, if heeded, will lead to a poor or bad conclusion. It is it seems an ‘irresistible distraction’.

Thankfully in our myth, our hero was fore-warned of the Siren call and consequently (and very wisely) strapped himself to the mast of his ship. He then ordered his crew to use wax in their ears so that they could not be seduced by the Sirens! No easy task! To be fair, the sailors obeyed and as we now know by looking back that this was a set of wise choices in such demanding circumstances! Thankfully, it all worked! and they were able to sail on despite the ‘distractions’.

This speaks to me in the following three ways:-

  1. After we have completed our market research we must be as wise as Odysseus and keep our eyes fixed on our objective asking carefully and wisely if each feature meets the litmus test of all three signifiers in the MVP trinity
  2. Next, we must paradoxically ‘resist the irresistible‘ and this ensure that we keep pace with our own progress and be careful not to be distracted by any external, or at times, internal ‘Siren call’s’ even though they may be beautiful features
  3. Lastly, as Scrum Masters we need to work alongside the Product Owner, in particular, and if need be ‘fasten him to the mast‘ and so ensure the safety of the project team.

Take care Jason


‘Lessons to be Learned’ is this anything more than a rhetorical device?

You might recognise the picture above as a human neural network. This is the miraculous or amazing ways by which the human brain disseminates information that we all use to make sense of our external (environmental) and internal (psychological) worlds. I believe that this is a useful metaphor for learning at a number of levels, including individually, team and organisationally.

This blog is all about learning. But the motive behind writing it is all about relieving pain, upset, misunderstanding and disappointment. Consider the following scenario:

A loved one is treated poorly by a provider of care/ treatment. This results in serious harm or death. Given the seriousness of the error an external review is completed taking several months. Consequently a comprehensive 157 page report is produced. The same day this becomes available a press statement including the phrase that we all recognise instantly: “The organisation accepts the reviews findings and acknowledges that lessons must be learned” is given to the national, regional and local media.

Even though several months have passed for you the associated emotions remain raw or visceral and there is this sense of an injustice. You are energised to do three things. Firstly, you read carefully all similar reviews of the same type of error over the last 10-years. Secondly, you ask the organisation to demonstrate the ways by which they have implemented the ‘lessons learned’ from these previous reviews that you have found. Lastly, you informally ask friends that work in that organisation in what ways the ‘lessons learned’ from these reviews has shaped their professional practice over the last decade.

It is an obvious point but worth exploring none-the-less, what difference will it make to you if you discover that very little genuine learning has taken place? And, of course, if you discover that learning from previous reviews has indeed re-shaped professional practice and informed the ethical culture of the organisation what difference would this make to your sense of justice/injustice?

Around 7-years ago I was asked to review (yes me too!) and then design and implement a learning architecture that would address the points that I have outlined above. This is roughly what we co-created.

As a matter of interest this was within healthcare, but as I said before I believe the design features, or principles, could be applied in most organisational contexts such as banking/finance, IT, social services, foster care, schools/education, and the military, and the voluntary sectors such as charities and churches.

We mapped the following key learning building blocks:-

  • Insights from International, National Reviews
  • Learning from other external Reviews
  • Learning from Organisational ‘near miss’ events (logged)
  • Insights from Programme and Project ‘Lessons Learnt’ reviews/ evaluations
  • Learning from Conferences and other CPD events
  • Team Based Learning
  • Individual Learning (PDR)
  • Communities of Practice (Professional)

With bi-directional information and learning ‘flows’ we anticipate the following direct outcomes and wider systemic benefits.


  1. The rate, or pace, of learning across the network ‘nodes’ should increase over time- given that we have specifically “designed-in” the learning connectedness
  2. There should be some correspondance of learning from each ‘output’ to the relevant learning ‘input’. In this way, we can see that any relevant learning from say a specific project review/evaluation should expected to be found, in say, the ‘community of practice’ for programme/project managers
  3. The same of course, could be said for any professional such as nursing, teachers, investment bankers and so forth
  4. Consequently, the knowledge management skill par excellence- is extracting the right degree of learning granularity from each knowledge input to each learning output


  • Having professional ‘communities of practice’ connected to learning knowledge management will enable skills and knowledge transfer in the most effective ways
  • The added-value from international/national reviews has genuine legitimacy to individual learning- with explicitly mapped transfer points or nodes across the network
  • The learning network is a key enabler for cultural and team climate improvements to this end
  • Individual learning evidently ‘scales-up’ to organisational learning. For example, an individual attending a CPD event would share a brief of that learning that is disseminated to each and every node

 Jason is a Business Psychologist.