The Way Agile is Fast - Fast as in Orienteering

Dear Junior

It is often claimed that agile development is faster than the alternative approaches. However, "faster" used this way might be misunderstood. For example, we all know that running can be tiring, so running faster can be exhausting. 

Does agile development mean that we will exhaust the poor developers? And do so sprint after sprint? Does it mean we induce stress ulcer? Or will the developers have to cut down on testing, design, and quality to meet this faster pace of deliver?

Quite the opposite. Agile is faster in another way. It is not faster as in a long-distance runner being faster, rather in the way an orienteering runner might be faster - by making smart choices of route.

In agile we realise that developing systems is not running down a pre-routed track. It is more alike to make our way through wild terrain. When doing this it is crucial to early see if we are moving down a dead-end route, and then stop ourselves. To run down a dead-end route without getting anywhere is the most wasteful exhausting thing an orienteering runner can do.

In agile we try to adress this at as many levels as possible. To prevent the individual developer go down a dead-end without realising it, we have pair-programming or daily stand-ups as reality checks. At a team-level we have short sprints, or watch the kanban cycle-time, to prevent us from working on stuff in a bad direction for too long. At project- or initiative level we do impacts map and similar to ensure we do stories that matter. At the level of finance/funding and portfolio management we track effects to stop us from continue spending huge effort on stuff that give no or low effect. 

So, agile does not make us faster by making us run at a more exhausting pace. Agile makes us faster by giving us tools to take smart routes, preventing us from detours.

Yours

   Dan

ps This is of course related to how Domain Driven Design makes us faster, even in the short run. Using the orienteering metaphor, what you to is to slowly jog for some a short period of time while exploring the map for different routes.

CDE and Big Brother

Dear Junior

What can a sleazy soap opera teach us about coaching agile teams and their managers?

It was somewhat a surprise to me when I realise that the reality TV show Big Brother makes a good metaphor for explaining one of my favourite models for understanding self-organised teams: the CDE-model.

The Big Brother TV-show is a non-scripted soap opera where a bunch of people are locked up in a house together and followed by cameras day and night. The "thrill" of the show is how the people interact and react upon each other.

The CDE-model is a system-theoretic model to reason about how teams self-organise as a reaction on their surrounding. Of course these reactions are very non-linear and hard to predict.

What on earth have these two things in common?

Let us put ourselves in the shoes of the Big Brother producers. Say that the events in the locked house have become a little bit dull lately. The people locked up have settled for a pace of life where they all sustain without unnerving the others. Nice for them, but not thrilling TV. We need something to happen.

The problem for us is that Big Brother is non-scripted. We cannot direct Susan to "go and snug up Jonathan", even if we think it would be an interesting turn of events. We need to find other ways to change the behaviour inside the house without giving explicit directions.

So we decide to shake them up a bit by changing the conditions under they live. A rough partition can separate three types of conditions: containers, differences, and exchanges.

Containers

One type of conditions we can change are the containers.

We can lock the yard so that they are locked indoors. That will unsettle Bob who is used to take his morning strolls there. He might have to spend his mornings in the kitchen together with Alice, who has a terrible temper before getting her coffee. Or, we can open up an extra room, one that is a little bit hidden away, with very little insight - apart from the camera of course. Or, in the middle of the night we could push in an extra wall dividing the house into two parts; let us ensure that Tom and Lisa are locked up in one part, and Toms rival Jerry in the other part. Or, we could simply remove all doors. That could be fun.

All these are examples of changing the containers that contain the contestants - making the containers bigger, or smaller, or less connected, or more connected, or even dissected. 

Containers need not to be physical, there are other ways to divide a group. We can create a competition between two teams, then the teams become sociological containers. The teams can follow some obvious partitioning like city of birth or gender, or by some arbitrary dissection. 

The important part is that containers effect the patterns of interactions, so changing containers will change the behaviour.

Of course we could interpret "containers" literarily and put them all in a freight container. That is an idea.

Differences 

Another type of conditions we can change are differences and how they are resolved.

We can stir up events by introducing differences. For example, if we have an group of contestants with the same ethnicity we can send in a new contestant of a different ethnicity, for example sending in a white guy when there are only hispanics in the house. Or send in a professor of philosophy in a house with high-school drop-outs. You get the idea.

Sending in someone fair-haired when all are brown-haired will probably not make a lot of fuzz. In Big Brother, hair colour does not make a difference to how people treat each other - at least not in a way that make a significant change. We say that we only consider "significant differences". 

