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 http://jungiancenter.org

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.

Summary
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

 

 

Yoda: A key role in Agile?

One of the key strengths of the Agile manifesto is the principle is that the team is self-organising. From these first principles we can anticipate that team roles will emerge from organising in this kind of way, rather than by way of a contrast, the roles being assigned by management. When we say ‘team roles’ we are not referring to technical roles such as Developer, Tester or Product Owner or Scrum Master, rather, we are referring to sociological functions; that enable the team members to ‘perform’ to high quality or best-in-class standards.

Yoda's_hover_chair

This ‘division of labour’ if you like between product delivery/execution and team sociological and/or psychological needs goes back a long way in team theory, and many of us can recall Belbin’s Team Inventory from his seminal book ‘Management Teams: Why They Succeed or Fail’ back in 1981. His typology was based on teams from a broad range of industries and included eight roles such: Chairman, Shaper, Plant, Monitor-Evaluator, Company Worker, Resource Investigator, Team Worker, and Completer-Finisher. Later, the notion of the Specialist was added.

Sharpening our focus more specifically on Agile IT teams, one recent study researched 58 Agile practitioners from 23 software organizations in New Zealand and India. What was fascinating is that they discovered that the roles, if and of themselves, emerged from the self organising processes underpinning Agile. To be fair, we might expect this, but this empirical evidence over a four-year period, adds to our body of professional knowledge. The authors used open-ended interviews to allow the research themes to develop (rather than impose their schema on the research) and they report finding these roles: Mentor, Coordinator, Champion, Promoter, and Terminator/Finisher. (see Hoda et al (2013) in Software Engineering, IEEE Transactions, Vol 39 (3).

From a Business Psychology perspective, what I found interesting was some of the similarities between the Mentor role and Jung’s archetype for what he called the ‘wise old man’. This role is characterised, or represented as a kind, ethical and often older Father-type ‘figure’ who draws on his deep knowledge and experience of people (what we might refer to in the 21st Century as emotional or people intelligence) to offer guidance, coaching, support and encouragement to help others. The coaching insights/ discussions help others to access deeper self-resilience and an improved sense of who they are, and who they might become, thereby acting as a Mentor.

Sometimes when appearing in dreams, Jung claimed that the wise old man might in some ways be seen as Other- that is to say from a foreign culture, country or set of values. In extreme cases sometimes like a liminal being of some description. I think that Yoda from Star Wars would be a more modern ‘take’ on this archetypal role. (By the way the new Star Wars trailer is very exciting! Bring-on December!).

When located in a story, there is a key turning-point in the narrative, when the wise old man naturally dies, or is murdered, or at times sacrifices himself to enable the Hero to take his rightful place in the story. As you might recognise by now from one of your favourite stories… because of the additional self-knowledge, and awareness gained from his relationship with his Mentor, the Hero can claim the rightful victory before the next turn in the text.

But what about us today in our Agile world? Well, it would be all to simple to make the erroneous link that the Mentor equals the Scrum Master. We, of course, have to be careful not to make this mistake. Recall that from the first principle of self-organisation, we know that these roles are not prescribed, but rather emerge from the team itself. Therefore, we can expect and anticipate that different team members, as individuals, will emerge as the ‘wise old man’ or or ‘wise old woman’ at any given time- given the team psychological and sociological needs of the Sprint in question.

To me this sounds and feels both flexible and life affirming, and ‘gives permission’ for us to see our own personalities, and strengths, in much more fluid, productive, open and transformative ways.

May the Force be with… You?

Take Care, Jason.

whatisbp

 

 

‘Agile is King and PRINCE remains the heir’? Not always…Project Design Choices.

At first glance the following sentence, or statement, will seem self-evident: “The project design will have a significant  bearing on the project’s success”. Fair enough I hear you cry! But what does the empirical evidence-base say about when, or what variables or factors determine when you should ‘design in’ adopting an Agile approach.. as opposed to say a more traditional approach like the classic PRINCE2?

AgileD

In this blog I’d like to focus on the team and project complexity factors. So I will ignore the organisational and the customer factors. I’ll cover those off in a later blog.

What do we know?

Firstly, that there are discernible team factors that should be analysed prior to adopting an Agile approach. These are as follows:-

  • Project teams committment (affective and psychological)
  • Internal project communication style/methods
  • Project teams expertise in the technical knowledge and actual delivery experience
  • Team dynamics and composition/maturity

What we know is that when the team is less mature, relatively inexperienced, and with low levels of technical skills and delivery experience and where the team dynamics are less collaborative and more ‘silo’ focussed then the evidence is that…traditional PRINCE2 project management is the best project design and this will predict project success. This holds true even when the project complexity is low and the project length and scope are short and narrow. A fascinating reality.

However, the opposite also holds true for Agile. What we know is that we should ‘design in’ an Agile approach in contexts where we have well established technical experts that have actual grounded experience of the given project’s demands. We also know that they all need to have worked ‘outward focussed’ and in typically more multi-vendor project designs in the past. In situations such as described and when these skills and experiences are found… but where the team is new then a professional PM can add value by developing the new team successfully in an Agile method as the Scrum Master.

This latter set of variables also holds true in project contexts where there is a need for pace, or urgency as well as innovation in the technical ‘fusion’ or integration of multi-suppliers. In this ‘innovation space’ Agile is ‘King’ and Prince remains in his younger, less mature but none-the-less ‘royal’ household!

I would add to this latter point that having a PM with actual experience of collaborative methods as well as some grounded, actual delivery, of complex projects (multi-million pound)would also be a critical success factor to this end. She, or he, can literally add value to the project outcomes in the ways outlined.

Happy project design!

As you can see your choice will have evidence-based consequences. Choose wisely!

All best Jason

whatisbp

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

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

Outcomes:

  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

Benefits 

  • 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

whatisbp
 Jason is a Business Psychologist.