Tuesday, May 16, 2017

The Scrum Manifesto

We are uncovering better ways of earning money by getting certified and helping others to do it.
Through this, we have come to value:

Enforcing Scrum over individuals and interactions
Proper Scrum over working software
Undisturbed sprints over customer collaboration
Meeting sprint goals over responding to change

That is, while the agile values are on the right,
the items on the left are much easier to implement.

(Careful, sarcasm)

Thursday, April 27, 2017

Shu-Ha-Ri: Can't we customize?

Let's have a short discussion on Shu-Ha-Ri and how it should affect your learning journey.
Many people feel that "This (or that) constraint isn't right, can't we remove it or try a different approach?"
Some common examples may be: "Why can't we have flexible sprint length?" - "Can't we do that step without a WIP limit?" - or even: "We need more Product Owners!"

Let's explore this matter briefly.

In the basic learner phase (Shu), every approach is rigorous and inflexible - that't the entire point of learning the basics: The constraints serve to protect.

In the advanced learner phase (Ha), the rigour no longer feels like a constraint as you already start to understand why it helps you and you've found ways to harness your potential within those constraints.

In the transcendence phase (Ri), the rigour becomes irrelevant, as you know how to achieve the ends with other means. For that, you must understand these means and the purpose they serve. Now, in the Ri phase, you may even be more rigorous than before - albeit in a different way, that may no longer have anything to do with the original form.

But ...
If you are wondering like "I think Karate hurts my muscles too much. Is Taekwondo better?" I can clearly answer that with: You'll have the same and other problems.

Refrain from the knee-jerk reaction of looking for a different "way out" and consider what you're doing wrong. Also, refrain from considering yourself in the Ri phase - if you were, you wouldn't have so many problems.

For example, a Ri practitioner may feel that Sprints are too slow - they prefer to deliver daily. Or, they don't understand the point of defining WIP limits as theirs is 1. Or, they don't even see the need to have a Product Owner at all.

They can do all those things, but they don't need to do them, because they can achieve the purpose of these practices without any effort.

If you're not there yet, you are Shu.

Friday, April 21, 2017

Changing priorities - what to do?

Taken from yet another LinkedIn post:

"My team mentioned the following: We are unable to focus on the work, resources are being borrowed mid flight, we have to wait for env to be ready for testing/deployment , priorities keep changing and worst of all ; often we hear <Our resources should give their 100%>, now how the hell can we give 100% with these constraints?"

Dear Robert,

Those are six different problems you mention there. Let's address them one by one.

#1 - Unable to focus

The more things you do, the less you can focus. It's easy to focus on one thing, yet impossible to focus on a dozen things at the same time. We lose focus when we lack clarity of what matters - and what doesn't.

Likely Causes:
  • Lack of transparency concerning value
  • Lack of clarity on the impact of multitasking on outcome
