Much of thhis article refers to a 2014 paper by Michael Sahota “An Agile Adoption and Transformation Survival Guide: Working with Organization Culture“. Many thanks to Martin Sumner and Chris Jenkins for pointing out this paper and Schneider’s Cultural Model as introduced in his book from the mid 90’s. This article discusses whether both book and article have relevance to the challenges faced by Red Hat Consulting (and other open source based technology organisations) when introducing changes to working practices as well as the technology.
If there is one thing that Sahota paper highlights is that organisations are not random entities that have simply emerged, but that they are complex entities that have evolved over time. In the same way an technology provider may wish to ignore technical debt (mode 1 oiltankers) and focus on new projects (mode 2 speedboats), the argument is that by focusing on changing ways of working only for new project is one way of circumventing this complexity. Sahota is making the case (and agreed much of uses evidence from 2010) that ways of working and culture are two different things. Simply changing the ways-of-working without understanding the dominant culture of an organisation will lead to failure. As Red Hat has seen, unless process and culture is examined and addressed, alongside the introduction of new technology, then an organisation will face significant challenges.
Over the last couple of years, Red Hat like many software companies and their customers have introduced Innovation Labs and have also taken culture and organisations more serious when looking at technology adoption. Red Hat Consulting has established a Value From Technology organisation to do look at this is situ, as well as propose better ways of working in the lab.
What this paper and related work highlights is that:
* understanding the organisational culture is key (Schneider’s model is the approach discussed)
* you need to fit the right software development / engineering approach to fit this overridding organisational culture
* as well as development approaches, readiness and willingness for open source adoption is also predetermined by the type of organisational culture.
Sahota’s paper has a host of interesting links on other papers on the success and failures around Agile, though he rightly points out this might be reflective of where Agile is on its journey on the hype cycle. Whether in the last 4 years Agile has emerged from the Trough of Disillusionment or not is a good subject for discussion and one that’s not core to this blog post.
Sahota points out that Agile is indeed a culture (it has values and beliefs), as are Kanban, Scrum and XP, though the latter are seen more as processes. You live and breathe a culture, while you more ‘simply’ do a process or method. Scrum and Kanban can be done to their rules (or as with Monopoly, some variant of the prescribed rules).
Therefore as a culkture, Agile needs of certain type of Schneider defined cultural model to exist inorder to be successful. Schneider identified 4 cultural types that would be prevalent in an organisation, none worse of better than the others.
Control
Cultivation
Collaboration
Competence
Sahota makes the case that you need to understand the case for cultural compatibility to see if Agile adoption will work and suggests that Kanban and Software Craftmanship (otherwise known as the Land that Scrum forgot) will fit the gaps for organisations that don’t have a Collaboration or Cultivation Culture.
As part of it’s Value From Technology programme, Red Hat Consulting has created a very straightforward assessment tool, Ready to Innovate (RTI) as a means to look at those areas beyond technology. As part of that it looks at Automation, Methodology, Architecture, Strategy and Environment. Agile and the software development approaches would be assessed as part of the discussion around Methodology, and DevOps in Strategy. As you move around the spider chart in a clockwise direction you move away from technology, through process and into culture.
Over the last 18 months, through conversations with customers that the need to understand culture and to ensure that the right approach for new technology adoption is applied has become key. What you see is that as go round the RTI diagram clockwise from the top, is where practical, technology things need to be in place (automation) in order to push changes, whilst the later criteria like environment are essential to pull these changes through. The later criteria are more complex and also organisational wide.
What is becoming clear, whilst you can apply processes and changes in a Lab, the very nature of the Lab is that it’s a clean environment so are you fundmentally changinge a culture. Before applying it in the wild, you need to understand the existing environment you are putting it into. With RTI, we’re beginning to start to evaluate the environment (the people and the way they work), but this is an evaluation based on a single premise. This premise is from the assesor and as Schneider’s model shows there is no one right model and that infact none of the four cultures are wrong. What is wrong is trying to force certain processes and organisational structures in to the wrong culture, without taking necessary steps to preserve it.
For example, you may practice elements of Agile in the Lab, but these are completely blown away when the Lab is over; you need to ringfence or protect the new fragile ways of working of Agile to ensure it is nurtured. However at the same time, the Lab may not have taken into account all the factors that were going to be encountered and some adjustement made.
Because of the ‘big’ questions Red Hat and other companies are being asked it is sometimes simpler to be prescriptive; provide a proven solution that works with another customer. In this way organisation politics and siloes, technical debt and legacy processes can all be put to one side. The ‘speedboat’ or mode 2 application isn’t held back by these constraints but is it then real ? If you are innovating around software development or IT architectures, this has to be end the organisations innovation, not one solely provided by a third party. It needs reference.
As Red Hat looks at it’s own Open Organisation, it also needs to consider if that is the right approach for another organisation; it’s not something that’s going to work for every organisation. As with Agile, it might be than certain organisations cannot become fully Open Organisations, but they can adopt parts of it.
As the diagram suggests, any organisation that is primarily a Control organisation it’s unlikely that it won’t become an Open Organisation and that whilst some parts of the open source approach will fit, some others won’t. However, using a Labs approach for innovation may work well in a Control organisation as it may ensure correct measurement of the results and sharing of the outcomes.
As with Agile, any ‘open sourcing’ of an organisation will need assessment and then selective application of different tools to make them work. In assessing the organisation, Schneider’s questions (in the book) are a good place to start and based on some pilot work, whilst you may not get a clear favourite being selected, you have an indication of the organisational culture. The data was collected using a Google Form and then processed using the Sheet behind it. While these was only a n=17, it did show a leading cultural trend of Cultivation, followed by Collaboration then Control followed up by Competence.
This can be transposed onto Schneider’s model and possible scenarios for development open source mapped to them. The next part of the write up with look at the possible scenarios for open source development and how they might be applied and their impact measured.
