Category Archives: Non-technical

Articles that can be understood without coding experience.

If you’re an architect, knowledge is your enemy

When a software architect gets a good idea or learns something new, he has a problem. The main job of the architect is to ensure that the right information in present inside the heads of the people who should build the application. Every new piece of information in the architect’s head represents a broader gap between his brain and that of the rest of the team.

The classical ways of adressing this gap is for the architect to write huge documents or sets of wiki pages. When they realize that there’s not sufficient time set aside in the project schedule for the developers to read all this information, the architect may present the material to developers who sit and nod their heads. But what did they really understand?

Instead of the read-listen-and-nod approach, I prefer an approach that I sometimes call “dragging the information throught the heads of the team and looking at what comes out in the other end.” I provide as little processed information as possible, but instead give the team a structured workshop to uncover and structure the information by asking me or business stakeholders. The outcomes of the workshop should be some tanglible results presented by the team. This result is always different from what I had in mind. Sometimes the difference shows a critical misunderstanding, which allows me to go more in depth in this area. Sometimes the difference represents a trivial misunderstanding or difference in opinion and the architect has the difficult task of accepting a small disgreement without distracting the team. Sometimes, the team has discovered something much smarter than the original idea of the architect.

I find it most useful to do workshops in small groups of three people per group. Each group should produce something that they can show to the whole team afterwards. Here are some examples of workshops that I run:

  • Divide in groups of three with the users/business and the developers represented in each group. Each group should discuss and fill in a template for the vision of the product being created: “For some user who performs some business function the name of system is a type of system which gives a capability related to the task. Unlike most interesting alternative our solution has an important advantage“. The groups get 10 minutes before a debrief with the whole team.
  • Each group then brainstorms a list of users, consumers and others affected by the system and write these on sticky notes. This should be about 20-30 roles. The whole team decides on a few interesting users and the groups then write down for some these: What characterizes the user, what tasks do they perform and what do they value?
  • Based on the list of tasks that stakeholders perform, we create a sketch of a usage flow. I like to refine the documented usage flow with a small task group which takes a few hours to prepare a description of the flow of interaction between the system and external actors
  • Groups of three go through the usage flow to come up with Actors (users and systems), Domain concepts (classes) or Containers (deployment diagram) mentioned or implied in the usage flow and write these on sticky notes. After showing the Actors, Concepts or Containers to the whole group, each workgroup then organizes these on flipcharts to create a Context Model, a Domain Model and a Deployment Model.

Many of these workshops can also be run with distributed groups over video conference and screen sharing.

I like to collect all of these artifacts (vision, users, usage flow, context model, domain model and deployment model) in a PowerPoint presentation so it can be easily showed by the team to external stakeholders. Sometimes someone on the team feel that photographed flipcharts with sticky notes are too informal and decide to draw something in Visio or another fancy tool. This is just a plus.

By asking the team to produce something and present it, rather than explaining the architecture to the team, I ensure that the information is really in their heads and not just my fooling myself by my own understanding.

Posted in English, Extreme Programming, Non-technical, Software Development | 3 Comments

The Rainbow Sprint Plan

Do you ever feel it’s hard to get real progress in a sprint towards the business goal? Do you feel the feedback from a iteration picks on all the details you didn’t mean to cover this sprint? Do you feel like sprint planning meetings are dragging out? Then a Rainbow Sprint Plan may be for you.

Here is an example of a Rainbow Sprint plan:

  1. A customer wants cheap vacations
  2. The customer signs up for daily or weekly notifications of special flight offers
  3. Periodically the System checks which customers should get notifications
  4. The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system
  5. The System notifies customer of any matching offers via SMS

    1. Variation: The System notifies customer of any matching offers via email
  6. The customer accepts the offer via SMS
  7. The System books the tickets on behalf of the customer
  8. The system confirms the booking by sending an SMS to the customer
  9. The customer can at any point see their active offers and accepted offers on the system website
  10. The customer enjoys a cheap vacation!

What you can see from this plan:

