context is the most important consideration for any organisation engaged in a Organisational Agile Transformation. Most teams of seven plus or minus two are fairly similar. The issues they face are fairly common and are fairly well served by established Agile practices like Scrum, Kanban and devOps (The new popular brand name for eXtreme Programming). Once you move beyond the team, the organisational context starts to play a bigger and bigger role. This means that as an IT Risk Manager, you need to manage the risk that failure occurs due to context. You need to understand the risk that a practice may work in one context but not in another. In other words, in which contexts is it safe to employ a practice, in which contexts do you need additional tools, and in which contexts is the practice likely to fail.
The Agile Community is an important tool for managing the risk due to the context. The Agile Community is a tightly knit, highly connected group of practitioners who communicate with each other about new ideas and contexts. Anyone can join the community provided they put in the effort to get to know the people involved. Although the strongest relationships are between those who meet face to face at meetups and conferences, there are plenty of on-line communities that are easy to join. The highly connected nature of the Agile community means that it is possible to connect people with a question “What problems did ABC have implementing XYZ” with the people with the answers “At ABC, we did not have a problem because of DEF. Solving DEF is your hardest problem.”. Often the material is in the public domain (e.g. on InfoQ, Vimeo or YouTube) if you know where to find it.
The Agile Community is the repository of all the failure stories that happened before the successful practice was discovered. Having access to these failure stories is incredibly valuable, especially as organisations modify practices and tools in order to make them work in their context. The principles and values help, but sometimes trial and error across a distributed community is the only way to succeed. Its not that the Agile Community hides its failures, its just that a book that says “We tried this and it did not work, we then tried this and it did not work,… and after ten attempts we came up with blah” is much harder to consume than one that says “Do blah, it works”. Think Edison and the light bulb, you get the idea.
The trusted nature of the Agile Community means that members are often aware of failures that are not necessarily in the public domain. One of the filters I apply when recruiting coaches who advocate a certain approach is their attitude to a less well known failure applying that approach. If they are not aware of the failure, they may not be as well connected as they think… and if they are aware of the failure but do not care, they are probably in the community of solutions rather than the community of needs. All coaches need to be in the community of needs, prioritising the organisation that pays them over their desire to promote their pet practice or tool.
The Agile Community is also a fantastic place to seek advice on how to make experiments safe to fail. They do this by sharing the cautionary tales (failure again) and offering feedback on things to watch out for.
High Quality Agile Product and Service Companies employ many highly connected and respected members of the Agile Community. Ronica Roth, Eric Willike and Martin Burns at Rally, Robert Holler and Olav Maassen at Version One, Dennis Stevens and Mike Cottmeyer* at LeadingAgile, Too many to mention at ThoughtWorks and BJSS. These individuals only work for these companies because the companies have a strong Agile pedigree. Their personal reputation and brand means that working for an Agile Industrial Complex company would lead to personal loss of (social) value and effectiveness within the network.
Agile Industrial Complex tend to hire Agile experts on a transactional basis. Often the people they hire have lots of qualifications but they are not trusted members of the Agile Community. This means that the coaches they provide to their clients do not have access to the richness of the shared memory of the Agile Community. This means that context becomes a big risk. Their coaches know the practices and tools, but they do not necessarily know where those practices and tools fail because they have only accessed Agile through the community of solutions (Training Courses). Junior coaches will often work in the Agile Industrial Complex as they build their own experience and personal brand.
Not all of the coaches in an organisation need to be members of the Agile Community, however if none of them are, you are exposing your organisation to context risk.
Thank you to Guy Winterbotham for inspiring this post with his comment yesterday.
*Mike Cottmeyer, what can I say. Highly connected but….remember Agile2009? đ
December 20th, 2016 at 2:08 pm
I was so very surprised and am so very honored for the mention. This blog helped me understand what type of community you were talking about. Thank you for the opportunity to participate.
Might I add another type of community that I was thinking about. One specific to and built around the Context. A Community of Possibilites. One which stems from the organizational needs but grows based on conversation about “valuing gifts and possibility over needs and problems” as Peter Block outs it. I think the Community of Needs with all they can bring to emerging Communities of Possibility within organizations offers an alternative path to the “Agile Industrial Complex”.
April 9th, 2017 at 2:33 pm
[…] However, that is not enough. They need to use their existing employees and coaches to manage context risk. Get their team to attend conferences and find out the real stories behind the success. Understand […]
April 15th, 2017 at 2:30 pm
[…] You will need to set up a portfolio of “safe to fail” experiments. Experiments that tell you the best place to apply LESS, the best places to try SAFE and DAD and Nexus. The best places to organise using the Spotify Model and the best to organise using the Buurtzorg Model. In order to make the experiments “safe to fail” you will need to speak to people with real experience of applying these approaches so that you can learn about the known failures. You won’t find out about failures from a sales brochure or a shiny powerpoint. You find out about them from people who trust you. […]
April 17th, 2017 at 4:57 pm
[…] How to build a learning network that extends beyond their organisation so that they can learn from other organisation’s failures. […]