What is an organisation’s culture?

A few posts ago, I discussed how Culture eats process for breakfast, but what is “culture”?

At the time, I had the simple approach of “what was there before”. However, and from experience, that is difficult to figure and codify! Where does one start? Who do you ask? What are the parameters for this “organisational culture”? And then, how do you evolve it?

Well I found a partial answer at “Three Bell Curves“, where you can download a document titled “Business Culture Decoded”. In that document, the author describes three bell curves (of course) that helps you understand where lies the culture of your organisation as well as how you can look at its improvement. The author also admits that this is not an easy thing to do, but since culture trumps process, if you change the culture, you will affect the process and, hopefully, get better results!

Agile stories, architecture, and religious processes

In his article titled “Stop Telling Stories“, Jim Bird highlights many points that have always made me uncomfortable about agile user stories, as well as describing how their usage came about. For those who are not aware, user stories are intentionally short description of what a user needs out of a system and why it is needed. Instead of detailed requirements for a system’s feature, they are often a short sentence that is then used to elicit more detailed information from a user (or product owner, but there are some concerns about “product owners” as well).

The section about “Don’t Get Hung Up on User Stories – Do Whatever Works“, addresses a particular case of one my generic pet peeves: blindly following what some experts/process tells you is the right thing to do as part of your process (see my blog entry “Culture eats process for breakfast“). I especially liked the quote in the referenced blog entry:

“stories are not enough. They are just one tool, a usage view. There are so many more options”
(Scott Ambler, Agile 2013 conference)

A process is not a religion, you are allowed to adapt it to your own culture and environment, and it must be subject to constant validation, just like it is stated in the last agile principle (which I still think Wikipedia got slightly wrong…) – regardless of what your guru/consultant/spiritual adviser tells you!

The other undertone of that blog entry is about the completeness of the product requirement if one only looks at user stories. Users stories can help you elicit the users’ needs (although you still have to be careful to differentiate their needs from their wants…), but it is not the whole story. How do you address non-functional requirements in user stories? How do you address existing architectural constraints? Note that these are not limited to user stories, but many of the agile (or “Agile”) processes, except for the Scaled Agile Framework, sometimes seem to ignore this. I would also recommend you read Philippe Kruchten’s take on Agile Architecture for a very opinion on that topic!

It’s good to see that in these cases of quasi-religious adoption of processes, there are still some critical thinkers out there!

Culture eats process for breakfast

Éminence Grise has a great posting with the same subject line as this entry (in fact, he has a bunch of great posting…). I am taking the liberty to extend his discussion in my own forum.

This discussion relates to a keynote address  by Henrik Kniberg at the Paris Scrum Gathering (2013.09.23). I have not had the chance to see the keynote in person, but the presentation is very informative – I wished I could have been there in person.

Nevertheless, the content of the PDF presentation was very good and interesting. I would almost say that it should be required reading by process implementers, but they may not like the content (;-)!

My take on this is that people, especially process implementers (read: management) always forget that there is already a process in place, an undocumented (sometimes) one based on the culture of the organisation. Once you understand that, you also have to realise that there is a process to change the process, and forcing a process upon a cultured organisation is not the way to do it! What we need then is (dare I say it) measures and feedback (a.k.a., retrospectives).

I have been through a work situation where a decision to impose a development process led to a failed regulatory inspection – a failure that could have been avoided if we had started from what was there. Imposing a process into an existing culture (and there always is an existing culture) will only create problems,

The Agile Manifesto had it right, but even agilists have a tendency to push their formalised agile “process” (e.g., XP, Scrum) and you are not doing it right if you don’t follow the rules!

Many have a tendency to only look at the manifesto and to skip the underlying principles. But we especially can’t forget Agile principle #12: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” We must remember that this is the basis of any work going forward – that it is where we must start to document our culture (a.k.a., our process 😉 before any new process is considered.


Jordi Cabot has an interesting Blog on Modeling Languages. In it (an on LinkedIn) there was a discussion recently on the difference or similitudes between MDA, MDD, and MDE. It’s interesting that Wikipedia treats the last two as the same thing – I like Jordi’s description better.

However, as I read Jordi’s blog posting, I found that his explanation certainly makes sense and is probably correct nowadays, in a more modern sense of the terms.

However, “MDD” has been used for quite a long time to describe model-based (as opposed to model-driven) development. That use of the term would not fit within the definitions presented by OMG as part of MDA (e.g., the CIM/PIM/PSM levels of abstractions and transformations). I suspect that this approach may also still be in use today – although probably not the best way of working with models. This may especially be true of some of the model uses seen in “agile” approaches.

So perhaps there is a need, in the diagram shown on that blog, to also have a model-based development (MBD?) circle that would intersect with MDD, but not the others?

All this also can not be discussed without mentioning the standards, processes, and methods (and the effect of tools on these) surrounding these approaches. Models need to have a standard representation to be useful – and the UML (and SysML) is certainly one that is common these days. However, other notations such as BPMN, ERD, etc., should not be discounted as they represent interesting domain specific modeling languages – and not all can be easily expressed using UML . Tools are too often viewed as a panacea to what ails software development – when they can be a hindrance when one does not understand the standards, processes, and methods they support.