In the past I wrote about holocracy and self managing teams as a system of balance, stressing mutual interest propagating overall business goals like in feudal society. All teams are driven by a purpose of providing a certain service to some other entity or to the final customer. Teams specialise in a functional domain. Coordination between teams is done through a team delegate participating in the team meetings of teams for which they have a client or provider relation.
Large Scale Scrum (LeSS) is a methodology for developing products along the lines of SCRUM adapted for scaling. It depends largely on focused teams directed at customer, product or product feature, functioning with minimal or no management overhead. Member teams work together at realising a complex product for a business represented by what is called a Product Owner in SCRUM. Coordinating happens through participation of a team members in each others team. A team is tasked with developing a component or better a feature that fits in the overall product and therefore they have to understand what is needed by the business team/unit that will be using the software product supporting their processes. As such it applies the same philosophy as Holocracy but adapted for software or ICT departments.
As holocracy teams are oriented at certain products or customer groups there should be a match with the product or feature teams identified in the software development LeSS teams. This match will ensure better understanding, efficiency as well as continuity in the development and direction of development.
When applying the logic fully, it means pairs are formed between business and ICT teams. In some cases the product provided by the ICT group might cover different customer channels, customer target groups or products addressing the clientele or at least parts of it. It might lead to priority discussions. However, relations between both sides of the story are clear. The lines of communication are short and priority discussion can be held in a transparent way with all parties involved present. Pairing will improve focus, direction and understanding of needs of both customer and the people providing the necessary services. Integrated working will avoid the need of translating business needs to IT requirements. The Product Owner as linking pin is part of the business team who understands due to proximity better than ever how development of software solutions work. The IT team will understand the needs of the business team better as they have a structural and long term relationship with the business team(s) they support even when stories are rather vague and lack information about the technical implementation of the request.
The functional focus will require a mix of technical skills and requires knowledge sharing on this level. Therefore, the creation of functional/product clusters should not lead to new silos. Technical oriented communities of practice covering the technology used within the organisation should provide a space for sharing knowledge and experiences concerning development practices and infrastructural issues related to deployment and system management. Alternatively people with specialist technical knowledge can be delegated to participate in development of a feature team to bring them up to speed. In this way one can avoid the reflex existing in current organisations to build technology oriented teams focusing on technical components that tend to live in their world having a hard job understanding business needs.
Pushing the envelope further, a good understanding between business and ICT teams can and will lead to more innovative products and fundamental digitalisation of business processes and customer interaction. The SCRUM methodology stresses the importance of the Product Owner as the person representing the business needs and thus piloting the development team laying out priorities and explaining the underlying reasons for a requested functionality. The relationship is mainly one directional, resulting in smaller incremental changes than what would be able to achieve when ICT potential would be used at its potential. Often scanning incoming documents is positioned as process digitalisation, actually it hardly changes anything more than facilitating the communication of the document through the process. Using a structured data entry form at the start of the process would permit instant data quality controls with the possibility to change and enhance data on the spot. Other examples can be imagined resulting in better use of digital technology. This potential often is not recognised by non tech savvy people concerned mainly with coping with the incoming work volume.
Establishing a tight relationship between ICT and business teams will most certainly enhance business performance when the purpose is clear and bidirectional communication facilitating the creation of added value. Therefore all talents should be used in an environment of mutual willingness to understand participants having different backgrounds.