Possible Solution:
Create an environment where limited WIP is possible, encouraged and enforced. (it's always possible, the rest is management mindset)

#2 - Borrowing mid-flight

This only occurs when there is confusion in the organization on what is actually important - and why.
It doesn't even make sense to divert people from doing the most important thing they can do.
Again, that's a management mindset problem.

Likely Causes:
  • Confusion around priorities
  • Managers who are unaware of the disruptive impact of their behaviours. Closely linked to #1.
Create a stable environment where only ONE priority 1 exists at a time.

#3 - Waiting for environments

Consider the "Developer's bill of rights" - if your organization isn't willing to invest into the best possible technology, you lost the game anyway.

Likely causes:
  • Managers who forget the opportunity cost of saving a few measly bucks on tech. 
Possible Solution:
It's essential that technology is an enabler for developers, not an impediment. A company that doesn't let their developers maximize the value of their time is paying high-cost talented people for twiddling their thumbs and getting frustrated instead of delivering results.
Developers must create a plan how they would solve this and what they need, then management must grant both the procedural and financial way to move forward.

#4 - Priorities keep changing

It's very, very simple for managers to change priorities - yet very hard to get things "Done" when the priority is different before something is. 

Likely causes:
  • This is the same as #1 and #2. 
  • Manaers who are unaware of the cost of change.
Possible Solution:
Make the cost of change visible. Enforce a strict policy that any change to work which is currently in progress requires the requester to sign off the investments up to this point as "burnt money". For example, if you sunk 20 dev days into a feature already and priorities change, the requester of the new priority causes a loss of 20x10 dev-days, e.g., $20k to the organization. Ask them if that's what they want.
Accumulate burnt costs, when they approach hundreds of thousands (which they quickly do) ask if it wouldn't be better to hire more people.

#5 - Demand without enablement

There's a memorable quote, not sure I get it verbatim: "There's nothing more cruel than setting a goal without providing the means" - yet this is exactly what's described here.

Likely causes:
  • Organizational structure
    • Separation of accountability and responsibility
    • Separation of Planning and Executing
  • Management philosophy
Possible Solution:
This is a tough nut to crack and will definitely take a long time. It requires management to reconsider everything they are doing. At a minimum, managers must move from controllers to enablers - even this step can take years to be fully anchored.

#6 - De-humanization of workers as "resources"

That's entirely a mindset issue occurring in organizations where people aren't being treated as people.

Lean thinking is built on "respect for people". "Resource" in regards to people is a very dis-respectful concept that needs to be banished out of the organization, without any form of replacement. That alone will have a positive effect on motivation, morale and therefore, ability to get things done.


The good news: Those aren't many problems. They are all somehow different faces of the same coin. There is only one problem: a communication gap between managers and developers. Everything else is a consequence thereof.
At the heart of it, managers need to stop "doing manager stuff" and start talking with their people. Try to get NEAR.

A good coach can help here.

Wednesday, April 12, 2017

The 4 drivers of a holarchy

Concluding the introduction to the basis of a holarchy, let us explore briefly what drives a holarchy:

The 4 drivers of a holarchy

1 - Interaction

Interact with those around you. Build relationships.
It's not enough to interact once. You must continuously interact and communicate.

2 - Inspiration

Give others reasons to want to do what you do - or even more.
Likewise, let yourself be inspired by others.

3 - Participation

It depends on you. If you don't participate in what needs to be done, nothing will change.
Participation is not an individual matter. Align with those who pursue the same goal.

4 - Maturity

You're not perfect. Make experiences, learn from others. Seek enlightenment.
Grow as a person and help those around you grow as well.


You must constantly work on all these drivers. They depend on nobody except yourself. Maybe you will be the person with the most drive in your holon, maybe not - that's not important. Important is that you drive.

10 Principles of a holarchy

How can you make a holarchy happen? First, you need to establish the values of a holarchy to create a foundation, then you must establish the principles to make it "tick". Here are the principles of a functioning holarchy:

The 10 Principles of a holarchy

1 - Care

Care for True North. Care for what you do. Care for people around you.

2 - Leadership

Everyone leads in anything: what they do, how they think and what they believe. Servant leaders never stop to serve, enable or inspire others.

3 - Engagement

Participate. Contribute where you can. Engage others. Take responsibility.

4 - Decentral

Every holon is autonomous. There are no directed dependencies. There is no "HQ".

5 - Informal

Everything is subject to the current need. There is no prescribed form for anything.

6 - Practical

Do what works, don't what doesn't. What works in your holon may not work in another.

7 - Respect

Everyone has something to contribute. You may need to discover what that is.

8 - Non-judgmental

Just because you disagree doesn't mean they are wrong.

9 - Openness

Everybody's perspective is limited. You grow by seeing through other's eyes.

10 - Voluntary

Everything you do is your choice. Nobody must agree to anything.


These principles are not open to customization or "adjustment for pragmatic purposes". If a single principle of holarchy is broken, the entire structure is threatened. Holarchies are fragile and require continuous attention.

Establishing these principles takes years. There will be a lot of setbacks. Failure, getting up and improving are the normal. Regardless of what you see or what happens - never abandon these principles and do your best to keep them.

The 8 core values of a holarchy

In a recent post, I introduced the holarchy as an alternative organizational structure.
Let's look at the core values required to build and sustain a holarchy:

8 Core Values of a holarchy

A holarchy requires shared values. They need to be applied and maintaned without compromize, both on an individual and a corporate level.
If you do not share these values, your holarchy is already set out to fail:

1 - Clarity

First, you need a "true north".
This true north is a transparent, shared set of beliefs and a compelling vision. Everyone must be clear and aligned on the vision and these beliefs. As the vision grows out of sight just by time passing by and life taking it's course, you must continuously invest time on recalibrating yourself.
Shared beliefs need to be clearly articulated and should be as free from ambiguity as possible.

Constantly communicating these beliefs and the vision in clear and simple terms is essential to keep the holarchy going.

2 - Humility

Nobody is better than anyone else, we all are where we are. We do have different responsibilities and different perception, but that doesn't mean mine is more or less valuable than yours.
We all always lack some piece of the puzzle - and we're seeking out more pieces instead of insisting that we got it right. Be willing to be corrected at any time, by anyone, through anything.

3 - Scrutiny

Everything is up to scrutiny. Everyone should be free and willing to say "I could be wrong", or even "We could be wrong" at any time. Nothing and nobody is exempt from being questioned, by nobody, at no point in time.
That doesn't mean we need to have all the answers: It can be that we simply don't know. New information or evidence may imply that our past understanding is no longer adequate or appropriate. When this happens, we must be swift and willing to update ourselves.

4 - Purity

A holarchy relies on following the vision without compromize and being consistent in what you do.
Scrutiny should expose inconsistency, and purity means that you consequently deal with inconsistencies by resolving them to the best of your ability.
True North guides the measurement of the direction you should take. Deviation from True North is an inconsistency that you need to deal with.

5 - Equality

"Rank has its privileges" - and that creates problems. Therefore, there are no ranks and no privileges. Discrimination of people based on any factor beside their actions creates inconsistency and must be subjected to scrutiny.
Roles are transient and subject to need and may change at any time. There are only functions and responsibilities. Not even "leadership" is a role - it is something you either do or don't. It is not a label attached to a person.

6 - Unity

Seek harmony with all those who are willing to move towards True North, regardless of who, where or when. The rules and practices of the holarchy should be inclusive, yet without compromizing on True North.
Tolerate no form of division, not even with those who are just at peripheral touchpoints, such as customers, relatives, or friends. Divisions create inconsistency, and inconsistency breaks the holarchy.

7 - Sincerity

Take a stand. Act on what you believe is right. Do what you mean and mean what you do. At the same time, be willing to be adjusted by those around you. You can't refer to "the system" or "the situation" as a reason for doing something you don't believe in, as both are shaped by your own influence.

8- Responsibility

Responsibility can only be taken, not given. If you don't take it, nobody might. You yourself are responsible, so do something. You have no excuse to point at anyone for saying "They should have ..." or "But they didn't ..." , but you do have the right to lead the change by yourself.


Nobody said Holarchy is easy. These core values are essential, yet incredibly difficult to maintain. and even more difficult to establish in the first place. They are the "magnet field" for your moral compass.

You can't just transform an existing system into a functioning holarchy without first defining "True North". Not everyone will join you in your pursuit of True North, and many will find it too challenging to continue on this pursuit in the long term. A holarchy must be willing and able to continue towards True North, even if their former leaders forsake these values course and it must be ready to leave those behind who choose to become impediments towards making these values happen. A holarchy can only persist with the people who are willing to share these values and True North. Finding the right people is the first problem you need to solve.

Significant change is required to get a holarchy to work. For those who are not willing to work on themselves to live out these values, participating in a holarchy will remain a dream - insubstantial and intangible.

Friday, April 7, 2017

Product Owner: From business or from tech?

There's a never-ending debate: Should a PO be chosen from the business side - or from the technical side? Let's look into this question.

What's a Product Owner?

In short, the Product Owner is the person who is key to the product's success. They decide what is being built - and with that, they decide how the money is spent. The PO is responsible for setting the team's priority, thereby deciding how the product generates value.

This begs the question: What does any of this have to do with their position in the Org Chart?

Advantages of a business PO

The PO from a business background often tends to be closer to real users of the product, i.e., they might have a better understanding how the product contributes to the company's success. Also, due to their background, they might have a communication advantage when talking with non-technical people. This advantage can become even greater if they have already established a network with real users.

Advantages of a technical PO

The PO with a technical background might have a more sound judgment on the development cost of features. They may be better at asking the right questions which open technical alternatives to minimize the effort for meeting customer needs. Likewise, they are able to correct misunderstandings faster if developers and customer have different intentions.

What neither may bring

As mentioned above, the PO is about maximizing the value of the product. This requires a deep understanding of concepts like "value", "ROI", "cost of delay", "opportunity cost", "investment", "customer satisfaction", "growth potential", "priority" and "sustainability". 

On top of that, there are soft skills like dealing with conflicting interests, making tough choices and others. The PO requires more grit than anyone else on the team.

It doesn't matter as much what the PO did in the past - if they aren't good at the items mentioned in this section, you have the wrong PO. If they can do these things in the organization's best interests, the rest can be remedied over time.


The past of a PO, i.e. their background, doesn't matter all that much. What matters is: Does your PO have the right understanding, mindset and skillset to do their current job?
If the PO doesn't have these, they need some basic training and good coaching. That should help. Otherwise, find someone who can bring thse. Technical, business - doesn't matter.

Sunday, April 2, 2017

Q&A: Our Customer says that our software is buggy?

Question: "When a stakeholder says to the Scrum team that our application has a lot bugs although the team has a good test coverage, what could be the team's take on that?" (source)

Dear Saad,
that's a good question.

The simple answer: Tests do not guarantee high quality software. 

Many Scrum teams feel that when their DoD is met and the Product Owner has accepted their Product Increment, they are "good to go". 

They might justify their behaviour based on whatever was agreed between them and the Product Owner. That might be quite revealing if the PO is the person who claims there are bugs. That would make a great team alignment&trust topic to discuss in a Retrospective. The key question here would be: "What does justification help - does it help us earn money?"

When another stakeholder (e.g, prospective customers) evaluate the team's success, this statement reveals that team has missed something important somewhere along the line. It might be in their approach, in their DoD - or in their understanding of stakeholder needs. 

We could now get into an argument of "defect" vs. "bug" vs. "feature", but that doesn't even make sense, because we'd still have the problem of a dissatisfied customer that we want to resolve.

How should you deal with that stakeholder?
Ask them to clarify what they mean with "a lot of bugs". Let them show you examples. Pay close attention. Learn how they use the product and what is important to them. Be open-minded.There's a good chance you made past assumptions that can't be held up any more. Try to discover what you can do different in the future. 

While we can never rule out the possibility of an insane stakeholder, they are rare. Most stakeholders want a good product, although their understanding of "good" may differ from yours.

Here are some items you may need to consider:

From technical perspective:
First, you could have written the tests "around" the defective areas - and second,  there's this difference between "works as designed" and "works as intended".

From customer perspective:
When you walk into a fastfood shop and get a Chicken Burger with a glove in it, you don't care how many hygiene checks ("tests") the company has - you care for what you experienced.

Keep in mind the Agile Principle #1 "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software".
This leads to two questions:
1. Why all of a sudden "a lot of bugs"? Wasn't that stakeholder involved frequently?
2. Has the team aligned their definition of value and quality with the stakeholder?

I leave you with are a few extra questions:
  1. Do you have good tests
  2. Is your test approach adequate?
  3. What is your defect strategy?
  4. What's your approach to communication debt?

There are answers, but you need to find them by yourself.

All the best,

Saturday, March 25, 2017

Get NEAR - Reduce Communication Debt

In a recent post, I introduced the topic of Communication Debt as a pressing problem within many organizations. You might be are aware that you are suffering from communication debt, yet you may not know how to tackle it.
Here's a model to help you get a grip:

The NEAR Communication debt model

Level 1: Reason communication debt

Very often, we encounter that people discuss the tasks they are (expected to) do, yet either fail to discuss why it is important - or use bogus reasons to avoid more time-consuming and/or meaningful discussion.

Lack of reason results in religious actions, i.e., where tasks are completed devoid of deeper meaning or with a vain hope of success. The more reason debt exists within an organization, the more work is being done where nobody can truly explain why it's done. Oddly enough, reason debt results in an insecurity of what would happen if we stopped doing it - the status quo is preserved without reason!

Level 2: Assumption communication debt

We all make assumptions, all the time. Every decision we make is guided by our underlying assumptions. When our assumptions differ, our conclusions differ. What looks good based on assumption A might look stupid based on assumption B. Inconsistent assumptions can tear relationships - and therefore, entire organizations, apart.

For example, I might assume it's better to have one person have only one task at the same time, while another manager X might assume it's better to give multiple tasks to people in parallel. The way we would organize work within our sphere of control would vastly differ.
In my discussions with X, I might accuse him of causing overburden waste and X might accuse me of capacity waste - because we have different assumptions, which are caused by different understanding and different chains of reasoning.

Unspoken assumptions may result in an actor doing things that another person highly disagrees with. Until we communicate our fundamental assumptions and discover why we assume what we do, we will be hard-pressed to align.

Level 3: Expectation communication debt

Expectations decide whether our actions are considered "successful", and different expectations lead to different results. Misaligned expectations often result in blaming, resentment and frustration.

As a simple example: If X expects fast results, they might accept any kind of makeshift clutch as long as it somehow "works". Y might expect high aesthetics and a level of comfort. When working with X in the same way as with Y, X will be disappointed - and when working with Y in the same way as X, Y will be disappointed.

Missing the communication of expectations makes it impossible to meet them without resorting to assumptions (moving the problem to another level without solving it). Many organizations have learned to minimize expectations, because they have not learned to align them.

Level 4: Need communication debt

Not talking about needs results in fickle, unstable relationships - yet it's often considered "unprofessional" to spend time discussing needs. This is a very odd situation, as discovering each other's needs is fundamental to relationship building and provides the basis for any kind of negotiation.

Uncommunicated needs result in misunderstood requests, while communicating needs helps build trust and understanding. This is as true for work relationships as for private relationships.
Yet, we tend to be abysmally bad at understanding each other's needs in a corporate environment.

For example, when I say "I need a hammer", this might go through demand management, order management, vendor management and purchasing - after hours of negotiation, I end up with a bargain bin sledgehammer (at an unbeatable price) - while my original intention was to fix a poster to a wall with a few thumbtacks: my problem might have been solved with a pack of blue-tack instead.
I didn't need a hammer, I needed a way to fix that poster ...

Misunderstanding needs results in a misinterpretation of expectations, we resort to (misunderstood) assumptions and we resort to (misunderstood) reasoning for our action.

Instead of fixing this kind of communication gap, people resort to abusing communication in order to create sufficient leeway so that they can meet their own needs, often to the detriment of mutual relationships.


The longer an organization exists without fixing their communication debt, the more misunderstanding about needs, expecations, assumptions and reasons exists - every day bringing people further apart.

When you want to have better communication, get NEAR. Align needs, expectations, assumptions and reasons.

Sunday, March 19, 2017

Let's talk about Communication Debt

During a recent discussion on LinkedIn, one comment was made that we're talking a lot about technical debt - yet not about communication debt. While it's easy to overstretch the debt metaphor, communication debt arises frequently and it is at least as damaging as technical debt. In the best case, the debt is outright prohibitive, forcing us to deal with it immediately. In the worst case, we never get around resolving it until the problems are beyond redemption. So, let's take a look ...

Communication debt is the communication we should have had, but didn't.

Why is communication debt a problem?

Missing or misfired communication creates a situation where people who should be on a similar level aren't. Why is that even a problem? Here are some examples:

Example 1: Short-term debt
A Product Owner explains the feature that developers need to create. Developers can't help wondering what the user would want to do with this feature, as it is very similar to some existing functionality, except that it's more complicated.
Here, failure to communicate user needs and system capabilities resulted in wasted time, money and dissatisfied users.
Fast feedback loops make short-term debt is easy to discover. It is rather simple to resolve.

Example 2: Mid-term debt
A developer uses variable names that are optimized for typing effort. For instance, instead of naming the fields "invoiceTotal = netTotal  + taxAmount", the code reads "X = i+t".  This kind of code works, yet in order to work on the same code later, significant additional effort needs to be spent to decipher what the cryptic variables mean and why the program does what it's supposed to.

Example 3: Long-term debt
Tina is the corporate architect. When a new feature is requested, Tina is able to decide fast and correct which adjustments need to be made in which place of the corporate infrastructure. One day, Tina receives a good offer from a different company and leaves. When she is gone, the entire company falls into disarray, because nobody was on her level. For many months, people waste time with reverse analysis, trying to uncover what needs to be done.

The Impact of communication debt

As hinted in the examples above, the impact of communication debt may differ. Short-term debt is most likely to result in strongly felt reductions of effectivity, while long-term debt may be hidden until a crippling blow hits productivity.

Here are a few ways in which communication debt impacts you:

  • Confusion about the intention of tasks
  • Confusion about the purpose of things
  • Wasting time acquiring existing information
  • Wasting time discovering "missing links"
  • Not getting things done because of lacking information
  • Doing things "wrong" because of lacking information

Hints at existing communication debt

Even before you experience the impact of communication debt, you may experience hints that there may be hidden communication debt. These hints are "smoke detectors" indicating that there may be a problem:

  • Intention:
    • You don't get the point of the communication
    • You missed the point of the communication
    • You feel patronized by trivial communication
  • Value:
    • You feel you didn't learn anything after communicating
    • The information doesn't help you further
    • The information leads you in a wrong direction
  • Talking:
    • You think that you need to talk, but feel uneasy about it
    • You feel that you're talking to each other, yet not with each other
    • Conversations raise negative emotions, such as anger, indignation, contempt
  • Availability:
    • Discussions that should happen, don't
    • Important information takes time to get
    • Existing information is not available upon request

  • Meetings:
    • Status meetings
    • Meetings which cover multiple topics at once
    • High-level summary meetings with little outcome
    • Attendants that can only contribute marginally
  • Documentation:
    • Knowledge is documented rather than conveyed face-to-face
    • Things that were discussed face-to-face get documented "as proof"
    • Communication happens asynchronous via documentation hand-over
  • Tools:
    • People use tools to avoid face-to-face conversation
    • Tickets are sent among people sitting in the same office space
    • Communication gets "standardized" via templates
  • Complexity:
    • It's difficult to discover who knows someone who has the information you need
    • Information is fragmented or only partially available
    • Information requires keys (meta-information) to comprehend


Years ago, I jested: "How do you know you work in Telecommunications? Because direct communication doesn't work." Communication debt is everywhere. It happens even in the commercial and social media. It can be devastating, yet few people tackle the problem.

Saturday, March 18, 2017

The "4 Re of Complexity"

How to deal with complexity? Too often, I hear "But it's so complex". As sparked by another one of my recent posts about the often prematurely assumed need for tools, here is a small model how we should approach complexity:

The 4 "Re" of Complexity

The 4 "Re" of Complexity

Resist the introduction of more complexity

You should resist the temptation of introducing complexity that you neither have nor need. Additional complexity introduces risk and effort - you want neither. Simplicity requires actively struggling against complexity. Both effectiveness and efficiency require minimal complexity.

Sometimes, you just can't avoid complexity that you neither have nor want - for example, when it's forced on you by regulatory compliance. Still, you should do your best to prevent that complexity from creeping in. Try to do the absolute minimum necessary rather than see "what else might be needed".

Reduce the need for new complexity

Sometimes, you need additional complexity of some sort to work effectively. Maybe you think about automating a process? This increases your technical complexity in an effort to reduce the complexity of manual effort. That makes sense - as long as the complexity you add to increase the efficiency of one task should be lower than the complexity you are removing.
For example, if you would use an automated testing suite with maintenance effort higher than manual testing, it doesn't make sense to automate. You would be adding more complexity than you remove - a bad deal.

Remove unnecessary complexity

Complexity is like dust on a shelf. It just adds up over time until you can only fathom the thing you originally put into place. Processes are often religiously followed without an understanding of what is needed why. When you discover that you have complexity that could be abandoned without any detriment to your business outcome - do it.

Reinvent existing complexity

Do you remember the days when you wrote a letter on a typewriter, then printed it out, only to fax it? Why don't we do that any more? Because email achieves the same purpose much faster, easier and cheaper. Even complexity that exists in your environment can be scrutinized for improvement potential. Discovering completely new ways of achieving a goal with less effort is advancement. Chances are, if you found an ingenious solution, others will benefit, too.


Never be content with complexity. Finding ways of doing the same thing simpler is essential in order to not be overwhelmed. The "4 Re of Complexity" help you dealing with complexity in an effective manner.

Friday, March 17, 2017

Building a CI tool from scratch in one hour

Is a CI server the right answer for your team? Do you need a CI tool? "Well, that's obvious!". Is it? You may be surprised! 
This is a lesson I learned about the Agile Principle #10: "Simplicity - maximizing the amount of work not done - is essential." 

A simple CI chain, providing essential feedback to the developer

We need a CI tool

In most software development projects, someone will say the sentence "We need a CI server" - usually right at the start of development, before the first line of code is written. In an extreme case, a company paid many thousand Euros to set up a CI chain before any developer was using it. Tools like Jenkins, Hudson, Bamboo and the likes pop into mind right away. They are very good at what they do.

When I worked with one organization that had been using Atlassian's Bamboo from day 1, I talked to a senior developer who took personal responsibility to create the best possible CI process that developers could get. He jested that setting up a build chain in Bamboo required a master's study in Atlassian tooling.

This leads me to pose the question: "Do we need the complexity that a CI server creates to achieve the goal we want to achieve?"

CI isn't rocket science

In its simplest form, CI doesn't do more than retrieve the latest commit from the version control system, create a new build, deploy it - and run the tests. Developers are informed about the consequences of their actions, and that's it. Of course, complexity can be added as needed.

Do you really need a magnificient tool to do this? Is it worth sinking hours (or days) into configuring and maintaining a platform to do this trivial job for you?

My claim: You don't need a standard out-of-the-box CI tool!

How to create a CI tool

We were in a training setting. It was a Certified Scrum Developer course provided by Andy Schliep. It was fun and we were building a training application (real, working software!) in Ruby. Andy set a constraint for the Definition of Done "Works on this machine".
There was eight of us in the course creating Ruby code - so we needed Continuous Integration. In a training setting, we didn't have a CI server, nor the time to set one up. So, we reduced it to the essentials. "What do we really need from CI?"
A developer story was born.
Since we had a cool gadget from blink1, Andy added the Acceptance Criteria here: "The light must be red on a failed build and green on a successful build." Blink1's API is very simple, so we got going.
Even if we had used Jenkins, the integration with our blink1 USB light would still be an open point.

Since I love Shell, I started writing some Shell code to access the blink1 LED:
  ~/tools/blink1-tool "--$1" 2>&1 >/dev/null
This small function snipped would allow me to set the color of our blink1 LED to anything I wanted, for example, red, blue - or green.

The next thing I needed was the failure state:
  blink red
  echo "CI step failure." | log
  exit 1
Of course, I'd also need a success state, which looked pretty much the same.
Like that, I could already "fail the build".

We then brainstormed which activities we would need in our CI. We ended up with the following sequence of actions:

  1. checkout the latest code from github
  2. install the bundle
  3. clean the database
  4. run the tests
  5. start the server

If all five activities succeeded, we would call this a successful build and "pass the build".

The main control logic of our CI looked like this:

  for task in checkout install_bundle clean_db run_tests; do
  do_task $task
  ( succeed )
  do_task start_server

Of course, we still needed to fill the logic for each task step, so we did that, too. Tapping into the knowledge of my teammates as to what exactly needed to be done, I wrote functions for each task as well. It looked pretty much like this:
  git_feedback="`git pull`"
  echo "$git_feedback" | log
  [[ "$git_feedback" == "Already up-to-date." ]] && return 1
  return 0

After we had the essentials down, we started polishing the code a little, adding extra features such as turning the light blue while the build was in progress.

Everything together, we spent roughly one hour to create this "CI tool" which served it purpose. It is less than 100 lines of code and can be viewed here. Of course, I should have added unit tests - but we were content with doing every unit test manually, because this was only a training exercise and I didn't have my Shell unit testing framework at hand.


You don't need to add the complexity of "yet another platform to maintain" to your development unless there are pressing reasons. Try looking into this question: "Who needs what - and what is the minimum we need?" Talk with the team, discover the real need and find the simplest way to reach your purpose.

Only add extra tools when you have sufficient evidence to prove that a few lines of code can't meet the same purpose. Remember: Every tool adds complexity and work.

Wednesday, March 15, 2017

Permit changes to the Sprint in Scrum?

Sparked by a recent article on LinkedIn, I would like to say a few words about changes to the Sprint. Some people consider the Sprint plan sacrosanct, others want to define a rule set for changes - yet others are very open-minded about changes within the Sprint. What is a good idea, what isn't?

Is the Sprint Plan fixed?

Many teams assume that a Sprint is immutable, and the Scrum Guide advises fixing the Sprint content as well.
This provides safety and a certain level of comfort for the team. Developers know well ahead what to do. The team can reliably forecast how well they will achieve their plan with a high degree of confidence. That's the plus side.

There are a number problems with this, such as:

  1. Plans must be made upfront with a high degree of detail - possibly at a time when the best solution is not yet known.
  2. Unnecessary features ( = waste) may be delivered if they made it into the Sprint backlog - resulting in additional rework in the future
  3. Opportunities that become known during development are not monetized immediately - reducing the possible value delivery of the team

All these points are violations of the Agile Manifesto, so you should be careful with statements that "Scrum supports this". Yes, it does - but only to a certain extent, less your Scrum becomes un-agile.

There are good reasons to keep the Sprint scope fixed regardless, for instance to protect the team against whimsical stakeholders who consider "everything urgent" and who come up with "even more urgent" things on a daily basis.
Keep in mind, however, that this is a different problem from the problem which work developers do and when they fix their plan.

When is changing Sprint content a good idea?

Instead of proposing a huge rule set, there is a simple guideline: "When it makes more sense to change the plan than to pursue it" (ref. Agile Manifesto value #4: "Responding to change over following a plan")

Here are some of the main reasons when it makes sense to change - you may find others:

  1. The team decides it is so.
  2. The product is dysfunctional until the change is implemented.
  3. A stakeholder has a very urgent need and is willing to pay the price.
  4. Not making the change would damage the credibility and reputation of the team

How do we change the Sprint?

The Scrum Guide suggests "Sprint termination". A Sprint termination means: "We stop everything we're doing, end with a Retro and restart with a new planning". That may indeed be an option if the change proposal makes the entire remaining Sprint unfeasible. It may not be necessary if the upcoming change is of a lesser nature.

Here is what needs to be done, at a minimum:
  1. Estimate the change: How much of the Sprint's remaining capacity will be redirected?
  2. Re-Plan Sprint Backlog: Pull enough items out of the Sprint to fit in the change, then add the changed item.
  3. Plan the change: The change needs to be subjected to the same kind of item planning as any other item that is already within the Sprint. This may require an extraordinary planning meeting.
  4. Inform stakeholders: Some items won't be touched by the team because of the change. They may either return to the Product Backlog or be discarded entirely.

What happens after we changed the Sprint Backlog?

We shouldn't be doing that on a daily basis. It should remain a special event. At the end of the Sprint, the team reflects in a Retrospective why this change occurred.

Here are a few questions the team might want to ask:

  1. Why do we see changes to the Sprint Backlog as a problem?
  2. Why are we getting these kinds of late-and-urgent changes?
  3. Did we do our best to clarify the impact of the change?
  4. Did we do our best to minimize the effort and scope of the change?
  5. How could we have discovered this information earlier?
  6. How can we increase their agility to deal with this type of change easier in the future?

The Retrospective should result in conclusive actions for improvement.


Changes to the Sprint shouldn't be the end of the world. In a domain with high uncertainty and rapidly changing outward circumstances, change should be a normal thing. When it makes sense to change, you can not hide behind Scrum rules to justify actions that don't make sense.

Apply common sense.

Tuesday, March 14, 2017

Hierarchy or Anarchy? - A false dichotomy!

"We need a hierarchy, otherwise there would be anarchy!" - have you heard this claim, or similar claims? How can an organization function without a hierarchy? We have been taught from an early childhood to believe that the absence of hierarchy leads to anarchy, which - in turn, is utter chaos and it's impossible to achieve anything. Is that true? Having experienced a different model, I claim: No. The absence of hierarchy is not necessarily anarchy. Let me explain ...

Hierarchy - the need for prescription

A classic example of a hierarchy

What is hierarchy? Based on the original meaning of the word, it means "sacred order" - or, an order that must be maintained at all costs. A hierarchy is implicitly optimized to remain a hierarchy. This is about status, but also about achievement.

In a hierarchy, the highest person defines the goals for the entire organization. With their direct subordinates, they extract subgoals for those people - and so on. Everyone contributes to the common goal by following the prescibed personal goal and making those below them achieve their goals. The hierarchy would fail to achieve it's overall goal if anyone would deviate from their prescribed goal.

The main purpose of leaders in a hierarchy is to ensure goal alignment and goal achievement within their sphere of control.

Without this kind of prescription, the hierarchy would achieve nothing.

Anarchy - the absence of structure

Let's look at the alternative to hierarchy: anarchy.
Anarchy: The nightmare of every manager
What is anarchy? Based on the original meaning, it means "no order" - or, the absence of order. Anarchy is a highly unstable condition and implies local optimization. Achievement in an anarchy depends only on the individual.

In anarchy, everyone has their own goals and pursues them as they see fit. The outcome of an anarchy depends on the outcome of the individual. There may be common goals or common directions, but they don't mean anything. Failure to achieve personal goals doesn't affect others, so the (not existing) organization in anarchy is unaffected by individual failure or changes to individual goals.

In an anarchy, there is no leadership and no control. Goals are not aligned, achieving a goal depends on the individual alone.

Is that what we have to choose between? If it were so, human society could indeed not function without hierarchy.
But wait ... this is the false dichotomy. There is an alternative:

Holarchy - Integral parts of the Whole

In a holarchy, there is no "up and down" and no permanent structure.
Holarchy is a different model. The term means "The part and the whole are the order" - or: the order is implicit rather than explicit.

What is holarchy? It's quite difficult to understand if you haven't seen it in action. At first glance, the self-similar (fractal) structure may be considered a hierarchy, but it isn't. In a holarchy, there is nobody giving orders. There is also nobody listening to orders, and yet, people pursue a common goal. Nobody prescribes that goal, they take the goal and align around it.
A holarchy is much more effective than a hierarchy, because nobody wastes time defining goals for others and checking their accomplishment - everyone is fully focused on achieving the one, common goal.
People are not "managed" to achieve a pre-defined objective that partially contributes to an organizational goal, much rather they find others around them with whom they are better at achieving their common goal: people with whom they can share labour to achieve something better, something more, something higher than they could alone.

As activities and focus change and steps are accomplished, people's collaboration circles (holons) change dynamically. Every holon is transient and people may be part of more than one holon. Holons themselves may be part of holons. It all depends on what makes sense.

In a holarchy, leadership is different - it's as transient as the holons themselves. Holons aren't "managed", yet there are people forming holons and keeping them together, helping them move forward and joining them with one another. These people are leaders. They have no title and you may not even recognize them.


Holarchies avoid the problems of anarchy and solve the problems that are endemic to a hierarchy, making them a viable alternative to both. They have other problems, but that's a different story to be told at another time.

Monday, March 6, 2017

The "5 Co's of Teamwork" maturity model

What makes a team effective - why is teamwork more desirable than a bunch of individuals working on the same topic? This maturity model sheds some light into why we should care about a proper team atmosphere in the workplace.

Competition Level

At the first level, there is rivalry within the team. Team members have the same or similar goals, yet different ways of reaching them, and these are not considered equal. There is an idea that there is a "best way" of doing things and that only one solution is "best".

 Interactions are driven by competition, i.e. by finding ways to be better than other team members.

Team members are focused on being better than one another. They pay attention to what others do in a negative way, either to find something they can take advantage of - or a flaw they can use to put down others.

Problem solving
When one team member has trouble, this is taken as an opportunity to increase one's own standing rather than help the team produce better results.

The effectiveness of the team could be written as 1+1 <1, because the effectiveness of the team is limited by the most capable team member - and even then, that person diverts a significant portion of attention towards securing their rank rather than a beneficial outcome.
In the worst case scenario of competition we see sabotage, i.e. purposefully conducting actions that reduce the effectiveness of another team member for personal benefit.

Additional team members will exacerbate this condition, i.e. effectiveness drops as additional people enter.

Conflict Level

At the second level, team members have common - or at least overlapping - goals.

Interactions are driven by conflict, i.e. when one team member feels that another is interfering with their way of accomplishing their goal. 

Team members focus on their invividual goals, which may or may not be comaptible with those of other team members. They don't pay much attention to what others do, unless it gets into their way. 

Problem solving
When one team member has trouble, that's that person's problem and will typically be ignored by other team members unless it also causes trouble for others, in which case people often tend to consider the person as the problem.
Even when goals align, a different understanding of the same goal may lead to incompatible approaches, creating friction.

The effectiveness of the team could be written as 1+1 = 1, because the effectiveness of the team depends on how compatible individual goals are with one another. When goals are diametrically opposed, the team will spend their energy in a tug-of-war, where only the strongest person's goal will be realized. 

When a new person enters a conflicting team, their effectiveness will depend on how compatible their goals are with those of others.

Coexistence Level

The third level - a local optimum - is when team members choose a way of working that will not create conflict.

Interactions are limited to a minimum, as team members feel that interaction might reduce their own effectiveness.

Team members focus on individuals goals, which have been purposefully chosen in a fashion that is independent of others. They can choose to ignore other team members, because their work has been created to be independent.

Problem solving
Problems faced by a single person are limited to that person, the team is not the place to receive much help. Other team members feel unaffected by such a condition.
Peaceful coexistence requires a high level of respect for one another, lest the team falls back into conflict.

A coexisting team operates on a "1+1 <2" effectiveness, depending on how often team members work individually to achieve the same goal, i.e. duplicating work. In the very unlikely case that all goals are also organizational goals and do not produce an overlap, coexisting team members will be as effective as the sum of each individual. The major downside of coexistence is a slowed problem resolution.

Joining a coexisting team will drive the team members back into conflict until the new team member has found their place.

Coordination Level

At the fourth level, the team members coordinate their personal goals and approach, finding ways to increase overlap in their goals and work for mutual benefit.

Interactions are limited to goal synchronization - reducing conflict and increasing the alignment of both goals and approach throughout the achievement cycle (identify, realize, achieve).

Team members first and foremost focus on their individuals goals, yet they chose those goals in order to achieve a uniting, greater goal. Coordination implies prioritizing one's individual goals in comparison to other goals within the team, so team members need to subject their individual goals towards those of others at times.

Problem solving
Coordination requires frequent synchronization, problems get addressed at those synchronization points.
The level of synchronization points as well as the quality of discussion occurring at those points reflects the effectiveness of addressing problems. The resolution of problems then depends on the way the team chooses to address identified issues.

A coordinating team achieves "1+1 =2" effectiveness, minimizing the waste of duplication and speeding up problem solving. The downside of coordination is the time required to coordinate, which is usually more than compensated through enhanced alignment and problem solving.

Coordinating teams tend to deal with newcomers well, since they identify problems in teamwork fast and address them effectively.

Collaboration Level

At the fifth level, team members collaborate to reach shared goals. They choose an adequate approach towards reaching their goal which allows every team member to utilize their strengths. Collaboration is a prerequisite for hyperproductivity.

Interaction is a continuous condition rather than happening at discrete points, yet driven by need. Team members will "pair up" where it makes sense and work individually when there is no benefit in working together. Synchronization points lose their meaning as team members are constantly synchronized.

Everyone understands and contributes towards the team's most important goals. Each team member's activity focuses on reaching shared objectives. Collaboration requires aligning personal goals with team goals and reducing the amount of goals that are pursued simultaneously.

Problem solving
Team members use each other to overcome problems, and problem solving - like interaction - becomes a continuous state. The resolution of team problems is prioritized over individual accomplishment. Problems are readily transparent, as the need for resolution will increase interaction.

Collaborating teams will be effective at "1+1 > 2", as team members are no longer limited by their own ability. Taking advantage of synergies and bringing together strengths allows the team to achieve goals which are greater than the individuals could.

Harnessing everyone's strengths, collaboration enables teams to perform even better as new team members join. To maximize effectiveness, new team members should complement, rather than duplicate, the strengths which exist within the team.

Closing remarks

The five levels are not "clear-cut" transitions. At different times, the team may jump between those levels and individual members within the team may operate at different levels as well. This model serves as a guide for observing and classifying where the team stands and draw conclusions for potential corrective actions.

Reflection Points

  • At which level do you feel most comfortable? Why?
  • What are the key impediments preventing your team from reaching the next level?
  • Which structural elements of the organization affect your level of teamwork?
  • Which beliefs, behaviours and actions result in your team's current level?
  • What can you do to help your team reach a higher level?
  • How do you avoid getting stuck at one level?

Wednesday, February 15, 2017

Agile negotiation

What do you see in the Product Owner role? There are many aspects to the Product Owner role. Let's talk about how the work comes to the team. Many Scrum teams see their Product Owner responsible for refinement, although the Scrum Guide explicitly puts refinement into the responsibility of the team. That doesn't mean the PO can't play a valuable role in refinement. Let's talk about negotiation.

Why the Product Owner needs to negotiate

If your team is using "INVEST" as part of your Definition of Ready, backlog items should be negotiable - but why should they be negotiable if you don't want to negotiate?

In a recent post, I discussed what "user stories" actually mean, so I'll skip on full repetition.

When you work with stories, then you're talking about someone who has a problem and an interest in having a solution. On purpose, we refrain from equating problem and solution for a while - because if people knew the best solution for their problem, they probably wouldn't have it anymore.

Negotiate interests

At this point, the different interests of the different stakeholders enter the stage: 
Why is the user interested in getting this problem solved quickly? Why would developers be interested in helping? What are our financial interests? Our strategic interests? What are everyone's primary interests? How far do they overlap? What can we do to align them and reduce conflict?

Different approaches can later be weighted against each other using aligned interests as objective criteria when making decisions.

Negotiate the approach

There is always more than one way to deal with a problem. Common strategies are:

  1. Accept (do nothing)
  2. Avoid (create a work-around)
  3. Ameliorate (reduce the impact)
  4. Cover (make it invisible to the user)
  5. Resolve (eliminate it once for all)

Descending from 1-5:

  • User pain decreases
  • User effort decreases
  • Delay increases
  • Engineering complexity increases
  • Engineering effort increases
The "null hypothesis" is always that we accept the problem, i.e., don't do anything. The Product Owner can direct the approach by elaborating on optimization goals, such as: "The user can't bear with it and we need to act fast" - or "We don't have much of a budget for this, but need to make it easier for the user".

Negotiate a compromize

You will make a trade-off. Questions such as "How much pain does the user have?" can open up discussions about compromizes, such as: "If this problem only occurs once a month, we'll fix this manully next time - to have enough time for our [other important thing], then afterwards, we'll resolve it".

Any chosen path will incur costs to at least one of the factors above. The Product Owner should defer a decision until there is enough information to weigh off plausible alternatives and put these into proportion with as much objectivity as possible, 

Negotiate the solution

After aligning interests and deciding on a strategy, different scenarios can be explored. These scenarios may result in solutions that are more or less compatible with our interests. They can be weighted against each other based on such objective criteria. While tools like a Pugh Matrix tend to be overkill, the team needs to come to an agreement that is "the preferred way of solving the problem" based on the optimization goals. 
The final strategy may be a compromize of multiple approaches, such as "We'll do a quick fix now, then spend a larger amount of time later to resolve it". 

The PO, central negotiator

The Product Owner can have more than one negotiator role: 
They might negotiate business interests with customers and/or developers - they might take the role of the customer and negotiate customer interests with developers - or they might facilitate the negotiation between these (and other) parties. 


Product ( / Story) negotiation relies on four key rules:
  1. Separate people and problems
  2. Focus on shared interests 
  3. Create options
  4. Use objective criteria
Apply these four negotiation rules to discover highly satisfactory solutions.
The Product Owner is responsible that negotiation can happen - the team is responsible for making it happen. 

Negotiation opens up solutions, rather than discovering ways of shoving someone's opinion down others' throats. Negotiation is the first step towards co-creation and mutual satisfaction.

Start negotiating stories today!

Wednesday, February 8, 2017

Choosing an adequate sprint length

New Scrum teams must answer the question: "What sprint length should we choose?" Being inexperienced in Scrum, beginners often address that question to me. I have an opinion - which does not matter in itself. Let me give you the reasons why I have formed my opinion:

I advise new teams to start with 1 week sprints, because:

  1. You from new habits quicker when you have the ceremonies every week.
  2. You learn to deliver smaller batches when you MUST get some thing done within a week.
  3. The ceremonies are shorter and feel less invasive.
  4. You'll do more experimentation with the process.
  5. You get faster learning cycles.

There is another reason that may be more compelling, depending on the reasons for choosing Scrum in the first place: Team effectiveness.

Retrospectives are the Scrum ceremony where process changes are discussed. I call them "experiments", because the team is changing something they hope will work out - not something they have experience with.

If you do 1 significant process experiment per Sprint, denoting that Significant means a 5% difference in results (although this is hard to quantify), assuming half of your experiments succeed, within 1 year:

  • If you do 1 Retrospective every 4 weeks, you will be about 35% better. That will hardly be visible.
  • If you do weekly Retros, it will be about 200% better. That is a massive leap which everyone inside and around the team will notice.

Where do you want to be after your first year?

Saturday, February 4, 2017

Guide: Sprint Planning with the Task Design Board

When attending planning sessions, I often realize that teams are stumped about the idea, "What is a meaningful task?" They come up with the standard tasks, "It needs to be developed, tested, deployed" - well, that's true. Yet, it's not very value adding. And it makes the planning meeting quite boring.
Here is a suggestion how you could approach task extraction in a way that adds a significant amount of value - and fun.

An example Task Design Board

The task design board

Let's check out what a "task design board" is: Instead of hudding around a meeting table and looking at a projector, developers make their work visual. They draw a design model representing their area of work - in our case, the architecture. Then, they add task cards in places where they intend to do work, denoting what they want to change. 

Step 1: Create a model

As we discussed above, in our case, we created an architecture model. Depending on what your backlog items are, you may also look into causal-loop diagrams, entity-relationship models, flowcharts or whatever floats your boat (pun intended). The model doesn't matter - as long as everyone understands why the model is useful and agrees that the model adequately displays the problem which the team is working on.
It's important that people understand the difference between "what is" and "what will be", because that is where the work-to-do comes in. In some cases, "what we still need to explore" is also a valid option. A suggestion may be to use different colored pens or small icons to denote these differences. 

Step 2: Defining tasks

After we know where we need to do some work, we add tasks which define what work we intend to do in order to move "from here to there", i.e. to the desired future state that solves the problem at hand. In the first draft, tasks can be very crude, such as "Website" - which is enough to indicate that there's work to be done.

Step 3: Refine tasks

This step is completely optional in a cross-functional team with close collaboration. If the team consists of specialists with limited interaction points, some tasks may need to be refined in order to be "workable". Let's take our example "Website". Maybe we need to break that down into "Set up webserver", "Create HTML", "Create CSS". The key in task refinement is not to have microslices of work as much as creating task slices that can be delivered without causing handovers delays in the process. The level at which you slice is defined by the team's skill distribution.

Step 4: Slice tasks

This is yet another optional task, depending on how quickly the team delivers. To decrease the risk and impact of blockages, tasks should not take more than 1-2 days. If the team has discovered that some task cards they created are probably significantly larger than 2 days, it may be a good idea to slice them down even further using techniques such as FURPS+, Impact Mapping or Specification by Example.

Step 5: Reduce tasks

You've probably run wild creating 100 tasks for a single Sprint now. Congratulations! That was fun. Now, we need to get pragmatic: Which of these tasks are really needed - and how many of them can we even do in a Sprint? Keep value and simplicity in mind. Your most important tool in this step is the trashbin, where all tasks go that have been created in a design frenzy. 

Step 6 - Order tasks

After you know what you really want to do, put tasks into a sensible order. A few constraints in ordering will go a long way.
1 - Cluster around value: Put tasks together that result in deliverable, visible customer value.
2 - Arrange by value: Start with the clusters that deliver the highest customer value.
3 - Arrange by feasibility: Inside the cluster, first do the tasks that could be done right now, i.e. that don't have unmet prerequisites.

Step 7: Assign tasks

This step is highly arguable. I personally don't recommend doing this in Planning already - yet some teams find value in this. Take a look at the task cards and ask around who will do what
Task assignment needs a few rules to work out properly:
1 - Pull: People take tasks. Nobody is allowed to "give" a task to anyone. 
2 - Consider Capacity: Nobody should take more tasks than they are confident they can handle.
3 - Think team: Look for ways to collaborate and do tasks together in order to proceed faster.

Step 8: Confidence vote

To conclude, let everyone take a step back and take a look at the created Sprint Plan. 
Does anyone see some unfeasible tasks? Is someone overburdened? Have we missed something? 
Everyone raise their hands in a display of confidence: Can we do this?
5 fingers = Yes!!!
3 finger = I have some concerns.
0 fingers = No way.
Numbers inbetween are ok.

If we get less than 4 fingers from most team members, we should discuss and resolve the problem.


Are you fed up with boring projector shows and ineffective planning sessions?
Try the Task Design Board as a simple, effective and energetic tool to run a Sprint Planning on low-tech, tipping deeply into the brains of developers to come up with a feasible, exciting plan.

Monday, January 30, 2017

User Story Writing - what does that mean?

I keep hearing the question "How to write good/better user stories?". A quick search on Google reveals over 25 million hits, with the first page linking to Scrum gurus such as Mike Cohn and Roman Pichler, giving examples of "good user stories" and guidelines for writing them.
Let's dig deeper. You want to write better user stories? What does the term "user story" even mean?
"I don't think it means ..." courtesy of memegenerator.net

The Connextra template

As a <ROLE> I want <FEATURE> so that <REASON>
Some guys at Connextra figured out in 2001 that a good way of formulating user stories is with their template. It helped them solve their problem and now people make that a (near) essential part of Scrum.
An entire industry has been created helping Product Owners "write better user stories" based on this template. There are many good tips around, including clarity of reason, specific acceptance criteria, separation of concerns and many others. All of them miss the point. The Connextra template is an "agile template for writing requirements". Using that template will not result in a "User Story".

So, what's a user story?

As heretical as this may sound: can you imagine a user telling a story to the developers?
Someone has a problem or a need and talks about it. We decide to create software to solve this problem.

What's the PO's role in that?

The PO has the main responsibility of deciding which item in the backlog is the most valuable and therefore, should be delivered first. For this, it's a good idea to understand what the user's problem is, how big it is - and how much value the user gets from having it solved. This means you need to listen to the user and ask questions helping in the prioritization process. 
It's OK to act as a mouthpiece for the user in cases where users don't have a voice.
In other cases, the PO has the responsibility of ensuring that developers get first-hand information and a thorough understanding of the problem.

What's the team's role in that?

In Japan, there is a philosophy that it's the student's responsibility to understand their teacher. In western circles, students blame their teacher when they can't understand their teacher. Let's just say that a blame culture helps nobody - and that users often don't understand why they have the problem they are facing.
So, the team has the responsibility of figuring out what the user means. And there is no better way of figuring that out than by interacting and discussing with the very person who is concerned.
Rather than point fingers at the PO for requesting better stories, the team should learn to understand their users. 
Asking questions is a plausible way of learning. Creating common models is another. Blaming leads nowhere.


When I work as Product Owner, I'm not stuffing information into computer-aided ticket systems. And I'm not "writing user stories" at all. I create doodles. Every story card I create is a doodle. And when we get around to it, the first question my team asks is: "What do you mean with this one?
That's where the discussion starts. It ends when we're all on the same page. 


If you want to write requirement specifications, please do so. Just don't call them "user stories".
If you want to work with user stories, try telling stories and asking questions.

Tuesday, January 24, 2017

TWEAK: Willingness

When trust is given, it must be followed with a desire, a willingness. Willingness is "the other side" of motivation. Agile Development regards intrinsic motivation over extrinsic motivation, so when willingness is impeded, you must find out the root cause so that people can release their potential.
As a Scrum Master, you should consider, as taken straight from Dan Pink's "Drive":
  • Purpose: Is the product important to the:
    • Product Owner?
    • Customer?
    • Management?
    • Team?
    • Society?
    • World?
  • Autonomy: Who calls the shots on:
    • Team constellation?
    • New features?
    • Processes?
    • Technology?
    • Activities (e.g. team events)?
  • Mastery: Considering Shu-Ha-Ri. Where is the team regarding:
    • Being a team?
    • Their technology?
    • The Product?
    • The Market?
    • Agility?
Do not feel pressured to achieve full willingness within everyone, both management and the team, on day One. Moving a rather complacent individual to be highly willing may take a long time, depending on the circumstances and duration for which complacency had set in.

Thursday, January 19, 2017

Draw Toast - learn to understand each other

Have you ever wondered why it is so hard to reach a common understanding? How often do people talk about the same thing without meaning the same thing? "Draw Toast" is a fun exercise to help us reflect and learn about how we ourselves think - and how differently those around us think. Let me share with you my experience from my first-ever Draw Toast session during the Open Space of ScrumTisch Köln.

The process of making toast - which model is "right"? Mine! ... oh wait!

Stage 1: Draw Toast

I instructed the participants to each grab a sheet of paper and a pen - then "Sketch the process of making toast, starting from the package until consumption". I wrote these instruction on a whiteboard. Below that, I sketched a piece of fluffy toast. They had five minutes.
Note to self: Five minutes was too much. People started to get bored. Three would have been plenty.

Toast? Close enough.

Stage 2: Discuss

In stage 2, I asked participants to pair up with someone else and exchange the sketches. Then, I instructed: "There is no right or wrong model, they only serve to have a conversation. Every sketch is slightly different, so take a look at the differences. Ask your partner to explain the intention behind their model. For example 'I see you have this step which I don't have: why is this important for you?' - or 'You omitted this step ... why?' Two key constraints: Do not judge. Avoid statements such as 'wrong' or 'bad'. And: Try to learn something." I gave them five minutes.
Note to self: Five minutes was quite little. Maybe seven would have been better.

The room went into bubbling discussion. We did some overtime until the room was silent again

Stage 3: Reflect

In the third stage, I simply posed the question: "What did we learn ... about ourselves and about others?" and opened the discussion, jotting down bullet points.

Left: About yourself. Right: About others.

Some of the key points that came up:

About myself, I learned:

  • we make tons of implicit assumptions
  • we base our models on our own habits
  • it's really difficult NOT to judge
About others, I learned:
  • Other people's approach differs
  • "Crispy" or "warm" is a personal preference
  • Hey, this guy likes strawberry jam!

    Stage 4: Debrief

    Participants already saw that even on a very simple process like toasting, expectations and unspoken assumptions vary widely. The visible model helps us to ask questions which bring us closer together. Until we had that model, we didn't even realize how different our understanding was. An open-minded conversation is absolutely essential to reach a common understanding.
    I dismissed the group with the suggestion to reflect on this half an hour and consider how our own mental models affect how we perceive and interact with those around us.

    Personal reflection

    Conducting Draw Toast with a group of over 30 people within 30 minutes was a challenge and I was amazed it actually worked.

    I intentionally broke the process suggested by Tom Wujec because I was simultaneously experimenting with the premise of non-judgmental discussion I picked up from Marshall Goldsmith and Liberating Structures. The experiment ended well.

    The Liberating Structure "1-2-All" was extremely useful. It would have been better if I'd had enough time to take one step further into "1-2-4-All", having pairs choose one of the two models and discuss them with another pair. That would have taken another 8 minutes which would have been worthwhile.

    One point which came up during the reflection was this: The shape of the toast I presented was copied by nearly all participants. Only during reflection did one of them realize, "Hey, this is not what toast actually looks like!" With a seemingly innocent visualization, I had already instilled a thought pattern into the audience. I had manipulated their concept of "toast"!
    Afterwards, I had a discussion with another coach on this matter. He jested "If you had drawn a frying pan next to the toast, we'd probably all have integrated a frying pan into the process."
    He suggested that as a potentially interesting experiment for the future: "What happens when you give people nonsensical preconditions, then ask them to design a process around them?"
    Note to self: Got to try that in the future. Need a setting ...


    Draw Toast can be used both for team building and during Retrospectives. It's a great exercise to help people in a team understand both themselves and each other better. Using Liberating Structures, you can do this easily with an entire room full of people.

    My suggestion: Give it a try.

    Monday, January 16, 2017

    Bringing power into your Retrospectives

    Many people consider that the purpose of a Retrospective is to let the team reflect what went good or bad in the last iteration, then decide on a few significant modifications to the process. Well - that's not wrong. Yet, it's a bit short-sighted. The most powerful retrospectives transcend that level. Here are a few pointers:

    Bored of yet another Good-Bad-Improve Retro? Good!

    Fit for purpose

    Let's start out with the question: What is the purpose of a Retrospective? The obvious answer is: "To improve the process." Let's dig below the surface by asking more specifically: What determines the effectiveness of the process?

    An action is either what we do - or how we do things, You can not expect to have an effective process if it contains ineffective actions. Therefore, we desire to replace actions with more effective actions. Likewise, we like to abolish unnecessary actions. And we should harness the power of our most effective actions.

    The standard purpose of retrospectives is to improve actions of the team.

    The more things you do at the same time, the less focused your work is. The more disruptions of the work we tolerate, the less business results we create. An unfocused process generates low value even when every actions is maximized for effectivity.

    Another purpose of retrospectives might be to increase focus of the team.

    While Retrospectives are a points of reflection, they are often induced, triggered reflection. Having reflection points on the calendar is good - albeit very limited. To reduce delays in improvement, increase understanding and maximize the likelihood of successful changes, reflection needs to be an innate skill of the team.

    Retrospectives can help the team improve their reflection ability.

    Systems Thinking
    The system within which a team operates constrains the team in many ways that they may be unaware of. For example, a local optimization may make work easier for the team, yet destroy business opportunities and therefore reduce sustainability. Understanding the impact of the system on the team and the impact of the team on the system is essential to effectively improve.

    Retrospectives can foster Systems Thinking.

    Collaboration is not only how individual people do their work with proper alignment - it is how people integrate their work with each other. Just like Pair Programming combines two brains on one task, collaboration enables the team to accomplish the same thing easier, faster and better. 

    Retrospectives may open doors for better collaboration.

    A team which is coached through a Retrospective is not only conducting activities. While the coach provides tasks to the team in order to guide their reflection process, the coach has the precious opportunity to observe how the team behaves and thinks in a controlled, protected environment.

    Retrospectives are a tremendous opportunity to observe.

    A wise coach not only leads a Retrospective to a result by guiding the team through the Retrospective process, the coach actively controls the process and experiments with the social and creative dynamics of the team while doing so. This experiment generates insights into the psychological and social structure of the team, which can later be used to change behaviours.

    Retrospectives are the coach's experimentation sandbox.


    To maximize the power of your retrospectives, you need to transcend the level of simply defining improvement actions. Use Retrospectives on multiple levels at the same time to:

    • Improve the process
    • Focus the team
    • Instill a reflection mindset
    • Nurture collaboration
    • Observe the team
    • Conduct social experiments

    When planning your Retrospectives, move away from finding techniques which entertain the team while going through the mandatory frequent improvement routine. Transcend this level and look for ways to work with the team on many levels.

    The potential optimization goals of Retrospectives described in this article are not comprehensive. They are intended as a reflection opportunity to maximize the impact of your Retrospectives.

    Add power to your Retrospectives by clearly determining the goals you want to reach, then finding ways to achieve this.