I am curious about the efficacy of using a "hackathon" to focus development early in a new project before moving a more formal DevOps process.
Does letting things start out fast and loose to get things going hamper later efforts to add process?
If so, how does one weigh the benefits of building that early momentum vs. establishing a good DevOps process?
If the project is for a startup's minimum viable product or some other sort of sanity-check/proof of concept effort - hackathon before DevOps is often recommended - basically in the "fail-fast/fail cheap" lean startup strategy.
Some might recommend hackathon before DevOps in other situations as well, for time-to-market reasons. But if DevOps doesn't followup fast enough that initial market bridgehead can easily collapse. Possible reasons for that include:
that early momentum can be ephemeral - easily lost as soon as the DevOps process starts to be established ("it's too hard, it's slowing us down")
typically hackathons cause accumulation of technical debt. The cost of managing and eliminating it can outweighs the benefits of that early momentum.
DevOps is about the merging of information and processes between those who develop the software and those who deploy the software.
If the goal of your hackathon is to produce code which can not, or should not be deployed anywhere, then sure it makes sense to get your proof of concept (PoC) coded before developing the deployment process.
However, if you wish for a client (i.e. anybody who isn't one of the developers) to be able to view the PoC from a remote computer, then part of your hackathon already includes DevOps. To not use DevOps for a PoC or Minimally Viable Product (MVP) would be a waste of resources and time, as you work on coordinating the deploy process with operations.
DevOps will aide you in deploying more iterations of your PoC or MVP to be reviewed by more people in less time, and will thus enhance your Hackathon efforts.
Hackathons are a great way to promote people to share knowledge, collaborate, and share risk and responsibility. The traditional (non-devops) organization is often power-centric and promotes people to avoid talking directly to each other. Allowing people to only communicate to each other via their managers. This type of culture in organizations is sub-optimal for good performance, which is what DevOps all about.
The term 'power-centric' and 'generative' culture come from the R. Westrum model on how you can measure culture. The article presents a way to determine which culture your organization has, and what are the pros & cons of each type of culture (there are just three types).
From the article:
There is wide belief that organisational culture shapes many aspects of performance, including safety. Yet proof of this relationship in a medical context is hard to find. In contrast to human factors, whose contributions are many and notable, culture’s impact remains a commonsense, rather than a scientific, concept. The objectives of this paper are to show that organisational culture bears a predictive relationship with safety and that particular kinds of organisational culture improve safety, and to develop a typology predictive of safety performance. Because information flow is both influential and also indicative of other aspects of culture, it can be used to predict how organisations or parts of them will behave when signs of trouble arise. From case studies and some systematic research it appears that information culture is indeed associated with error reporting and with performance, including safety. Yet this relationship between culture and safety requires more exploration before the connection can be considered definitive.
A typology of organisational cultures by R. Westrum
The big question that DevOps researches asked themselves, is how can you take an IT organisation and transform the culture from power-centric towards generative. Hackathons are one of the definite tools that leadership can promote, which have an actual effect breaking down old ways of doing things and really changing culture.
This is why the Westrum model has been heavily quoted both in the 2016 State of DevOps Report, and in DevOps Enterprise forum guidance materials.
The PuppetLabs State of DevOps Report is a survey of more than 25k technical professionals. They were asked questions about various aspects related to DevOps. The section on "Lean Product Management", and the section on "Organizational Culture and Identity" specifically quote the Westrum model. Using it to explain how better culture is a key factor in better organizational performance.
The paper on Metrics for DevOps Initiatives at the DevOps Enterprise Forum Guidance explains how to measure culture using the Westrum model, and what organizational performance can be expected from it.
Key messages from the Westrum model:
- To be able to work with and understand organisational culture, we need a typology of organisational environments.
- Information processing style is a useful focus for such a typology, because information is important directly and is correlated with other features of the organisation’s culture.
- Three typical styles of information processing are pathological, bureaucratic, and generative.
- These styles are shaped by leaders’ preoccupations, including focus on personal needs, bureaucratic objectives, and the organisation’s mission.
- These styles are associated with different responses to signs of trouble and opportunities for innovation.
- Culture is mutable. With new leadership, an environment with one kind of culture can change into another.
Implications of Westrum model to clinical practice, most of which apply directly to IT organizations:
- Leadership in the medical unit shapes the culture, which shapes the information flow.
- Good information flow and processing has important effects on patient safety.
- In particular, an open and generative culture will mean better uptake of innovations and better response to danger signals.
- A generative culture requires that alignment, awareness, and empowerment replace suspicion, isolation, and passivity.
- A culture of conscious inquiry will assist in getting fundamental improvements to the system, rather than just quick fixes.
