My agile journey started almost nine years ago. In that time I have been fortunate enough to undertake the roles of Product Owner, Scrum Master and Agile Coach. These roles and the different organisations and industries in which I have fulfilled them, have helped to provide me with a broad range of experiences and examples of agile implementations and ways of working that I am now able to share with those whom I am currently working.
My most recent roles have primarily been focused in the Agile Coach space, in particular, working with organisations going through a change process where they are adopting agile ways of working and with people, teams and organisational leaders embarking on their own agile journeys.
Change is scary
Whenever the words ‘change’ or ‘transformation’ are mentioned within an organisation it can often bring with it a sense of unease and uncertainty as people worry about it may mean for them, their team and/or their department. In some instances, this trepidation can lead to people ‘putting up barriers’ in an effort to protect themselves from the unknown. This can lead to them becoming overly defensive about how things have worked in the past and averse to trying new things.
As an Agile Coach, I need to be able to introduce the evolution that people, teams and the organisation are beginning in such a way as to build relationships and trust. This will allow for the defensive barriers to be broken down and ensure that I ‘get everyone on the bus’.
Whichever agile framework or methodology an organisation chooses to adopt, it is highly likely that there will be a host of new terms, phrases, roles, events and artefacts that people and teams will need to become more familiar with. Understanding these defined aspects of the ‘new ways of working’ can be easier for individuals, teams and organisations to accept due to the fact that they can be more easily described and documented.
For example: –
The Development Team – A group, consisting of between three and nine people, that have all the skills, knowledge and experience necessary to join in a collaborative effort and shared commitment in order to develop a potentially releasable increment of ‘done’ product.
The Daily Scrum – A daily meeting, lasting up to fifteen minutes, where the Development Team discuss the progress that they are making towards the Sprint Goal, along with any impediments that would prevent it from being achieved.
The Product Backlog – A prioritised list of items to be worked on by one or more Development Teams, which is owned and administered by the Product Owner.
What can be more difficult for people, teams and organisations to adopt and accept, are the behavioural and mindset changes that a successful agile adoption requires. In order to help individuals, teams and organisations acknowledge, understand and accept both the new terms and phrases, as well as the less tangible aspects of the agile transformation through which they are going, I like to try and use analogies. So, what is an analogy? What is the difference between an analogy and a metaphor? What are the benefits that analogies provide? And, are there any pitfalls of using analogies?
An analogy is ‘a similarity between like features of two things, on which a comparison may be based’ , while a metaphor is ‘a figure of speech in which a term or phrase is applied to something to which it is not literally applicable in order to suggest a resemblance’ . In short, an analogy is a comparison of two similar things, whereas a metaphor implies a meaning that is not literal. Here is an example of each based upon the same subject.
“That test was as difficult as plaiting water.”
“That test was murder.”
Both examples are intended to have a similar meaning, with the intention of conveying the difficulty of the test. The first provides a comparison of the difficulty level, while the second just implies that the test was horrific.
In addition to the analogy identified above, there have already been two other analogies included within this blog post. Did you spot them? It was not intended that either of them be hidden or disguised, but used in the right context, they can provide a familiar explanation that aids understanding and increases acceptance.
The first, ‘putting up barriers’ is a common phrase that is used when individuals look to defend themselves, their property and/or their way of working. A physical barrier can help to stop or slow progress, for example, the Thames Barrier is used to protect and defend London from flooding from high tides and storm surges. It is unlikely that people will start to build physical barriers around themselves within an office environment, however, they may begin to exhibit obstructive behaviours whereby they put down an idea before even giving it a try or, their efforts at trying something new are half-hearted and potentially disruptive.
The second, ‘get everyone on the bus’ highlights the fact that helping an organisation adopt an agile way of working is not just a case of walking in the door, reciting the Scrum Guide telling people to ‘do as I say’. Those that are closely affected by the transition need to understand that they will be going on a journey. Underlying this analogy is a further paradigm. Very few bus routes are linear and go directly from A to B, with many having lots of twists and turns. This aligns with the fact that things may not work right first time, and that is ok. Failure provides people, the team and organisation the opportunity to learn and pivot in order to head back in the right direction.
Using an analogy can often help people make sense of the change being discussed, with the analogy making the unfamiliar familiar. The more similarities/commonalities people can find, the more readily they will accept the new idea or concept being introduced. Both Apple and Amazon have used this approach when establishing new products/services to the marketplace.
In order to help customers be more comfortable with its first Macintosh computer operating system in the 1980’s, Apple used terms that were familiar for users. After their computer booted up, users were presented with a ‘desktop’ that contained icons labelled ‘trashcan’ and ‘files’. They were not being presented with a physical desktop, waste bin or filing cabinet, but they represented what was familiar from a physical office in a digital setting.
When Amazon first entered the digital shopping arena, many shoppers were unfamiliar with e-commerce. Amazon decided to deliberately use terms from a ‘real world’ shopping experience as part of the ‘cyber world’ experience in order to transition people from the known to the unknown. Consumers were directed to put items into a ‘shopping cart’ and once they had finished shopping, they were directed to ‘check-out’.
Over the years I have used a variety of analogies, using examples that I have heard and repeated as well as creating my own. They have served me well as a coaching and training tool to introduce new processes and practices to people, teams and organisations. Here are a few of them, some of which (or versions of them) you may have heard and/or used yourself: –
Organisational Change
Turning a container ship takes a long time. Similarly, adopting agile ways of working across a large organisation will not be instantaneous. A speedboat is nimble and can pivot quickly. When implementing agile ways of working, start small to allow faster changes of direction.
Building Foundations
You cannot build a house without first laying the right foundations. Without any foundations being put in place there is a high probability of problems manifesting themselves in the future. When adopting an agile way or working, it is important to get the basics right, so that they provide a solid base that can be built and innovated upon.
Iterative Delivery
10-pin bowling is the ultimate iterative delivery. You have ten frames to deliver maximum value towards an overall aim (getting the highest score possible). There are opportunities within and between each frame to inspect and adapt the ball you use, where you start your approach, where you’re aiming etc. based on what you learnt from the previous frame.
Cross-Functional Teams
Each player on a football team has a primary position that they fulfil but that does not stop a striker from tackling or a defender from scoring as they work together to deliver value as a team. The same should be said of agile delivery teams. Your primary role may be that of a developer or tester, but that does not stop you from undertaking other work that would benefit the team and help deliver value.
Limiting Work in Progress
The more balls that you juggle or plates you spin, the more likely one (or more) will be dropped. Taking on too many tasks, user stories or projects at the same time can result in one (or more) being delayed and/or delivered with reduced quality.
Sustainable Pace
It is possible to push a car to its limit. However, if you keep running it at full throttle eventually one or more parts will fail. The same can be said of an agile delivery team. Pushing a team to undertake longer hours in order to hit a deadline could have a negative effect including, reduced productivity/velocity, reduced quality and reduced availability (increased sickness).
Goal Setting
When 10-pin bowling you should aim for the arrows not the pins as it is much easier to hit something 15 feet away than 60 feet away. The same should be said about agile deliveries. Aim and focus upon the next small deliverable increment, rather than the long term goal.
Maintaining Standards
One trip to the gym will not make you fitter or shift those extra pounds. In order to reach those goals you need to attend regularly and follow a consistent regime. The same can be said for implementing agile ways of working. Working practices, processes and agreements, as well as events, artefacts and roles and responsibilities cannot be picked up and put down at will. They should be followed and amended as the team matures and develops.
Continuous Improvement/Learning from Failure
Thomas Edison said, “I have not failed. I have found 10,000 ways that won’t work.”. People, teams and organisations should embrace failure as an opportunity to learn and improve, without making the same mistake twice.
Although I have included a number of analogies here, there are many more in circulation (try searching #agileanalogy on LinkedIn, Twitter and/or Facebook) that could help to demonstrate that the ‘new’ item or way of working being discussed is not too dissimilar from something of which you are already aware.
The use of analogies is not without its pitfalls and this was demonstrated in the first Scrum Guide. The 2010 Scrum Guide contained an analogy, that of the chicken and the pig, which was used to help individuals understand and appreciate the difference between those who were committed to a delivery and those who were simply involved. It was removed in the 2011 version of the Scrum Guide as it was felt that the terms ‘chicken’ and ‘pig’ were derogatory, harmful and created a negative connotation that drove negative behaviour.
It is important to understand when the use of an analogy may become detrimental (as noted above). Relying too heavily and too long on a single analogy carries with it a notable risk. Over time that analogy may become a poor fit relative to other analogies that may be available. Following an analogy too closely can cause similarities to remain undetected or be falsely assumed to exist. Concentrating too much on similarities can also cause what is unique about the ‘new’ to be overlooked.
Despite these potential flaws, analogies can be one of the most helpful tools for conveying and ensuring the understanding of a ‘new’ message or meaning. The challenge is to use the right analogy, at the right time, for the right length of time. It is important that you employ a wide range of analogies, maintain an open mind and be willing to change analogies with the times and circumstances.
Read more about our Agile Coaching and Transformation service.
