Fearlessly Adapting to Change

As I experience more and more change initiatives of one form or another the more I see that most of the time they’re based on some sort of ‘hit and hope’ strategy. By that I mean they’re often driven by nothing much more than a lofty initial vision and then a lot of hope that that vision will somehow, perhaps magically, translate into a successful implementation.

In my experience these initiatives rarely result in the lasting change they set out to deliver. There’s a bit of brief initial energy and then things start to fizzle out. People don’t really fully understand or buy into the intended change, understand their role in the initiative or how they’ll help contribute to success. Such initiatives, it would seem, are setting out to fail.

Surely a better strategy is to set out to succeed, to take a considered and purposeful approach to change and maximise the chances of a lasting positive impact.

There are many tools that we can use to help with this including various change models and frameworks. One of the most well known in the agile space is the ADAPT model, an amended version of the more widely recognised ADKAR change model. The strength of this model, in my view, lies in its simplicity to understand and its effectiveness in practice. It recognises that lasting change requires a collaborative and motivating approach and sets out clear stages to help shape and realise that change:

Awareness that there is room for improvement

Desire to change

Ability – to work in a new way

Promote early successes to build momentum

Transfer the impact throughout the organisation so that it sticks

These stages help to provide focus to a change initiative by telling us what to focus on. They don’t however tell us much about how to achieve the desired outcome for each of the stages (Mike Cohn does offer some suggestions in his Succeeding with Agile book). It was through reading the Fearless Change and More Fearless Change books by Linda Rising and Mary Lynn Manns that I realised the patterns contained within make an ideal companion for the stages within ADAPT.

Rising and Mann describe their patterns as strategies for enabling change to happen, iteratively through small steps. If we view the stages within ADAPT as the what of enabling change then we can perhaps view the Fearless Change patterns as the how. Each pattern is based on real world observations and experiences, practical to use and theoretically grounded. Rising and Manns present 63 of these patterns in total and are clear about the nature in which they should be used:

“It’s not a recipe book for change. It is a book of patterns – nuggets. It’s up to you to decide if one or another nugget would be helpful in communicating your particular idea campaign within your organization”.

That said, with the sheer amount of information it can become difficult to maintain a considered view of what patterns you might use and when you might think about using them. It struck me that the stages in ADAPT might help bring some shape to this.

This is obviously always going to be a subjective view and some patterns will have a clear relevance to more than one ADAPT stage but here’s my initial view of how the Fearless Change patterns might fit with the stages of ADAPT (click image to view a larger version).

I realise that without the details of each pattern the above can seem a bit meaningless. Even though, perhaps such bringing together of strategy and patterns can help to evolve our understanding of change management more broadly.

In their 2012 paper, Back to the Future, Revisiting Kotter’s 2006 Change model, Appelbaum et al note that:

“Theories and approaches to change management currently available to academics and practitioners are often contradictory, mostly lacking empirical evidence and supported by unchallenged hypothesis.

Studying major change management projects is inherently difficult, due to their sheer complexity. Obstacles include difficulties encountered in evaluating the level of implementation of the steps and the challenge of corroborating implementation level with implementation success level.”

Could an approach of viewing potentially disparate change patterns through a strategy lens such as ADAPT help us to better understand the complexities of change initiatives, how to respond to them, the various steps and actions involved and the effectiveness of any patterns applied?

In other words, could bringing a new perspective to viewing and understanding change patterns help us improve our view and understanding of how to approach change and, in turn, of change itself? At the very least, the combination of ADAPT and the Fearless Change patterns might be a useful tool to help us review, consider and apply the various options available to us when setting out on a new change initiative.

Shaping the Strategy: Consultative Coaching

Hackman and Wageman (2005) posit that there are three fundamental functions that determine the level of team effectiveness. The second of these is the appropriateness to the task of the performance strategies the group uses in it's work. Coaching that addresses performance strategy can be seen as consultative in character.

Self-organisation is at the heart of how Agile teams work. Teams are empowered to make, own and execute plans for getting it's work done.

In doing so, and in line with the theory of team coaching, the effectiveness of a teams performance strategy will be influenced by two key factors. Firstly, to minimise mindless adoption or execution of task performance routines in uncertain or changing task environments and secondly to foster the invention of ways of proceeding with the work that are especially well aligned with task requirements.

