The term 'Agile' is frequently used as an adjective to qualify the noun 'culture'. So there is, at least in the minds of a substantial number of Agile evangelists and practitioners, a thing which is referred to as 'Agile culture'. But what can this mean ?
Cultures tend to have complex networks of moral beliefs - beliefs about what is 'right', what is 'wrong', and to what extent given thoughts and behaviours fall into these categories. Sometimes these beliefs are called 'values', which are often expressed as a set of simple, discrete, concepts although the underlying reality is usually messier.
Therefore the simplest approach to answering the question 'what is Agile Culture ?' could be to look for it's values. This is not hard. The Agile Manifesto starts with a declaration about the values of the authors. This declaration is pretty short and succinct.
The reason I appear to be hedging here is that the relationship between values and the expression of those values, no matter how short and succinct they may be, is not so simple.
It's pretty straightforward to make a case that no well defined system of human interactions exists in a vacuum - humans are not easily bounded by typical abstract system or process definitions which have a particular focus. They will necessarily be affected by things which are 'out of scope' for these processes. They exist in an 'environment' which the process cannot ( and does not seek to ) control or define.
So in a general sense, it's really hard to be confident about the form Agile Culture will take simply on the basis of inspecting values. Wherever and however these values are applied, they will be translated through layers of environmentally defined interpretation. This 'environment' may be the corporate environment, it may be a sociopolitical environment, it may be a geographic environment, very likely it will be a combination, but there will be 'environment'.
Therefore although it is safe to say that 'Agile Culture' is whatever happens as a result of applying the values in the Agile Manifesto, it's not safe to assume that your 'Agile Culture' will look identical to mine.
For reasons that are not particularly clear, it has become fashionable in recent times for businesses and organisations to codify particular sets of values with which they desire to be publicly associated. These 'values' are often used within the organisation to judge the behaviour of individuals. They may even be demanded of or by business partners and suppliers.
It is entirely unsurprising that such values tend to describe thoughts and behaviours which emphasise compliance with legal requirements, compliance with whatever the organisation's customer base happens to think is 'best practice', and compliance with whatever the organisation's management and investors consider likely to enhance profit.
Scrum, although not formally a business or organisation, has actually attempted to codify a set of values. These are quite distinct from the Agile Manifesto values even if, as I explain below, there are some points of contact.
Although these values are not defined with the same intent in mind as those I mention above, they are still values in the sense of being beliefs or assertions about what is right, i.e. they are fundamentally moral in nature. They are actually the part of Scrum with which I have the most difficulty.
The difficulty is straightforward - both Agile and Scrum emphasise empiricism as their philosophical basis. Agile and Scrum are what they are because they are based on observation of what works well.
Values, on the other hand, are very much not empirical. Values are moral judgements - they are an expression of what you, or a particular entity or culture, believe to be right, and therefore should be made true, rather than merely being observations of what is, in fact, true.
It follows that there is no such thing as 'an empirical value' - it's a contradiction in terms. It is not sufficient that a value is derived from observation. The observation itself may be empirical. A value derived or inferred from it is not.
This is not a trivial distinction. An emphasis on values of this sort can easily destroy any benefit that accrues from empirical thinking, because any empirical observation that conflicts with such a value will be considered wrong, and therefore either ignored or positively attacked. The values become, or perhaps are even deliberately adopted as, a dogma.
Mixing empiricism with moral judgement, and attempting to present the resulting chimera as a coherent whole is a recipe for stress and confusion.
It is very notable that the Agile Manifesto, when talking about values, couches them as the beliefs of the writers themselves, rather than being observations per se. In doing so, they avoid the trap of 'empirical values'.
Scrum, however, has followed a different path.
The Scrum values were not attached to the original definition of Scrum. Ken Schwaber ( one of the creators of Scrum ) and Mike Beedle first describe them in the book “Agile Software Development with Scrum”, where they claim to have observed them as characteristics of successful Scrum teams. Since 2016 ( a long time after they were first described ), they have been formally adopted and added to the Scrum Guide.
Note very carefully that there is an additional layer of indirection here as compared to the Agile Manifesto. The values talked about in the Agile Manifesto were opinions held by those writing it.
Scrum, on the other hand, likes to treat the values referred to by Schwaber and Beedle as empirical observations. In fact, they are inferences - i.e. they are inferred from observations of the behaviour of others, via the minds of the authors. Therefore not only are these values not 'empirical' because values cannot be by definition, they are not even empirical in the sense of actually being observations per se. They are simply an attempt by two people, albeit experts, to capture abstractions which represent the beliefs they believe guided the behaviour of some other people.
Nonetheless, these values are now taught as being fundamental to the execution of Scrum, and are often presented as the underlying rationale for Scrum. However, I consider retrofitting a rationale to something after waiting to see how ( or if ) it actually works in practice to be, at best, somewhat disingenuous.
An equally valid perspective is that Scrum evolved until it happened to find a set of behaviours that could make it work well. What is usually left unsaid is that perhaps this is not the only set of behaviours that could be used - but as long as a particular set, whether well-observed or not, has been abstracted into values, and is taught as dogma, it is likely that others will not be explored ( see above ).
Scrum dogma is what it is, so it is relevant to ask 'what is it ?', and even 'what does it mean ?'. Strap yourself in, this may be a bumpy ride 🙂.
Scrum values are simply five words : Focus, Courage, Openness, Commitment, Respect.
The Scrum Guide provides very succinct definitions of these terms, but they are too brief and woolly to really be illuminating. An attempt at a more useful set of definitions has been made by Gunther Verheyen, and certainly these definitions use more words, but I don't find them to be any more helpful.
Exactly how Scrum has come to the point of relying on these five words as the bedrock upon which Scrum supposedly rests on the basis of these definitions is a mystery to me.
If I temporarily use the term 'culture' in a different, less specialised sense, thinking of such things as 'Western' culture or 'Indian' culture, then not only is there inherent ambiguity in these terms considered from the perspective of a given culture, there is certainly a possibility that cultural differences could result in significantly different interpretations. And indeed, since no one is acultural, perhaps that is one reason for my own difficulties as described below.
What follows draws on a variety of sources, including the Scrum Guide, Gunther's site, various books and training material that I've encountered, and of course personal experience working with Scrum.
Time and again, definitions of Focus for the purpose of Scrum are offered that rely on using the word 'focus', sometimes liberally and in multiple contexts ( e.g see Gunther Verheyen's definition ). It's a little like the apocryphal English approach to communicating with foreigners by just speaking English BUT LOUDER.
Irrespective of any considerations of recursion, from my point of view 'focus' is singular when considered in the context of human activity. It's a contradiction in terms to have multiple foci, even if in a technical/mathematical sense it may be possible. You could say 'ah, but I can focus on X now, and Y in a few minutes, and then Z after that'. In fact, I think this is an example of the sort of situation that Scrum is trying to avoid.
Or you could invoke context, and simply argue that the concept of 'focus' should be applied in all of the many contexts encountered in the course of normal working activities. But without context-specific definitions of what focus really means, this does not really take us any further towards an understanding of it. I'm trying to understand how 'focus' works in Scrum.
So it becomes an exercise in semantics and abstraction to formulate a singular definition that describes 'focus' for the purposes of Scrum.
One key aspect of Scrum is minimalism. Minimum effort, minimum time, minimum functionality, minimum scope, minimum concurrent tasks. Of course, Einstein's comment that things should be made as simple as possible but no simpler must act as a bound on this minimalist tendency. Minimal thinking cannot be an excuse for poor quality or goals not met.
Another key aspect of Scrum is limitation. The sprint, for example, represents a limitation on effort. The Sprint Goal represents limitation on scope.
I think these are the key perspectives when considering the meaning of 'focus' in Scrum :
Focus in Scrum is the state achieved by pursuing limitation and minimisation in all the various contexts in which these things can be done.
Of course, one could argue the converse - that limitation and minimisation derive from the Focus value. But in this case we would be no nearer understanding the Focus value per se, and in any event as previously noted, the value is supposedly derived from observing successful practice in the first place.
It is also very clear that this value is related to Lean Thinking concepts - indeed, the Scrum guide makes explicit reference to 'Lean thinking' as a basis for so-called 'Scrum theory'.
This particular value seems to be used as a catch-all for any behaviour that requires honesty, discipline, communication, or any recognition of normal professional ethics. Added to the mix, at least in some expressions of this value, is the quasi-religious expectation that people should engage in ''courageous' evangelism of Scrum.
The Scrum Values Poster has this to say :
'Scrum Team members have courage to do the right thing and work on tough problems'
I don't doubt that there may be circumstances where some of these things are difficult. I'm certain some people will have more trouble with some of these things than other people. These are things which may benefit from training, and require support from management and colleagues. The Scrum master should certainly be watching out for people who may be having problems of this nature, and be proactive in offering and arranging help, perhaps via line management, perhaps via HR depending on circumstances.
However, my particular dislike of this value is that I regard nearly all of the behaviours lumped under it by Scrum as merely normal professional obligations. It doesn't ( or shouldn't ) require 'courage' to discharge a normal professional obligation. If the organisation you're working in operates in such a climate of fear that this is actually the case, upholding Scrum values is probably the least of your concerns.
Kent Beck, one of the inventors of the XP ( Extreme Programming ) Agile method, apparently defined courage as “effective action in the face of fear.” But, fear of what ? In my world, 'courage' means facing up to and dealing with an existential threat, or at least a threat of actual harm, and not merely the possibility of criticism, and certainly not the possibility of just being wrong. Sometimes I make my coffee too strong - that doesn't mean I need any courage whatsoever to make the next cup.
It seems to me that Scrum's application of this term significantly dilutes and devalues it. If a term is required for acts of the sort Scrum labels as 'courageous', there is no shortage of alternatives. 'Determination', 'Grit', 'Confidence', even 'Enterprise' all seem like candidates to me.
The concept of 'Courageous' Scrum evangelism is almost sinister. Yes, there may be opportunities to extend the use of Scrum within your organisation, and supporting that activity could be considered part of every developers role, suitably managed. More likely, it is a part of the Scrum master's role. Since there is a meme in Agile circles that refers to the Dead Scrum Master ( although this is not, as sometimes presented, exactly what Ken Schwaber said ), perhaps this role does require courage 🙂.
But it is surely not the responsibility of each and every Scrum team member to risk death or pointed comment by standing up before the pagan hordes around the water cooler and imploring them to believe. If 'focus' is truly important, then this activity feels very much like one that should be minimised.
In conclusion, although I can see important behaviours that Scrum labels as 'courageous', I find this label seriously misleading. My preferred term for 'Courage' would be 'Confidence'.
One way to understand this value is to ask what 'non-open' might look like.
It may mean that information about problems was not shared with colleagues or stakeholders. It may mean that individuals or teams treat any techniques they may devise for improving quality as secrets for their benefit. It may mean that the current state of the sprint was invisible even to team members. It may mean that individuals or teams did not share information about their capabilities. It may mean that teams were averse to adapting in the face of changing customer requirements.
Therefore it's really difficult to see how a non-open approach could positively benefit any team or organisation that was aiming to be Agile. It's hard to see how many elements of Scrum could function. What benefit could a retrospective possibly provide if people were not open about their problems ( or their achievements, or their ideas for improvement ) ? What chance would the team have of preparing appropriate backlog items if problems and capabilities were not known or changed requirements could not be taken account of ?
In fact, it runs a little deeper than this. Although we are talking here about Openness as a Scrum value, in this case Scrum is not describing anything particularly special or unique. It's actually quite hard to see how any team based development environment could work effectively in the face of the sort of 'non-open' behaviour described above. Therefore it comes as no surprise that Schwaber and Beedle should have observed it in successful teams.
If we look for 'openness' in the Agile values, it's fairly easy to see. 'Responding to change', 'Collaboration', and 'Interactions' are all things which can fit under the umbrella of 'openness' - partly in the form of communication, partly in the form of 'being open to change'.
If we look for 'openness' in the Agile Principles, there is no explicit reference, and it's a little trickier to see openness. Indeed, there's a deep tension in the Agile Principles between empowering the team viewed as a collective, and giving both responsibility and authority to the individuals within it. The idea that the team ultimately serves the needs of the business and the customer ( not necessarily different entities ) does not sit comfortably with the idea of an empowered team with extremely independent members who have considerable authority.
However, I would offer Principles 2, 4, 6, and 12 as drivers for openness. Changing requirements, working with the business, face to face communication, and reflect/adjust thinking, all reflect the openness of the Agile values pretty directly.
Here is the one value that I thoroughly agree with. In fact, I've disgorged a whole section about this. See Commitment.
This is another seriously woolly one, and perhaps the one that I have most trouble understanding in a Scrum context. So much so that I've also offloaded this discussion to a separate section. See Respect.
© Mark de Roussier 2022, all rights reserved.