Use case overview: The plan gives a high-level picture of the next release. We can see how the work we are doing is fitting together and how it ends up satisfying a customer need. This is a requirement technique that is basically Use Cases as per Alistair Cockburn’s “Writing Effective Use Cases“. I’ve been writing use cases at this level for the last three years and found it to be a good way to understand requirements. The trick of good use cases is to stay at a the right level. In this example, each step is some interaction between the system and a user or the system and another system. How this communication is handled is something I find best to leave for an individual sprint.

Iterative completion: Each step has a color code:

  • Black: The team hasn’t started looking into this
  • Red: We have made something, but it’s a dummy version just to show something
  • Orange: We have made something, but we expect lots of work remaining
  • Yellow: We’re almost done, we’re ready to receive feedback
  • Green: Development is complete, we have done reasonable verification and documentation

So the plan accepts that we revisit a feature. As we get closer to the next release, things will move further and further into the rainbow. But we can choose whether we want to get everything to orange first, or whether we will leave some things at red (or even black) while bringing other steps all the way to green.

Demonstration script: When we get to the end of the sprint and demonstrate what we’ve created, this plan gives a pretty good idea of what the demo will look like: We will sign up the customer to a dummy signup page (red), we will register some flights in another dummy page (red), trigger the actual scheduling code (orange), then we will see that an SMS is received on an actual phone (yellow). Then we will simulate an SMS response (orange), see that they system made some communication to a dummy system (red), and send “ok” back as an SMS to the customer (orange). This will focus the team around a shared vision of what to do in this sprint.

I have been thinking in terms of a Rainbow Plan in my last projects, but I’ve never used the term before. I think the plan addresses three of the most common problems that I see in Scrum implementations:

  • The team doesn’t see where it’s going, because user stories are too fine grained to get the big picture. User story mapping and use cases address this, and rainbow plans put it into a sprint-context
  • The team dives into technical details during sprint planning. With rainbow plans, the sprint plan becomes the demo plan which coincides with the requirements.
  • The project has a purely incremental approach, where each feature should be completed in a single sprint. This means that it’s hard to keep the big picture and the product owner is forced to look for even small bugs in everything that’s done in a sprint. With rainbow plans, the team agrees on the completeness of each feature.

May you always become more goal oriented and productive in your sprints.

Posted in English, Extreme Programming, Non-technical, Software Development | Leave a comment

How I debrief workshops

I have tried to create a simple process for debriefing workshops. This is the current process I use, and I think it may be useful for others.

  1. I give everyone sticky notes with three colors
  2. I ask everyone to write “a thing that surprised you about the workshop”, “a thing that you learned today” and “a thing that you plan to do as a result of the workshop”. Each question goes on a different color sticky note.
  3. Everyone puts their sticky notes on a flip chart. As people come up, I read through their notes and pick out some notes that I think were interesting to discuss
  4. When everyone has put up their answers, I read up 1-3 notes about what surprised the participants, 1-3 notes about what they learned and 1-3 notes about what they plan to use it for. I comment on these results.
  5. As I end the workshop, I tell everyone “now, pick up the note with your plan as you leave the room and put it in your pocket. When you find it in the future, ask yourself whether you have completed it, or whether you should put it back into your pocket

"What surprised you", "what have you learned", "what do you plan to do"

I feel this gives a nice closure to the workshop and a drive for people to apply what they’ve learned. Have you been to one of my workshops where I had this debriefing? I’d like to know whether you used the “what do you plan” note. :-)

Posted in English, Non-technical | 1 Comment

Digital natives

  1. We were taught to categorize, but we know that searching beats sorting
  2. We were taught that information is scare, but we know that the real problem is too much information, not too little.
  3. We were taught that information must be protected from being viewed, but we know that the greatest threat to information is irrelevancy
  4. We were taught to estimate and plan what the marked wants, but we know that our customers don’t behave according to our plans
  5. We were taught to guide our customers, but we know they want to serve themselves. And they don’t want to wait for a sales clerk.
  6. We were taught to use use tools that reside on our computer, but we don’t use the same computer for long and we don’t work alone. We use tools that reside on the web.
  7. We were taught that companies are trustworthy, but we’ve learned to trust the voices of named individuals.
  8. We were taught that our value is determined by what we have, but we’ve know that our value is determined by what we give away
  9. We are the digital natives and we were not taught how to live in our world