Hence, in order to shape an effective performance strategy understanding the nature of the task at hand is of critical importance. The use of sense making frameworks such as Cynefin may be of help with this, but specific frameworks aside, the key point is that different situations require different responses. Although self-organisation will be at the heart of that response in an Agile setting, consultative coaching functions can help a team recognise the nature of the situation with which they're faced and to tailor their approach and practices accordingly.

Consultative coaching is best placed at the mid-point of performance cycles when teams have existing data to reflect on and are arguably more open to altering their performance strategies. The multiple feedback loops in an Agile context again give rise to multiple opportunities for the reflective improvements that consultative coaching can help deliver.

Sharing the Knowledge: Educational Coaching

Hackman and Wageman (2005) posit that there are three fundamental functions that determine the level of team effectiveness. The third of these is the amount of knowledge and skill members bring to bear on the task. Coaching that addresses knowledge and skill can be seen as educational in character.

At the heart of Agile approaches is the concept of continuous improvement. Moreover, the process of a team continuously improving stems from the team continuously learning. Effective teams will continuously develop new knowledge and skills, seeking opportunities to learn how to work better as a team in pursuit of their given task.

The Agile concept of a cross-functional teams and members with T-based skills strives to enable members to make a valued and continued contribution to the output of the team. Creating and maintaining an effective cross-functional team and T-based members though requires continued investment. Knowledge and skill need to be fostered both in terms of how to work well as a team and the individual task skills required within it. This is where educational coaching delivers.

Educational coaching is best placed at the end-point of performance cycles when teams have collected as much performance data as they can. With the task in hand complete and armed with maximum data, teams are arguably best positioned to reflect on their performance and internalise any lessons for going forwards.

Growing the Effort: Motivational Coaching

Hackman and Wageman (2005) posit that there are three fundamental functions that determine the level of team effectiveness. The first of these is the level of effort that group members collectively expend carrying out task work.

Coaching that addresses this level effort can be seen as motivational in character. The aim of motivational coaching interventions is to build a commitment to both the group and it's work. This commitment needs to be shared and maintained amongst all group members.

In practice this involves building an igniting purpose and a shared reason of being for the group. This is the area where we can see the importance of giving teams problems to solve rather than solutions to deliver. The problem presented to the team gives them something to unite around and a base from which to collaborate and derive a solution. This in turn builds a shared ownership around the problem and solution and an increased commitment to the team's work.

We can look towards collaborative specification approaches and tools such as Impact Mapping as examples of ways which can provide a team with an increased understanding of desired outcomes and input into possible solutions.

Due to it's character, motivational coaching is best placed at the beginning of a performance cycle. The different levels of feedback loop which operate in an Agile setting present multiple opportunities for the application of such motivational levers, e.g. at the individual feature level, at a Sprint level or higher at a release or project level. Moreover, with the use of multiple feedback loops the team will be presented with a range of opportunities to benefit from the increased engagement and commitment that motivational coaching interventions can help deliver.

Expert Coaching

Hackman and Wageman's Team Coaching paper outlines a functional approach to coaching underpinned by a temporal focus. It's this functional and temporal approach, combined with Agile and Lean thinking which forms a core component of the Expert Coaching pillar in the Agile Coaching Circle.

Hackman and Wageman base this functional and temporal approach to expert coaching on two key propositions and it's easy to see how they lend themselves to an Agile setting:

Proposition 1: Coaching interventions that focus specifically on team effort, strategy and knowledge and skill facilitate team effectiveness more than do interventions that focus on members' interpersonal relationships.

Within an Agile setting we clearly value a focus on the output and effectiveness of the team rather than of any particular individual within in. A model then that focuses on the team as a collective and building it's effectiveness as a whole is clearly one which lends itself to working with Agile teams. Coaching functions that focus on team effort, strategy and knowledge and skill can be seen as motivational, consultative and educational in nature.