It differs from situation to situation what is a "significant difference" but in general the nuance of hair-colour is not one, whereas gender is - men and women are (sadly enough) treated differently. Same goes for ethnicity, sexual orientation and lots of other traits. All those are significant differences.

Introducing or enhancing differences are sure thing to induce change, but sometimes reducing differences can also unsettle the state of things.

Let us say we want to send in one person when there are four men and one women left in the house. Sending in a man would enhance differences from 4-1 to 5-1. Sending in a women would reduce gender difference to 4-2, but would probably be more interesting.

Apart from the differences as such, we have the issue about how these differences are resolved. 

One contestant might enjoy a particular kind of music, and preferably at high volume. Another contestant might not be so fond of that particular kind of music. However, they might be able to stand each other on a day-to-day basis. The difference is manageable, handling it is not difficult.

Now we can amplify the difficulty to manage differences, for example by introducing a large amount of liquor. Should either of them get drunk, or both, it will be harder to resolve the difference in taste of music, and we will probably see some interesting conflicts. 

Another difference is food preferences, one way to amplify the effect of this difference is to insist that everybody in the house agree on what should be served for dinner. Can be fun to see how Mark "must have meat" tackles Vegan-Lisa, even more interesting when he gets hungry. 

As differences and resolving differences are a major driver for interaction, obviously changing those differences will change behaviour.

Exchanges

Third and last of the conditions are the exchanges with the outside.

If we let the contestants interact with the outside things will happen. We might let each of them have a (filmed) phone-call with a friend. Or we can have a small room where one at a time is allowed to speak to the audience. Or we might take away that room. We could put up a big TV showing news from the outside. We could fake the news we show. Surely things will happen.

Exchange need not to be communication. We can change the way food is delivered to the house; instead of small deliveries every day we make one big delivery once a week. That will cause some interesting effects at the end of the week when someone has eaten all the goodies on day one. If we are diabolic we can give them slightly too little to eat. Surely things will happen.

As exchanges are the connection between the very limited system in the house, and the very large system on the outside, it is not surprising that how the inside and outside are connected will effect the behaviour on the inside.

CDE

Of course there are a multitude of ways to unsettle the status quo in the house. However considering containers, differences, and exchanges (CDE) gives a good start to think about what leverages we can pull to cause the people in the house to behave differently. Or phrased in system lingo: to make the system reconfigure itself in another configuration.

System theory teaches us that lots of systems are dynamic and non-linear. This means that it is very hard to predict the exact outcome of a change.

As producers of Big Brother we know this. When we nudge the system in the house, we know that something will happen, but we do not know exactly what. We can have a guess, but we do not know. So, we need to be at our toes to watch out if things go another direction, and take compensating actions - or actions we hope are compensating.

Well, obviously neither you nor I are producers of Big Brother. And most probably we will never be. But same ideas can be applied to think about agile software teams that have self-organised and when coaching them or their managers. However, that is a subject which is a letter of its own.

Yours

   Dan

PS To be honest, my description does not perfectly fit how CDE was described by Glenda Eoyang in her Ph D thesis. But I think I am truthful to the main idea.

PPS Glenda Eoyang’s thesis can be read in full at http://www.hsdinstitute.org/about-hsd/dr-glenda/glendaeoyang-dissertation.pdf. A briefer introduction can be found at http://wiki.hsdinstitute.org/cde.

PPPS I think first time I came across CDE was when Mike Cohn introduced it to me during is tour when he released Succeeding with Agile, a good book for a lot of reasons and which also includes an introduction to CDE.

The Three Elements of Agile

Dear Junior

Not that I necessarily claim to be an old hip-hopper, but an interesting part of the hip hop culture is the concept of "the four elements". 

• Breaking - more commonly known as breakdance
• MC - more or less what rap is about
• DJ - you know disk-jockey
•  Graffiti - public painting

An interesting thing is that within the hip hop community it is commonly agreed that all four elements are needed. If you should take away any of them, the hip hop culture would not be whole, it needs all four of them to be complete.

Also, all the elements are on the same level. That MCing should be "higher" than graffiti, or vice verse, is an idea that would be refuted as ridiculous. All the elements are of equal importance and each indispensable. 

Obviously, the individual hip-hopper might not practice all of the elements. He or she will most probably immense in one of them. A few might practice two or three. Some might practice all four but are certainly not expected to master all of them.

Still there are a lot of respect between practitioners of the different elements: a talented MC easily gives public cred to a vicious graffiti painter. They are both needed and they would both feel poorer without the other. 

The four elements must be in balance for the hip-hop culture to thrive.

Well, that sounds all nice and cosy. But what does that have to do with agile?

