I came across an article recently “Refactoring – 4 Key Principles”. Being Agile OD with a background in IT, I was fascinated. And when I read the article I thought, this should surely be applicable to other areas, such as “Organisation Refactoring”.
In the world of software development, refactoring is the process of restructuring existing computer code without changing its external behaviour. It’s about improving the internal structure of an existing program’s source code, while preserving its external behaviour. Refactoring is intended to improve the design, structure, and/or implementation of the software, while preserving its functionality.
Now, surely this applies to business and organisations in just the same way. In today’s fast-changing and unpredictable world of business, surely this is exactly what we need to do in organisations. We need to improve the internal structures, capabilities, processes, systems and roles, while preserving (and hopefully improving) the external behaviour – the solutions and service we offer to our customers.
So, I looked at the 4 principles, and here’s how I see them applying in the world of business.
Organisation Refactoring Principle #1: Keep It Small
As with software, Organisation Refactoring is safest and cheapest when it is done in many small increments rather than in large batches. The “least likely to succeed” extreme is the “big bang” approach – the complete redesign of the organisation, its capabilities, processes, and functioning. The best refactoring activities should take hours or days to execute, not months or years.
Small refactorings create constant modest change in the organisation and the work of the teams. They also allow for quick changes when necessary, provide opportunities for learning and adapting, and minimise the risk to the organisation. This then becomes a natural part of the pace of the teams – the pace of organisational change.
Organisation Refactoring Principle #2: Business Catalysts
When should Organisation Refactoring be undertaken? In short, when the business needs it. Organisation Refactoring doesn’t need to be applied organisation-wide. It can be a team, a business unit, a value stream, or any part of the business. But is driven by the needs of the business – customer behaviour change, customer demand change, current processes are not fluid enough, etc.
If the business needs a change, then refactoring should only be done on those parts of the business that are required to enable that change. In other words, don’t refactor the whole organisation, just the parts that relate to the specific business need.
Organisation Refactoring Principle #3: Team Cohesion
Teamwork requires high levels of communication and collaboration. In Organisation Refactoring work, teamwork is just as important, if not more so, than other activities.
As with software development, there are 3 levels of team cohesion in Organisation Refactoring.
- It is critical that all members of the team have a common understanding of the problem or need, and principles and purpose of the specific Organisation Refactoring.
- The next level of team cohesion relates to the tools, techniques and practices that a team uses in refactoring. Will the team use “agile” practices and ceremonies, will Design Sprints be used, how will the team communicate, what applications will be used for collaboration, meetings, etc.? These are all questions that need to be asked and answered up front to ensure that the team is able to work as cohesively as possible.
- The highest level of team cohesion in refactoring comes from collective ownership and trust. The tools and practices selected in 2 above, should be selected to enable collective ownership and trust-building, not only in the team responsible for the specific Organisation Refactoring, but also others who will be impacted by it. Shared understanding leads to self-organising behaviour in which team members make independent decisions that they know the other team members will support. It also impacts research and learning processes so that teams can do experiments and try alternatives quickly. All of which leads to the ability to do Organisation Refactoring, large and small, quickly and without fear.
Organisation Refactoring Principle #4: Transparency
Transparency in Organisation Refactoring is about being open, honest, and straightforward about everything to do with the refactoring to take place. It about sharing information about the reasons why it is needed, what processes can be used and how, who will be involved, how long it will take, how much it is likely to cost, and any other information relating to the specific Organisation Refactoring that could be relevant to the different stakeholders and stakeholder groups.
Transparency in business leads to trust, and with trust comes an increase in advocacy, loyalty, engagement, and commitment.
Summary
For Organisation Refactoring, the refactoring should:
- Be undertaken in small chunks
- In response to a business need
- By a cohesive team, and
- Be fully transparent to all stakeholders.
Well, what do you think? Can we use the concept of Refactoring for organisations, not just software? Let me know what you think.
If you would like to discuss Organisation Refactoring with us, please complete the form below and we will be in touch directly