WHY ORGANISATIONAL TRANSFORMATION REQUIRES TRANSPARENCY

Diabol Continuous Delivery, Digital Transformation, Lean/Agile Practices Leave a Comment

2018-04-16 CAROLINE ILIS & MARTIN LAGUS 

Start doing agile transformation, for real!


Organizational Transformation Transparency

Organisations that experience transformations, due to the change of the outside world or due to the internal reorganisations, have some important matters to put at hand. We have observed that transparency sometimes is a key factor for enabling organisations to transform. This blogpost is about transparency, why it is needed, the possible reasons and situations to why lack of transparency can occur, and suggestions how to get more transparency. We will share our thoughts on what happens if transparency is handled as a key factor, in terms of adaptation and how to become a quicker player at the marketplace.

When it comes to enabling the organisation to make the needed transformations, there can sometimes be a feeling of us and them. Especially, when it comes to responsibility and ownership. “We did this, and they need to do that. It is not our fault that they failed”. From our experience, this type of behaviour is often rooted in prejudices, a limited understanding for how others works, with what, and a lack of transparency between the different departments in the organisation - hence silos.

A typical silo culture is when people have limited insight of what is happening outside their “own” department and have very limited communication and transparency in relation to other parts of the organisations. Other signs of a silo culture can be expressed as employees reflect and express themselves in terms of “ours” and “theirs”, “we” and “them”. These type of expressions implicates that there are invisible walls between the departments (and/or groups) in the organisation. These invisible opaque walls becomes a threshold when the organisation needs to transform and adapt to the outside world. Friction between the departments is inevitable, because there are no obvious paths for communication.

For example, if a company decides to adopt continuous delivery for their software development, but doesn’t consider to change the decision-making processes for what software to develop. The result will be that, the decision-making process will slow down the end-to-end product delivery lead time of the software.

This is because, in general, all software development project must be approved by business stakeholders and stakeholders might require verified data that the product / feature will be successful (i.e. they want to know that they make the right decision), followed by a complete requirement specification.

Therefore, getting the approval to begin develop a new feature or product, can consume more time than it takes to actually code it. Consequently, the window of opportunity in the outside market can easily be missed, because of the in-effective decision-making processes, and if there is a silo culture, the business might blame IT, that it takes too much time to develop or that “wrong” feature was completed.

However, the business must understand how their decision-making process affect the end-to-end product delivery lead time, which can only be visualised through transparency. Continuous delivery is not exclusively for IT, but for the whole organisation. Without transparency in to IT and to Business, the business side won’t be able to see and realise how their decisions affect IT and IT won’t be able to see how the business assesses new ideas and products.

The lack of transparency can lead to common situations between IT and business that blocks the Agile ways of working. It is not uncommon to hear that the business side holds IT as unpredictable, not being able to deliver on time, never according to expectations, and above all, that IT project always exceeds the budget. On the other hand, from IT’s point of view, the business is incapable of submitting clear specifications, always submit late changes in waterfall-like organisations, and requests of additional features just before deployment.

Late changes and requests for additional features affect the development teams planning. A small feature that seems simple to add, could potentially require rebuilding a major part of the product and consequently delaying the whole product’s development time, making it difficult for IT to deliver on time. Of course, this is an extreme example. Today many organisations don’t run their projects in a “Waterfall manner”, but have adopted Agile methods (such as Scrum or XP).

It is not always clear, how the actions of the business and IT are associated, it is not always clear due to the lack of transparency what will happen if business pushes IT as in the former examples. How different ways of working, semantics and silos in cultures affect the overall outcomes of the company are crucial, and especially the need of transparency is crucial to see what will happen if i as a business pushes changes.

Transparency is more important than ever, and a way to create transparency is to introduce some carefully selected KPIs. KPIs are a simple starting factor, often considered as a key factor to build transparency, and give people in the organisation understanding for each other. Without asking, claiming ownership discussions, KPIs can give each other in the organisation information of the transformation being made and current situation in the organisation.

  • Created vs Resolved KPI

This is a KPI that is based on a selected area/team/department, and measures the relation between all work that is done, and not done. If this KPI is visualised in a trending fashion with separate staples, then increase of both done or “resolved” work will occur. It is possible then to see if one of these (created/”resolved” work) increases faster than the other. If the created staple increases higher than the Finished work (Resolved) that this indicates that to much work is being given to the selected area/team/department, or that the area is understaffed.

  • Time to resolution

To get an understanding of how long things take, and to investigate the time as an KPI, then Time to resolution can be a good way. Time to resolution measures from the date a work item has been created, until the work item was done/resolved. All work items resolved in a specific time period, for example a month, could get a calculated average of days of all work items resolved a specific month. Then it is interesting to compare each month and see how long time to resolution a selected area has. If this increases it might be worth to investigate why, and also if this decreases its worth to know how others work so other areas can learn from the increased speed - or if the area just has gotten less to do.

Conclusively, driving change to transform an organisation is never an easy job. Creating transparency through visualisation of carefully selected KPIs that is important for your organisation will make the people in the organisations more aware of the present situation. It will give the people a holistic view of the ongoing project, incentives and interdependencies, which in turn creates better understanding for each other and affect the company culture to become more open and adaptive to change.

Start doing agile transformation, for real!


Leave a Reply

Your email address will not be published. Required fields are marked *