Introduction:
Empiricism (scrum) identify the three pillars as ‘Transparency’, ‘Inspection’ and ‘Adaptation’. On the face of it, these seem quite open and honest pillars. Do they allow for organisational culture that is [perhaps] not quite so clear? Is there a failure to accept the complexity of the real working environment that we call the norm?

Lets start with some simple definitions of these three pillars;

Transparency – means facts are presented and available as they are, everyone involved are open in their day to day transactions / communications and news / updates (good or bad) is made clear and available to all and with no hidden agendas. (It shouldn’t be difficult to find something out).

Inspection – refers to inspection by everyone in the team (scrum) and refers to the product, the processes, people, practices and continuous improvement and means a critical investigation with the idea to identify any improvements that can be made as soon as possible. Everyone is responsible.

Adaptation – The response to the transparency and Inspection and the changes needed to respond to the analysis.

Seems quite straightforward seeing it written down however in my own experience, this is perhaps the first and biggest stumbling block any organisation can face. The reality is always far more complex in the real world. For example, in a scrum team where does the transparency end? Do the team need to have an in depth understanding of every project that is in progress in the organisation or just the project that they are working on? How are the team and the stakeholders supposed to be transparent enough? Does ‘everyone’ need to come together on a daily bases and have a group update on every small thing the business is doing? The truth is that all this may be a possibility, it really depends on the project and just how far reaching it is for the organisation as a whole. There are no simple answers and the only way to be as clear as you can is to provide the opportunity to allow discussion.

How many of us have worked in an organisation where getting answers to questions from the organisation was harder than finding hens teeth? Some people tend to hold on to information and manage it like their secret power. You’ve heard the phrase ”Knowledge is power!”? There really are people who don’t like to share knowledge and they can be adept at justifying why this is the case to both themselves and to the organisation. It can be easy to tell yourself that it does not matter, that little bit of information but the reality is that it could be and the only person who can honestly judge that is the one person who may or may not need it. Transparency is a culture and it is really really challenging. In my experience the key here is effective stakeholder management (the subject for another blog).

Inspection is the next subject and once again it seems simple enough. The onus is on the whole team to inspect the product, the processes, the team, the outcomes like this is simply the easiest request ever. How often does something happen that was not considered and or planned for? In software development it tends to happen a lot. The developers are more than likely working on technology (code) they had nothing to do with originally and technology is always improving and changing, so how the new code will interact with the original code can be quite surprising / frustrating. Thankfully agile and lean practice have techniques to tackle inspection. Most people understand the concept of the retrospective, in my opinion, the most valuable event in scrum for many reasons. Retrospectives can be good or bad, the challenge is to make them effective. This can take time building on Commitment, Courage, Openness, Focus and Respect (those good old scrum values). Effective retrospectives will enable conversation and challenge the team. The value is identifying strategies to learn and improve.

This brings us to the adaptation. Everything up to now has little value if the adaptation phase is actioned. Identifying opportunities to improve mean nothing if there is no follow up to deliver the change needed. The key considerations here are;

a. Do we know what we need to do to make the required change and can we measure the success?

b. Can we make the suggested change (do we have the autonomy and or the desire)

c. Is there agreement (consensus) that the change is worthwhile?

d. Are we trying to make too many changes at once?

Seeing an opportunity for change does not mean the team know how to achieve it, sometimes it will take research and investment. For example I was working with a team that wanted to adapt to feature releases to achieve more frequent and safer delivery to the customer, however there were a lot of aspects needed to make this a reality including input from the business to adapt a CAB (Change Advisory Board) process to suit. There were some technical changes to the branch technology that needed to be carried out too. Is there consensus in the team? You don’t need everyone to agree but if the team make a decision (majority), then the team should work together to experiment. If one of the team disagrees because they have experienced this kind of change in the past (with another team), then this is no guarantee that in the current team it cannot work this time. Their experience may offer some valuable insights into a certain approach for example. Finally making too many changes at once is a recipe for confusion as it becomes more challenging to identify what change is impacting what. I joined a team that often did not hold retrospectives and when they did the suggestions for adaptation were numerous and the team felt pressured to record as many changes as they could because they were unclear as to when the next opportunity to adapt would come. This is where the capture of ideas and suggestions is a good starting point and the identification of the highest value change is advantageous. Creating a board where suggestions and ideas were not lost is valuable and the continual evaluation of these against new suggestions are important because you will find that some change will improve the situation elsewhere.

One final point here is that not all change is a success, some ideas fail and it is important to accept the risk and avoid any kind of blame game. By keeping changes small and reversible, you have a team that can truly be courageous and experiment with ideas and by evaluating the success (with metrics), confidence in the change can be built on.

One final note from me on metrics. Be careful with metrics, they can cause as much harm than good, especially if there is a lack of transparency on their purpose. Metrics should exist throughout the organisation to measure a variety of functions and an organisation has a responsibility to remain transparent about the what and the why. It is also important in my opinion to allow for conversation on metrics and their value because often small changes can give better results. I would also advocate the allowance for teams to work out and gather their own metrics to prove their own successes. All too often metrics in KPI’s or OKR’s can be lazily sought out to try and compare team value without the consultation of the teams involved. This can lead to a culture of mistrust if the team feel that they are being micro-managed. For example, I worked in an organisation that watched daily captured hours within a team like a hawk and clumsily used these stats to constantly question the value being provided. If a team did not capture all their hours in a day then it was an indicator that they were not doing enough work, but the reality was that they were often being pulled from their planned work to rework old code which was not being captured on a task. The team refused to create tasks for every little bit of work done to justify their existence, which I understood and that was a battle I had with management continuously.