I think the Agile community have a similar situation. Cutting the cake with a blunt knife I see three elements within the "agile culture": tech, process and organisation. OK, the knife is blunt so the cuts might not be perfectly clear, but I think it suffice to clarify my point.

Agile Tech consists of the technologies we have developed and use for the direct building of software. In this category we find frameworks as Hystrix for resilience; we find products as nosql-databases; we find tools as Chaos Monkey. Aside from the code we also have the close-to-code practices like Test-Driven Development, Domain-Driven Design, Continuous Integration, Build Pipelines etc. All these things enable us directly to write awesome software.

With "process" in Agile Process I simply mean "the way we work". We work in sprints á la Scrum, or WIP-limited continuous flow á la Kanban; we demo at regular intervals; we use information radiators and stand-ups to synchronise work; we make forecasts to synchronise our work with other departments; we run retrospectives after sprints and projects to have a structured learning etc; we set targets and measure progress visavi effect goals, e g using Impact Mapping.

Finally Agile organisation is about how we structure ourselves. Within teams we self-organise, sure, but this is what we do on a larger level as well. We must ensure that information propagate across the organisation in a sound way; we want the architecture to stay reasonably consistent, preferably without a command-and-control chief architect. We must also synchronise and prioritise initiatives across this organisation so we also find portfolio management and finance/funding practices like Beyond Budgeting. Last but not least we find Agile HR/Agile Talent Management as part of this element.

Each agile practitioner might not do all the elements. On the contrary, most will stay mostly within one element or have their foot-hold in one and cross over to the other. 

Comparing to the hip-hop culture I must claim that the agile community is not complete without all three elements. Doing only tech does not help us; doing only process does not help us; doing only org does not help us. Skipping any of them would hurt us.

Nevertheless I have during the history of agile I have seen competition between the element, sometimes even hostility between practitioners where one side have claimed to be the "true agile".

I think it is unnecessary and harmful.

Furthermore, I think it is unworthy of us, of a community praising "humans and interactions" over all things, a community that thinks "cross functional teams" are the superior model - should we not strive for a "cross functional community"?

In the same way as the hip-hoppers give cred across element borders I would love to see the kick-ass developer praise the agile-minded HR Director for "getting it"; I want the beyond-budgeting-inspired CFO to thank the engaged and engaging scrum master for the fantastic project retrospective; I want to see the impact-mapping business analyst to thank the devops for coming up with insightful real-time metrics about what customers actually do.

OK, I might be guilty of hippiesm here, but I want the three elements of agile to share love.

Yours

   Dan

PS One of the reasons I care so much is that deep in my heart I feel that Agile is different.
PPS There is a video in Swedish from the conference Agila Sverige 2014 where I do a blitz presentation on this subject and some related stuff.

Four Characteristics of a Good Product Owner

Dear Junior


A good product owner is hard to find — but it is well worth the effort. Once a development team start becoming agile it does not take long before the quality of the product-ownership becomes one of the most significant factors for the  productivity of the team. A good product owner works with the rest of the team to gain and uphold a high velocity. A bad product owner can slow the team down to close to a grinding halt.

I have seen several organisations that have attempted to establish a product owner role, where some attempts have succeeded and others have failed miserably. I have tried to find some way to characterise the product owners of these organisations where I have seen success. Finally I have boiled it down to four characteristics that are to some degree linked to each other.

The product owner I have come to appreciate can be summed up by being engaged, involved, decisive, and empowered.

Engaged   Involved

Decisive    Empowered

Of course, each word here have a multitude of interpretations so some explanation is needed to clarify what  I mean. I will elaborate each of them in subsequent letters, but right now I just want to try to convey the larger picture to you.

Context - Person and Organisation


One thing I find interesting with this list of four characteristics is that it contains attributes of the person being product owner as well as the organisation surrounding that person. On one hand side, being engaged and decisive are personal attributes — they come from the "inside".

Engaged   Involved

Decisive    Empowered

On the other hand being involved and empowered are attributes given by the surrounding organisation, it can let you be involved or being empowered, or it can stop you from doing so — they come from the organisation environment.

Engaged   Involved

Decisive    Empowered

So, the verticals in the matrix is about the context — personal or organisational.

Situation - Informal or Formal


In a similar manner the attributes describe how the product owner acts in different kinds of situations.  Being engaged and involved are about informal situations — day to day discussions, coming to daily stand-ups , etc. 

Engaged   Involved

Decisive    Empowered