Posted in English, Non-technical | 3 Comments

Tell a story with your project plan

This blog post is a summary of my lightning talk at XP2011

I needed to fail with modern methods for requirement gathering in order to understand old methods for requirements gathering. Many software projects write requirements in what is refered to as “user stories”. But a use story is not a story at all. There’s no drama, no action and no resolution. Instead, user stories are often just a bunch of interactions between the user and the system laying in a big heap in a shoe box. Or even worse: In an issue tracking system. Using the form of use cases, a requirement form that had failed me in the past, I have reinserted the drama into my projects.

Humans have used stories to communicate and to think about the world for as long as we’ve had language. Some elements are common to all stories: A conflict upsets the order of the world. A hero enters the scene. Through the actions of the hero, the world is set back into order and the all is well in the world.

Here is a for a project that makes a webshop, the story of desire:

  1. Some person craves stuff (the conflict)
  2. The webshop(the hero) welcomes the craving user to its front page
  3. The webshop lets the user picks stuff
  4. The webshop lets the user pay
  5. Some more stuff happens through the webshop so that the stuff is delivered
  6. Even more stuff happens
  7. The craving person gets his desire fullfilled and the world is set back to the way it was supposed to be

Not the most exciting story, you say? Well, you asked for software system requirements, not for literary masterpieces! The use case illustrates my point: A narrative lets us understand the purpose of the system (the hero) in the world and the operations the system needs to perform in order to fulfill its purpose. The first and the last step of this narrative happen without reference to the hero, setting the stage and providing the coda (look it up!), respectively. Each of the action steps between clearly states what sort of capability needs to be built for the system.

The story of desire is a made-up story to illustrate the point. Here is a simplified version of a real story in my current project – the story of disturbance:

  1. There is a disturbance in the balance of production and consumption of electricity (the conflict)
  2. Already, the system (the hero) has received from power plants information about their reserve capacity (this is a story of its own, but for another day)
  3. The system shows the Operator (the real hero!) power plants with reserve capacity
    • Variation: The operator filters the list of power plants using some criteria
  4. The system lets the Operator activate the reserve capacity at a power plant
  5. The system sends an activation request to the power plant in question so they can be activated
  6. The system shows the operator what reserves are currently activated
  7. The system lets the user deactivate reserves
  8. The system sends all activation requests to the accounting system, so the power plant can get paid
  9. The balance is restored

If you wonder why this disturbance in the force is a bad thing, take a look at my blog post about xxx. You’ll quickly see that the balance of electricity may impact whether or not my beer stays cool. Clearly an important concern.

This story is a bit messier, since it deals with more real-world problems. Together with all the details I let out, it also has the disadvantage that it will take one team about a year to develop. Our customer is a bit too eager to get some software out the door to wait for all that.

So, we present: The impatient story of disturbance

  1. There is a disturbance in the balance of production and consumption of electricity
  2. Already, the system has received from the old system we’re replacing information about power plant reserve capacities
  3. The system shows the operator power plants with reserve capacity
    • Variation: The operator filters the list of power plants using some criteria
    • Variation: The system updates the view it receives new reserves
  4. The system lets the operator activate the reserve capacity at a power plant
  5. The system sends the information about the activation to the old system we’re replacing for further distribution
  6. The system shows the operator what reserves are currently activated
    • Variation: The system shows the operator what reserves have been activated at a given power plant
    • Variation: The system displays a chart of what reserves have been activated at a given power plant
  7. The balance is restored

During the start of our project we wrote about 10 stories like the original story of disturbance. The stories were written by small gangs each consisting of developers and users or other domain experts. The gangs would swap stories and improve each others work. Meanwhile, the product owner and the project architect would try and pry apart a story so it could be delivered by a single programming team in the order of about 4 months.

