<p>DevOps is about the merging of information and processes between those who develop the software and those who deploy the software.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-03-06T09:11:27.947Z
2017-03-06T09:11:27.947Z
avi
<p>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.</p>

<p>The term 'power-centric' and 'generative' culture come from the <a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1765804/pdf/v013p0ii22.pdf" rel="nofollow noreferrer">R. Westrum model on how you can measure culture</a>. The article presents a way to determine which culture your organization has, and what are the pros &amp; cons of each type of culture (there are just three types).</p>

<p>From the article:</p>

<blockquote>
  <p><em>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.</em></p>
  
  <p><strong><a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1765804/pdf/v013p0ii22.pdf" rel="nofollow noreferrer">A typology of organisational cultures</a> by R. Westrum</strong></p>
</blockquote>

<p>The <em>big</em> question that DevOps researches asked themselves, is how can you take an IT organisation and transform the culture from power-centric towards generative. <strong>Hackathons are one of the definite tools</strong> that leadership can promote, which have an actual effect breaking down old ways of doing things and really changing culture.</p>

<p>This is why the Westrum model has been heavily quoted both in the <a href="https://puppet.com/resources/whitepaper/2016-state-of-devops-report" rel="nofollow noreferrer">2016 State of DevOps Report</a>, and in <a href="http://itrevolution.com/devops_enterprise_forum_guidance" rel="nofollow noreferrer">DevOps Enterprise forum guidance</a> materials.</p>

<p>The <a href="https://puppet.com/resources/whitepaper/2016-state-of-devops-report" rel="nofollow noreferrer">PuppetLabs State of DevOps Report</a> 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.</p>

<p>The paper on <a href="http://devopsenterprise.io/media/DOES_forum_metrics_102015.pdf" rel="nofollow noreferrer">Metrics for DevOps Initiatives</a> at the <a href="http://itrevolution.com/devops_enterprise_forum_guidance" rel="nofollow noreferrer">DevOps Enterprise Forum Guidance</a> explains how to <em>measure culture</em> using the Westrum model, and what organizational performance can be expected from it.</p>

<hr>

<p>Key messages from the Westrum model:</p>

<blockquote>
  <ul>
  <li>To be able to work with and understand organisational culture, we need a typology of organisational environments.</li>
  <li>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.</li>
  <li>Three typical styles of information processing are pathological, bureaucratic, and generative.</li>
  <li>These styles are shaped by leaders’ preoccupations, including focus on personal needs, bureaucratic objectives, and the organisation’s mission.</li>
  <li>These styles are associated with different responses to signs of trouble and opportunities for innovation.</li>
  <li>Culture is mutable. With new leadership, an environment with one kind of culture can change into another.</li>
  </ul>
</blockquote>

<p>Implications of Westrum model to clinical practice, most of which apply directly to IT organizations:</p>

<blockquote>
  <ul>
  <li>Leadership in the medical unit shapes the culture, which shapes the information flow.</li>
  <li>Good information flow and processing has important effects on patient safety.</li>
  <li>In particular, an open and generative culture will mean better uptake of innovations and better response to danger signals.</li>
  <li>A generative culture requires that alignment, awareness, and empowerment replace suspicion, isolation, and passivity.</li>
  <li>A culture of conscious inquiry will assist in getting fundamental improvements to the system, rather than just quick fixes.</li>
  </ul>
</blockquote>

CC BY-SA 3.0
2017-03-07T07:03:27.673Z
2017-03-07T11:30:35.860Z
2017-03-07T11:30:35.860Z
Evgeny Zislis
<p>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" <a href="http://theleanstartup.com/principles" rel="noreferrer">lean startup strategy</a>.</p>

<p>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:</p>

<ul>
<li><p>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")</p></li>
<li><p>typically hackathons cause accumulation of technical debt. The cost of managing and eliminating it can outweighs the benefits of that early momentum.</p></li>
</ul>

CC BY-SA 3.0
2017-03-06T04:45:06.423Z
2017-03-08T02:35:47.333Z
2017-03-08T02:35:47.333Z
Dan Cornilescu
<p>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.  </p>

<p>Does letting things start out fast and loose to get things going hamper later efforts to add process?<br>
If so, how does one weigh the benefits of building that early momentum vs. establishing a good DevOps process?</p>

CC BY-SA 3.0
2017-03-06T12:11:07.780Z
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
CC BY-SA 3.0
2017-03-06T12:17:13.840Z
@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
CC BY-SA 3.0
2017-03-06T12:38:12.800Z
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
CC BY-SA 3.0
2017-03-06T12:40:29.943Z
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
CC BY-SA 3.0
2017-03-07T11:33:13.273Z
@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.
Evgeny Zislis
<culture><process>
What are pros and cons of Hackathons on implementing a DevOps culture?
wogsland
# What are pros and cons of Hackathons on implementing a DevOps culture?

(Asked by: username_0 on 2017-03-06)

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?

**Tags:** culture, process

> **Comments:**
> **username_1**: 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?)  
> **username_0**: @username_1 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.  
> **username_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 ...  
> **username_2**: 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)  
> **username_3**: @username_0 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.  

---

## 3 answers

### Answer by username_5 on 2017-03-06. Score: 9

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](http://theleanstartup.com/principles).

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.


---

### Answer by username_4 on 2017-03-06. Score: 5

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.


---

### Answer by username_3 on 2017-03-07. Score: 4

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](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1765804/pdf/v013p0ii22.pdf). 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](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1765804/pdf/v013p0ii22.pdf) 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 heusername_4ly quoted both in the [2016 State of DevOps Report](https://puppet.com/resources/whitepaper/2016-state-of-devops-report), and in [DevOps Enterprise forum guidance](http://itrevolution.com/devops_enterprise_forum_guidance) materials.

The [PuppetLabs State of DevOps Report](https://puppet.com/resources/whitepaper/2016-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](http://devopsenterprise.io/media/DOES_forum_metrics_102015.pdf) at the [DevOps Enterprise Forum Guidance](http://itrevolution.com/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.


---