On the other hand we have decisive and empowered. These are attributes that talk about formal situations — when there is a decision to make. The decisions are small as well as large. A small decision can be to scope a story during sprint, a large decision to say: "let's release". Disregarding small or large, those decisions are important.

Engaged   Involved

Decisive    Empowered

So, the horizontals in the matrix is about situation — informal or formal.

I definitely want to dive into each of these characteristics, but that will wait for another day.

To sum up this observation: I think this cross-section of personal-vs-organisational context and informal-vs-formal situations neatly catches most of the really important parts of what a good product owner is like, and what behaviour it leads to.

Yours

  Dan

Agile is Different

Dear Junior

From time to time I hear, see, or read how Agile is explained as "it is no news" or "it is the same old good project management, with some twists". My impression is that this is done as an attempt to make Agile less scary to make it easier to "sell" to management. I think this is a serious mistake. I think that in subtle but fundamental and important ways - at its heart and roots - Agile is different.

The difference is subtle because you cannot observe it directly. Any and all of the things you can see in an Agile-honouring organisation can easily be copied. There are software delivered in short and regular intervals, there are team retrospectives, and daily team-meeting. And all of these practises can be used in a traditionally managed organisation as well, but it does not make that organisation Agile.

To me the fundamental difference is in how you look at humans.

Traditional management use humans as building parts to build a software-producing machine, or a factory. In this machine people are the moving parts and they are strung together by a processes that dictated their interactions. At the end of the process, software emerges. It is very mechanical. For example, in this world it would be very strange if people would arbitrarily start changing the process - then the designed process might just break and who knows what would happen. So that cannot be allowed.

I might be guilty of over-exaggerating, but the practice of constantly referring to people as "resources" to me unveils an outlook on people that I find scary.

The view of humans in Agile is different. In Agile we acknowledge that it is the engagement and skills of people that make things happen. We make it a first-order concern that people should feel motivated and proud. And instead of a mechanical world view, we rely on a more organic view of organisations. If people want to change the process they are not only allowed, they are encouraged to do that — even if we do not know the precise effect it will have on the overall system.

To explain this, I think it is easiest to look at the Agile Manifesto. The first of its values is:

Individuals and interactions over processes and tools

This is not a small thing. Here lays a fundamental difference in how we look at people and organisations. A traditional process is defined by a single person at a single point of time. However, the wisdom and insight of that person at that time is nothing - absolutely nothing - compared to what can be achieved by having each involved person thinking and discussing with their peers - and doing so continuously. And if given the choice between an ever-so-well defined process on one side and trusting the wisdom of the crowd on the other hand, we chose the crowd any day of the week.

It is a little bit like democracy. We could trust a wise and benign emperor. However, we think we get a better result if all citizens engage in an open discussion. We create and change our laws according to that discussion - even if we do not know the result in advance.

In this perspective Agile is a celebration of the wonderful and mysterious system that emerge from initiatives that rise out of interaction between people that care.

This is also what can be seen in the fifth principle of the Agile Manifesto:

Build projects around motivated individuals.

Give them the environment and support they need,

and trust them to get the job done.

We actually trust that people want to work. We acknowledge that we need to give them the proper environment and tools, but that will be enough. There is no need to command and control. Things will just happen. It is a leap-of-faith to let control go. Organisations with traditional management dare not take that leap. Agile does.

So, when looking at a traditional organisation or project and comparing that one with one honouring Agile, you might not see much of a difference. But if you are inside of it, you feel the difference. It is there - at the heart. You feel trusted and empowered. And if you look closely you might see it as well - the small smile on peoples faces.

The difference is subtle. But it is fundamental. And it is important.

I am convinced that at its roots and heart - Agile is different.

Yours

Dan

Not Enforcing Architecture

Dear Junior

As I often enough take on the role of software architect (whatever that is), I am from time to time asked by other architects how I do to enforce architecture, or certain patterns, or coding conversions. They seem to see a problem that they spend a lot of energy and effort in defining these rules or guidelines, and developers in general seem not to follow the rules, so how to enforce them?

The question always takes me aback. Besides really not recognizing the scenario, I really have some trouble with the question itself, especially the usage of the word "enforce".

To start with, if you believe in that there is something like "free will", you cannot enforce anybody to do anything. From a philosophical perspective anyone is always in a position to say "no" - of course taking the consequences, but still refusing to be forced. The only way to really force someone is to ensure that the consequences are catastrophic, so that refusing is not an option. Total annihilation of mankind would be such a scenario. Or, from a personal perspective, pointing a gun to someone's head would suffice in depriving them their free will, thus enforcing some behaviour.