Proposition 2: Each of the three coaching functions has the greatest constructive effect at specific times in the team task cycle. Specifically, (a) motivational coaching is most helpful when provided at the beginning of a performance period, (b) consultative coaching is most helpful when provided at the midpoint of a performance period and (c) educational coaching is most helpful when provided after performance activities have been completed.

This proposition offers obvious relevance to an Agile setting in way of the defined performance cycle and the distinct points within it. Agile teams seek regular feedback on their work, constantly going through performance cycles of their own and thus providing apt opportunity for the timely utilisation of the three coaching functions.

Combining motivational, consultative and educational coaching functions and their temporal application with a standard PDCA action and feedback loop gives us a clear and practical illustration for how we might consider and apply these coaching functions in an Agile work setting.

For more information on each of the coaching functions and their relevance in an Agile setting see below:

Motivational

The team coaching model posits that there are three functions that determine the level of team effectiveness. The first of these is the level of effort that group members collectively expend carrying out task work.

Coaching that addresses effort can be seen as motivational in character. The aim of motivational coaching interventions is to build a commitment to both the group and it's work. This commitment needs to be shared and maintained amongst all group members.

More on motivational coaching.

Consultative

The team coaching model posits that the second function that determines team effectiveness is the appropriateness to the task of the performance strategies the group uses in it's work. Coaching that addresses performance strategy is consultative in character.

More on consultative coaching.

Educational

The team coaching model posits that the third function to determine team effectiveness is the amount of knowledge and skill members bring to bear on the task. Coaching that addresses knowledge and skill is educational in character.

More on educational coaching.

The Crystal Clear Tree

A little while back as part of an organisational merger I need to facilitate the coming together of two groups of agile coaches and agile project managers.

One group came from an organisation that was more Scrum focused and the other group from an organisation that seemed to be somewhat anti-Scrum, with scepticism around the defined levels of process and control within the framework. Both organisations however had a strong underlying alignment to agile values and principles and as part of the merger it was important that we identified these commonalities to provide a common ground for moving forwards.

There were also questions around how the teams at each organisation were working in practice. The two groups would need to come together and find a way of working in the new organisation and to do that we needed to explore and develop a shared understanding of each organisation and group’s current ways of working. For this to be an effective exercise we needed to avoid becoming bogged down in philosophical debates of Scrum, vs Kanban or any variation thereof and remain focused on exploring and understanding our practical commonalities and differences.