For a single delivery, we would write an impatient story. Each action step or variation of the “impatient story of disturbance” became an item on the backlog of the programming team. I’ve left out about a thirds of the stories to keep the text of the blog post down. In addition, the team had about 5 technical tasks, such as performance testing. Each week, the team would deliver on average two such items.

After a few months, we have delivered the first increment in a system that tells a new story to the users, but a story they recognize. We have taken the task that they use their existing system for the most and made it easier and faster to use. The result: Happy users. And cold beer. We hope.


This approach has very much the same vision as Jeff Patton’s user story mapping and Effect maps. The approach of linear textual stories is one that works well for me. I urge you to find an approach that works even better for you. My stories use Alistair Cockburn’s style of use cases from “Writing effective use cases”, but with one changes: I simplify the writing of variations to better support the linear flow and avoid detail. They are roughly at what Cockburn describes as “kite level”.

Posted in English, Extreme Programming, Non-technical | Leave a comment

The value my system delivers: Keeping my beer cool

This blogpost is a summary of my ScanDev 2011 talk: “Fearless Improvement”

What is the goal of your current project? I currently work on a project for the transmission system operator for the Norwegian electrical grid. The value of the system we’re building is that my beer stays cool.


If you’re not skilled at what you’re doing, you may put in a lot of hours and end up having nothing to show for it. Maybe you ended up writing code that didn’t compile and you had to throw it away. Maybe you ended up staring at an empty screen for hours waiting for inspiration to strike. Maybe you ended up writing a long document, only to forget to save it and then your computer crashed.

The first trick to making sure that your work is worthwhile is to make sure that the effort you put in actually transforms to some effect. In order to achieve this, you need experience and practice with your craft.


If you don’t know why you’re doing what you’re doing, you may produce a lot, but it ends up not being valuable to anyone. Maybe the code you write solved the wrong problem. Maybe your long document didn’t answer the questions of you readers.

The second trick to making sure that your work is worthwhile is to make sure that the effect you have actually produces value. In order to achieve this, you need to move in the right direction.

skill transforms effort into effect; purpose transforms effect into value

This is the model of all human industry, whether you’re making cars, books, food, presentations or software.

In software development, effort is the time you put in, skill is your skill as a developer, effect is the working software, purpose is the architecture and value is the business goal.

The fast track to success is to understand the last step: Value.

“The other me”

Here’s an example. Find the value:

My current project creates a system which presents in user interface electricity reserves and planned electricity production that it has received from a message gateway, as well as measurements that it has received from an electricity management system.

This is gobbledygook. If this is how I see the system, I will fail.

In order to see the value, we have to take a step back. The system receives planned production and available reserve capacity from power producers. It presents this, along with measurements of the current balance between consumption and production on the electricity grid to an operator. The operator uses the reserves to regulate production to match consumption.

Hopefully, this is much more understandable. You’re probably aware that there are companies that produce electrical power, and you probably understand that electricity consumption should match production.

But why?

The ultimate value of the system is to the consumer who want to plug his appliances into the grid and have them work. They should neither blow up (too much production) or lose power (too little production).

Who is this mysterious “consumer”, then. Why, it’s me! It’s not Johannes-the-software-developer, it’s the other me. The “me” who has his fridge connected to the power grid so I can keep my beer cool.

The purpose of my project is to keep my beer cool.

The other you

To understand the purpose of your system, you should try and see how it contributes to your own life. Not the life of the “you” who develops software, but the “you” who uses electricity, the “you” who drives a car, the “you” who breathes fresh air, the “you” who wants to retire at some point in the future.

If you can’t see “the other you” in your system – take a step back and look again. If you still can’t see “the other you”, maybe you should be working on a different project.

Posted in English, Non-technical, Software Development | 1 Comment

Retrospective techniques

At the Smidig 2010 Agile User Group confererence in Oslo, I conducted an open space workshop where I tested out a few retrospective techniques on the participants.

The workshop was very well attended, and so I’ve posted a Norwegian language summary on the company blog for Steria Norway. Go check it out if you understand Norwegian!

Posted in Non-technical, Norsk | 3 Comments

