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?

  • 3
    I think you should rephrase your question to something like "what are the pros and cons" (instead of asking for usefullness). That way you avoid the risk of your quetion being closed as "opinion based" (some may answer "great", others may answers "terrible", that's like a poll, which probably doesn't help you as an answer, right?)
    – Pierre.Vriens
    Commented Mar 6, 2017 at 12:11
  • 2
    @Pierre.Vriens Good suggestion. I've gotten a couple well thought answers so far though. If I see it start to trend polemic I'll adjust, but for now your fears don't seem to be becoming reality.
    – wogsland
    Commented Mar 6, 2017 at 12:17
  • 1
    Don't worry too much about "my" fears on this ... But I'm not sure if you are aware (= authorized to see) how many close votes your question already has. BTW: I voted to leave it open "for now" ... So maybe better not push your luck too much further? Good luck with your question ...
    – Pierre.Vriens
    Commented Mar 6, 2017 at 12:38
  • Hopefully or sadly, answers focus on the hackathon part and dismiss quite entirely DevOps is not a process management. Some process management fit better in a devops culture/organization, some less, but there's no exclusive. (Voted to skip, I've no real position on this question, sounds awful to my mind, but not close worthy and I'm unsure of what to do with it)
    – Tensibai
    Commented Mar 6, 2017 at 12:40
  • @wogsland can you focus the question towards hackathons, and move the part about process ("Does letting things start out fast and loose to get things going hamper later efforts to add process?") into another question that might deserve different answers? It doesn't really seem to be directly related to Hackathons. Commented Mar 7, 2017 at 11:33

3 Answers 3


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.