To provide a framework for that exploration I looked towards Alastair Cockburn’s Crystal Clear methodology and the properties contained within. For those unfamiliar with this approach Crystal Clear is part of the wider Crystal family of methodologies based on Alastair’s research of successful teams at IBM. Crystal methodologies are characterised by being human-powered, ultralight and stretch-to-fit (http://alistair.cockburn.us/Crystal+methodologies). That’s to say that they work to enhance the work of the people involved, to reduce overhead and bureaucracy and to start with something just smaller than you think you need and then grow it just enough according to context.

Crystal Clear is described as a human-powered methodology for small teams. It provides a highly optimised way to use a small, collocated team, prioritising for safety in delivering a satisfactory outcome, efficiency in development and habitability of the working conventions (http://alistair.cockburn.us/Crystal+Clear+distilled).

As such, Crystal Clear is a process agnostic approach to work which outlines the properties that characterise successful projects rather than prescribing a particular process or tool. This seemed like an ideal foundation on which to base our discussions, removing the potentially distracting topic of processes and tools from the equation and providing a neutral and focused container to explore how the software teams in each organisation strive to successfully deliver.

As part of using Crystal Clear in this context I gradually developed a way of illustrating the methodology in a concise and easy to understand format. In the spirit of agile growth and evolution I developed a Crystal Clear tree metaphor which is quick and easy to both deliver and understand. You can run through the metaphor with a team in just a few minutes and deliver a concise and powerful message. I thought it would be useful to outline here as an approach for outlining this lesser-mentioned approach or as inspiration for developing your own learning metaphor. I also happen to be a big fan of Crystal Clear and the thinking contained within and keen to support new ways of sharing that thinking.

*Apologies for the crudeness of the drawing

Roots

The roots of the tree represent the priorities of Crystal Clear. The priorities are essentially the outcomes that Crystal Clear seeks to deliver and they form the roots of the tree as everything else stems from them. Each priority is represented by a person symbol to emphasise the human-driven and people-centric nature of the approach. Crystal Cleat isn’t driven by process or tools, rather success is achieved though enhancing the work of the people involved. Each person represents a single priority; safety of outcome, efficiency of development and habitability of working conventions (whatever the ways of working, the development team needs to be able to live with them).

The Tree

With strong human-focus roots in place a strong a sturdy tree can grow.

Branches

The branches of the tree represent the Crystal Clear properties. There are two sets of properties in Crystal Clear, three properties that should be found on all projects (core) and four properties that are optional, although still important. It’s the branches that give the tree its shape just as it’s the properties that shape the success of a project.

The core properties are represented by the sturdiest, thickest branches whilst the optional properties are represented by branches that are thinner although still integral to the shape and balance of the tree.

The branches also provide a good way for the teams to measure their situation by gauging their alignment to each property. Teams can shade the branches according to where they think are with each one and use as a visual tool to focus and adjust their efforts.

Core properties:
1. Frequent delivery – The most important property of any project is to deliver working software frequently. Crystal Clear doesn’t dictate how frequently although greater frequency delivers higher project safety.
2. Reflective improvement – The team should regularly take time to reflect and improve on how it’s working. There’s always a better state to find.
3. Osmotic communication – This takes close communication to the next level. Team members are located so closely that they pick free-flowing information as though by osmosis.

Optional properties:
4. Personal safety – In order to truly improve a team needs to be able to speak out and address it weaknesses. In order to do this team members need to be able to speak out without fear of reprisal.
5. Focus – knowing what to work on and being able to work on it is essential to making progress. Teams should have clear goals and work items with minimal distractions.
6. Easy access to expert users – Rapid feedback is essential to gauge whether we’re heading in the right direction.  Expert users can be a valuable source of expert feedback.
7. Technical environment with automated tests, configuration management and frequent integration – Surprisingly still not embraced by all teams but all-important for safe and efficient software development.

Canopy

The canopy of the tree is made up from the smaller branches and leaves which represent the special eighth property in Crystal Clear; collaboration across organisational boundaries. This is property has special status because it’s a property in its own right providing additional project safety but also offers partial evidence that some of the other seven safety properties are being achieved.

It doesn't magically appear but comes from a strong sense of personal safety and working with a sense of honesty, amicability and integrity within and outside of the team. It can therefore be seen as a sign of a healthy ecosystem with the canopy being connected to and dependent on the branches of the tree.

Although clearly not an artistic masterpiece I find the simple tree metaphor works well to communicate the core messages at the heart of Crystal Clear. Hopefully it can be of use more widely and help spread the thinking further. In the meantime I’ll work on my drawing skills.

A Respectful Approach to Agile Coaching

At the heart of The Agile Coaching Circle is the knowledge that every team is unique. This may seem like an obvious statement but is seemingly often overlooked as teams experience the imposition of pre-defined ideas and practices, for example, strict and fixed planning meeting formats, inflexible inception exercises or specific and prescribed approaches to estimation.

 Within each team a particular blend of individuals, goals, requirements and technology combine to create a unique setting. Teams have different needs, operate in a unique context and will sometimes need to take varying approaches to similar problems. It’s therefore important that we respect the uniqueness of teams and give them the environment they need to harness their individuality and the strengths that come with it. By association this means that motivational, consultative and educational (MCE) coaching levers are not only likely to be different in nature between teams but also different in nature within the same team when faced with differing scenarios.

This means that with the use of MCE coaching levers we don’t give teams a list of practices, tools or instructions on how to approach a particular problem, but aim to give them the skills, knowledge and freedom to find their own.

Moreover, one of the tenets of the Team Coaching Model is to prevent the mindless adoption or execution of pre-defined routines and practices in favour of the team carving out their own more suitable strategies. Prescriptive approaches to agile coaching can all too often have the unfortunate and ironic effect or limiting an agile team’s ability to shape and evolve their performance strategy. One might argue that the word ‘coaching’ is often used to mask an approach of direction and control, underpinned by a lack of respect for the uniqueness of the team.  I would suggest, sadly, that such approaches are not that uncommon.

A foundation of the Agile Coaching Circle is therefore that every team is unique. That uniqueness deserves carefully considered coaching interventions, something that can be achieved through the appropriate use of the MCE levers. Moreover, such an approach can be a powerful motivational driver by its own accord – with teams driven by the trust and respect extended to them, values not only at the heart of the Agile Coaching Circle but at the heart of Agile itself.

Lego Scrum in the Big Apple

I've just got back from New York where I was attending the Big Apple Scrum Day to present a Scrum simulation session.

There were two main aims for the session, firstly and primarily to provide an introduction to Scrum for people new to the subject area but also to provide an example of a practical hands on learning experience which others may be able to use themselves in their own coaching efforts.

The basis for the session was the Lego Scrum simulation created by Alexey Krivitsky back in 2008. You can find more details on that here http://www.lego4scrum.com/. In general though, the session provides a practical learning experience, enabling participants to learn about Scrum by seeing and experiencing it in action.

We've been using a variation of this game now where I work for a while now to help create an increased awareness and understanding of Scrum across the organisation, including both technology and non-technology business areas. The response to these in-house sessions has been really positive with feedback including:

I think this concept is a great way to introduce people to the concept of Agile. It took me from very little knowledge to a position where I feel I understand the key concepts.

It was an awesome reminder of how good and simple games, executed well, can improve people's understanding of Agile (or anything, really).

The Lego workshop beautifully illustrated the focus on discrete deliverables that the business collaborates on. I also liked the emphasis on what Agile isn't.

The way it was presented, without a dry presentation, engaged me a lot more and allowed me to see how it can work in a more obvious and logical way.

On the back of this feedback I headed off to New York, with some fellow volunteers, to run the session at the Big Apple Scrum Day. The session is run broadly in line with what's outlined in Alexey's original document, with teams working to build a Lego city using the Scrum framework. Through experimentation and practice we've adapted some aspects of the simulation for our own use, with some of the main amendments outlined below.

Vision

We kick off the simulation with a vision which everything anchors back to; To build a Lego city with suitable infrastructure for healthy everyday living. This vision statement frames the rest of the simulation and is something that teams can refer back to to help guide and shape their building efforts.

Team focus areas

As per the original game all teams work to build a single city, thus it's a collaborative rather than a competitive effort. To provide as much focus as possible to each team we ask them to select a focus area e.g. housing, retail, infrastructure, energy and recreation. Each team contributes to the city according to their focus area. This also helps drive collaboration between teams as they need to work together to create a single integrated city, rather than distinct functional areas.

Dedicated Product Owners

When we first started using the Lego Scrum game one of the things we were keen to emphasise was the value that a dedicated a co-located Product Owner can add to a Scrum team. For that reason we run the simulation with a Product Owner allocated to each team. The Product Owner can then work with the team in a constant and on-going basis, highlighting the importance of continued customer collaboration through the course of a Sprint. The Product Owners are also co-facilitators, experienced in the Lego game. As such they can purposefully adopt specific behaviours and actions to draw out key learning points.

The downside to that model is that you need more than just yourself to run the workshop. For us it works, but if that isn't practical then perhaps there's a way for each team to allocate their own Product Owner. That's something that we're yet to try though.

Collaborative Product Backlog creation

Another key point that we wanted to illustrate with this simulation is the value that comes from collaborative Product Backlog generation. We wanted to avoid illustrating a scenario of the Product Owner handing over a pre-formed backlog to the team. As such, the team and Product Owner work together to form the backlog, referring back to their focus areas and the overall vision to help guide them. The Product Owner can also introduce tools such as personas to help build an increased understanding within the team of their potential end customers/city dwellers.

Learning points - revisit following retrospectives

This one is really a question of facilitation rather than game structure. At the end of each sprint, following the retrospectives, we'll take a quick look at some of the key learning points that the the simulation is trying to illustrate. These include points such as early delivery, focus on value, continuous improvement and customer collaboration. The idea is that teams, even following the first Sprint, should start to see and understand how these principles and concepts manifest themselves within Scrum. The regular reflection helps to build this understanding through the course of the game.

Global retrospective

As per the original simulation we also end our session with a global retrospective in which all teams participate. To kickstart that we give each team a few minutes to consider their overall experience. To help provoke thought and ideas we provide some broad questions that the teams can use to help support their discussion. These include questions such as how did it feel to be part of a Scrum team, what happened when the Product Owner was absent and what would you do differently if you could build the city again? Following the team team discussions we then take some time to share our insights, experiences and discussion across the whole group.

All in all the Big Apple Scrum Day session was a great success with many people seemingly inspired and enthused about both Scrum and the Lego simulation. I look forward to running many more! Finally, here's some pictures....

Improvement Mapping: Using Visualisation to Support Continuous Improvement

Visualisation is a powerful technique. In all walks of life it can aid us in achieving many things, in directing our thoughts, in becoming better at what we do and working towards our goals. Visualisation is often a mental technique but we can also use it in a more practical and physical sense. It's this practical visualisation which I explore here in terms of supporting a team's continuous improvement.

One thing I've often wondered about over the years when working with Scrum teams is how best to keep track of the agreed improvements that come out of retrospective sessions, in terms of things we've tried and their effectiveness or otherwise. How do we keep track of the possible improvements which we think might be useful, but which we won't yet implement?

At the most basic level we can include a review of the most recently agreed improvements at the beginning of each retrospective, we can keep the things that worked and ditch the things that didn't. Going forwards we can maintain a list of those things so that we can revisit and consider as appropriate to support our continuous improvement.

Long lists can be hard work and difficult to interpret though, and they're never very engaging. So I wonder whether there's a better way, a way which quickly enables the team to visualise improvements, things they've tried, things that worked and things that didn't. A way that helps increase the team's understanding of how their process is evolving. Moreover, can that increased visualisation and improved understanding be used to support a greater buy in and ownership of their process?

Impact mapping is an emerging tool used to help visualise and shape what's being developed my mapping outputs back to outcomes, i.e. features back to the required impact/value. Gojko Adzic describes impact mapping as follows:

"Impact mapping can help you build products and deliver projects that make an impact, not just ship software. Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and makes better roadmap decisions"

If we can map and visualise product deliverables back to their impact then is it also possible to map process changes back to impacts? In line with the above definition could this help us align our team activities against the overall objective of continuous process improvement?

Another pattern which I've often observed in retrospectives is a focus on the negative, or a sole focus on trying to fix the things which aren't working so well. An effect of this is that teams can often lose sight of understanding what's working well and, more importantly, why those things are working well.

Ed Catmull in his recent book, Creativity Inc, describes how one of the core principles at Pixar Animation is to understand what works well as part of making any particular film. Not just noting the 'what' but truly exploring the underlying factors that enabled that success. If we can understand something then we can be better positioned to replicate and benefit from it again in the future.

Hence if we can better visualise the things that are working well as part of our development process and we understand the impact those things are having then will we be better positioned to protect and continue to benefit from those things going forwards?

My experiments with adapting impact mapping to improvement mapping aren't at all scientific and so far are rather limited in size and scope. I look forward to developing and experimenting some more with this and will report more findings when I have them.

My feeling though is that if we can see how our process is improving, if we can visualise and understand the impact/effect that changes on the process are having, if we can use that to shape future changes, if we can be more mindful of possible changes that we haven't yet tried and if we can be more aware of what's working well and why, then overall we'll be better positioned to work effectively as a team towards the goals of continuous process improvement.

We're Agile, We're Doing Stand Ups: The Ever Persistent Cargo Cult.

I know I'm not alone with this one and it isn't anything new but thought I'd write something about it as I find it's persistent presence really quite fascinating. What am I talking about? The Agile cargo cult.

For those not familiar the term cargo cult comes from the second world war where the natives on a South Pacific island observed how the Allied forces were receiving regular deliveries of cargo. After the forces had left the island the natives wanted to continue receiving the cargo for themselves and so would elaborately copy all of the actions and routines they observed the allies undertaking. Obviously this didn't achieve anything. The natives were undertaking a reenactment of visual ceremony without understanding the real mechanisms of delivery.

You never have to look very far to find a team carrying out the equivalent with Agile software development. It's as if the mere ritual of standing together in a huddle every morning will somehow lead to a magical transformation of performance and results, obviously it doesn't. This is often accompanied by the strange assumption that some form of 'planning' every couple of weeks somehow leads to an automatic delivery of value, obviously it doesn't. Stick a cancelled Sprint demo onto the end of it all and you've got yourself a Scrummaster standing at the end of the runway looking up at the sky and unable to explain the actual reasons for lack of delivery but promising that something will show up soon. Well, it might, but nobody knows what or when.

So why does it happen? Surely it's obvious when following  a particular approach doesn't deliver any tangible benefit? Well it is - if you understand what that possible benefit is in the first place. I find many teams who's understanding of Agile starts and stops with Scrum. Actually, that statement is perhaps overly generous. Some teams have a grasp of the ceremony and artefacts of Scrum but not necessarily any real understanding of the intent behind it. So what's the fix? Better education perhaps. When teaching new teams about Agile rather than jumping straight into a particular process I think it's important to develop an understanding of Agile values, principles and ideas in general. Only once these are grasped can a team really begin to understand how to effectively utilise a particular tool or framework.

I saw a question posed a little while back (I can't remember where) asking whether it was more important to be Agile or to deliver value. I struggle to make the distinction between the two parts of the question. If you're not delivering value then I don't see how you can be Agile. Perhaps the question should ask whether it's more important to look like you're doing Agile or to be actually doing Agile and thus delivering value. If our aspirations are higher than merely implementing a cargo cult then the answer to that is surely a no-brainer.

As noted at the beginning of this post  Agile cargo cult teams have always existed and continue to do so. There has arguably been a gradual shift in thinking over recent years which poses an ironic conflict with the values of the agile manifesto. Engage someone in discussion these days about Agile development and it's likely that they'll immediately start talking about Scrum or Kanban or another specific process or methodology. Moreover, the Agile world is awash with discussion around Scrum vs Kanban, pitching them against each other as if they're unrelated in concept or intent. Based on this a newcomer to Agile could easily be forgiven for thinking that the whole thing is about process, prescription and compliance. This new way of thinking is leaving us on the wrong side of the first value in the agile manifesto:

People and interactions over processes and tools.

So what do we need to overcome the persistent problem of the cargo cult, a new way of thinking perhaps? I'd argue that we need a shift back to the old way of thinking, taking our focus back to exploring and understanding core Agile values and principles. Lose sight of these and we lose sight of the purpose of our Agile endeavours in the first place. Do that and we'll soon all be looking up and wondering where the next shipment of new functionality is coming from. Who knows, but let's hope it drops out of the sky before the next demo!

Retro Surprise

A little while back when researching new ideas for retrospectives I stumbled across Adam Wesibart's Retrospective Cookies creation.

I quite liked the idea and thought it sounded interesting and different enough to have a go at. However, I don't like fortune cookies. I find them plain and boring, and if you don't strike lucky you can find yourself chewing on something akin to cardboard. I also didn't find the price overly exciting.

So I took the idea, ran with it, fused it with my fondness for Kinder Surprise eggs and came up with what I'm declaring the Retro Surprise.

Now, this is fundamentally the same idea as the Retrospective Cookies but with a couple of differences:

- We're using Kinder capsules instead of cookies. They're reusable and will keep your costs down. The capsules contain the thought provoking questions, just like the cookies do. You can also swirl them around in a bowl, lending themselves quite nicely to the lucky dip concept.
-  The capsules also contain a chocolate reward to eat, so you get a sugary kick whilst deliberating the answers.
- Most of the capsules contain a chocolate that everyone loves. A couple though will contain one of the unpopular chocs that always get left at the bottom of the box. Times are already hard enough if you draw one of these - so you just get a declaration of 'Bad times' and things move on.
- I've got no real reason for including the above element other than it adds a bit of fun knowing there are a couple of booby prizes out there.

All in all I found this a fun and productive retrospective. The newness of the format helped keep the team engaged and we came up with some really great improvement ideas. As with any format though I think it will be important to use this as one of many approaches to keep things fresh and vibrant.

Some of the Retro Surprise capsules...

Be careful though or you could end up with a desk like this..........

Have fun!