The Great Wall of Architecture

As an architect for a team with a large number of people, I have a couple of problems:

  • I often make decisions that turns out to be quite crappy.
  • Even when I think I’ve written or drawn something that’s smart, it often turns out that it’s incomprehensible to everyone else

Luckily, I’ve noticed that most developers have characteristics that almost always counter these weaknesses:

  • Most developers are pretty smart, especially when they’re trying to solve a specific problem.
  • Most developers don’t read architecture documentation

So instead of trying to force the developers to read my crappy, poorly documented decisions, I decided to try to see what happened if I instead made use of the opportunities that the situation presented to me. Enter: The Great Wall of Architecture.

The Great Wall of Architecture

There are two rules for the Great Wall of Architecture:

  1. Only the pictures on the Great Wall of Architecture are officially part of the system documentation.
  2. The architect (me) cannot draw pictures to be included on the Great Wall of Architecture

As a playful addition, some of the developers have signed their work, just like we used to do in kindergarten. You can’t actually see it on the photo, but the hand writing on this diagram reads “made by Christin, 32 years old”.

Sequence Diagram

My hope is that the Great Wall of Architecture will make the whole team feel they can use their strengths on the project. As more drawings come up every day, I’m optimistic with the result.

Posted in English, Non-technical, Software Development | 6 Comments

Structuring your thinking in three easy steps

Sometimes I’m asked to write or speak about something with very little preparation. In these situations, I need a tool that can help me:

  • Organize my thoughts quickly
  • Prioritize the wheat before the chaff
  • Maintain a coherent train of thought

I find a very useful structure for archiving this to be what I call “three-by-three”: Three main points with three subpoints each.

  • Forcing myself to keep to a structure will make my thoughts flow more quickly. Coming up with three ideas isn’t hard, so I quickly get something down on paper. Limiting myself to three points forces me to cut out less important ideas, and when I can’t think of a third point at any one level, I can leave it blank, knowing that I will revisit it later
  • Using a simple cookie cutter approach allows me to spend more time with the important preparations for the talk, or the important work with the article: iterating over the points I want to make. Nothing improves a talk faster than practice. Nothing improves an article faster than reading it out loud. Deliver early and deliver often.
  • Finally, using a simple structure like three-by-thee allows me to clearly get my point across. If I’m writing an article, I can use bullet points or headlines for the points. If I give a talk, I can count down “the number of things I want to talk about” on my fingers. And with only three things to remember, the audience has an easier time following what I’m saying.

Of course, any form can be limiting, especially when you’ve worked with the material for a while. So I have some variations of the three-by-three structure that I often use:

  • Three-plus-three-by-three-plus-three: The middle part of an argument needs to be the most substantial one, so I can fractally subdivide this further into three-by-three arguments.
  • Three-times-three-plus-one: It’s often good to end on something different, a counterpoint of some sort. I often add a “zinger” to the end of a three-by-three talk
  • Let it go: As I iterate over something that started out as a simple three-by-three structure, I often find that it no longer no longer lets me express what I want. Then, as with any rule that get in the way, I break it.

I use the three-by-three structure in my workshops on how to present, as an assignment for the workshop attendants. This greatly reduces the time before they can start practicing their talks and get to that really great, quick presentation.

Posted in English, Non-technical | 4 Comments

Husk å melde deg på til Smidig 2010

Smidig 2010: Norges største smidige konferanse

Har du fått med deg at Smidig 2010 arrangeres 16.-17. November på Radisson BLU, Holberg plass i Oslo? Konferansen har åpnet for foredrag. Early bird prisen på billetter varer KUN TIL TORSDAG, så det gjelder å bestemme seg fort!

Opplev vårt unike format, med over 70 lyntaler og 100 diskusjonsgrupper! Smidigkonferansen er den årlige nasjonale hendelsen som samler mennesker fra alle typer roller i IT-bransjen; prosjektledere, produkteiere, utviklere, bedriftsledere og testere og flere.

Posted in Extreme Programming, Non-technical, Norsk | Leave a comment