Well, pointing a gun to the developer's head will probably not be a feasible way to enforce some coding standard. In particular it has the drawback that you can only enforce it at one programmer at a time, or two if they are seated within arm length distance and you have two guns. Apart from that, I think it would be illegal in most countries I have worked.
So, the programmer must follow your architecture out of free will taking into consideration the consequences of not adhering. Let us get back to this later.

Secondly, the word "enforced" is normally most used in the context of "law enforcement" or "enforcing legislation" referring to the power of police, courts, and the rest of the system of justice to uphold the rules of society - which is usually considered to be a good thing. Let us pause for a moment and consider why this is considered good, even though it is a restriction of our freedom of choosing our actions. The legitimacy of the legislation in our democratic societies derives from the fact that it has been decided in an open process after careful discussion and debate between delegates elected to represent the people being governed by the laws.

So, how often does this structure apply to the relation between the architect, the architecture, and the developers? Is the architect elected by the developers in free elections, and the architecture debated and voted upon? In most of the cases when the architect asks for advice on enforcement, the answer to these questions is always "no" in my experience.

If we are to find a government system that resembles the structure of most organisations with architect and developers, it is despotism that is closest. The despot makes decisions he (most of the cases) consider wise, the subjects have no say in the question and must obey. Of the different kinds of despotism, the situation is actually best matched by a kingdom where power of the king stem from a higher power (i e a God in historic societies, and Upper Management playing that role in development organisations).

I am sorry, but if someone asks me for advice on how to enforce legislation in a system of one-ruler dictatorship - I will simply discretely not cooperate.

Back to the free will and making people follow rules. If you do not point a gun to their head, the reason for developers to follow "your" architecture is the consequences of not doing so. The architect might get angry at them, they might have an unpleasant discussion with the boss, or they might eventually be fired. Basically, they will follow the architecture out of fear. And, having seen quite a few teams in various situations I can tell, fear is not the best motivator for producing high quality software.

So, at the bottom line: I will not enforce architecture. I will not help enforcing architecture. I think it is a bad idea to enforce architecture. I think that if you want to enforce architecture you are working in the wrong direction.

Do not enforce architecture. Do not even consider doing it. Find a better way instead.

Yours

Dan

Transparancy of Business Value

Dear Junior

The story-format from Behaviour Driven Development is wonderful in many ways. I have not yet found another format that is even as close to the semantic density of

As <role>
I want <feature>
So that <benefit>.

However, I would like to dive into one particular aspect.

If you have three things collected it is often interesting to focus on two of them and pay less attention to the third. During my student years there was a joke that it was easy to be well-dressed, social, and sober - but you had to pick two out of three.

In this case we have the role, feature, and the benefit. Please play the game of focusing out the role or the feature. I want to dive into what happens if you fade out the feature itself and focus on the role and the benefit. Benefits can be measured in millions of ways, but let us make it easy for us and convert it to monetary business value. If you need help in doing that, please contact closest economist, they have a broad selection of models for company value calculations to pick from.

"As <role> (...) so that <business value>": If we look at the last part, it is a value experienced by someone - and that can be converted to money. If we look at the first part, it tells us which group will benefit. Multiply the size of the group with the value per person, and you have the potential strategic business value of the story.

As an example: last fall I discussed this during a mountain walk with Bryan Basham who work for StillSecure on the Cobia system for configuration of network nodes (e g routers). One of their stories read roughly "As a network admin I want to apply a setting to a group of network nodes, so that I do not need to configure each of them manually". So, why should a customer pay for this functionality? Well, manual repetition of the same configuration converts really easy to cost of labour hours. So, the benefit of having each network admin saving a few hours each month transfer through multiplication to a monthly reduction of costs, which through not-to-advanced economical calculations can be transferred to a now-value. Voila!

The benefit of actually putting a figure on the value of the story is that you can get clearer transparency of the business value through the organisation. When the product owner makes priorities she can have a look at the estimated value as well as the estimated cost (number of story points we will spend on implementing the story). Another way to use it could be to clear out communication with external stakeholders. E g, a seller might have gotten his will through by being the loudest shouter. However, when he is forced to set a figure of the value, he can also be held accountable if he gets the feature, but fail to deliver extra sales. It can also be fruitful for the CTO/CIO to sum up the value of all stories delivered by development in their quarterly report to the CEO. In that way it might become clear that IT development is not just "all costs"; it actually delivers business value, or at least potential value for someone else to realise into actual cash.

Unfortunately, many organisations are not brave enough to see this so clear. For some reason they prefer to see development as a cost which is funded through a limited budget, and which often do not deliver what they should.

Yours
Dan