Optimizing the whole with the strategy and the vision

In the past year I have played and studied chess more or less active. It has been interesting to see how strategy game chess actually is. As well chess is fun to play I have also found interesting relation to software product development.

In both “games” I have found one of the best approaches first doing strategy, then planning and  executing it in small pieces. Let’s take a closer look why I think strategy is important.

Software development and vision

A vision is strategic document in software development. Document usually contains description from the problem and vision from the solution. It also declares in which boundaries solution needs to be implemented.

In other words in the vision you set up strategy how customer problem will be solved.

Based on vision you can start to create more detailed plan like product backlog or functional requirement lists, adjust priorities and then execute it.

Advantages of strategic thinking in chess

chessboardIn chess strategic thinking means you are building a plan which you can follow and finally win a game. That plan is not step by step moves to the victory. It’s rather vision about which weaknesses and strengths to guide you through the game. The game can be in situation when it’s better to attach, switch pieces or even to sacrifice a piece to get better position as opponent has.

Without a long term plan in chess your chances to win are not good. It’s not possible to count all variations which opponent might play. It’s too complex. And if you just move based on opponent’s last move then he or she controls your game. You need to have long term vision how to win a game.

Software development complexity board

In software development complexity might not be so easy to see, but it’s there. I’ll try to explain complexity with software development board.

Let’s start from the chess:

  1. Your opponent has his or her pieces which have different properties. Your opponent has own mind which you can’t read. So he or she moves pieces more or less unpredictably. This causes most of the complexity.

  2. You have your own pieces which have different properties. You can control your own pieces.

Transforming it to the software development:

  1. LIke in chess I added items which cause complexity to the top of the table. Those are again more or less unpredictable and not fully controlled by you and your team. There is two kind of things. There is items which are related to customer and there is items which are related to environment where you are working.

  2. To the bottom I added items which are solution. These items you can control. There is features delivered and then solutions how features were done.

You win if you can handle complexity and unpredictability and build the solution which satisfies stakeholders.

From theory to the game

As I told in chess it’s impossible to count all moves and win the game. Same applies to software development. It’s not possible to create detailed functional and technical documentation upfront.

Why? Because there is too many factors and you learn those when development goes on. That’s why, as in chess as well, you create first a vision and only then plan next and only next moves.

Now let’s take an example about playing with the vision.

Let’s assume that playing couple moves in the chess game. You find out (or learned) that you opponent is attacking from the left side with his bishop. You need to stop that and you have two options. Which one to choose? The one which aligns with your strategy. This way you improve your whole game and you are just controlled by your opponent.

Same in software development. Let’s assume you created a proto and showed it for the users. You learned that the way they do their things are different that you expected. You need to do something. Way to do things was unknown for you and now it’s attacking you.

With this case you have now possibility add more details to feature which will be implemented in near feature. Like in chess game  you had two options to react to opponents move now in software solution you have several ways to fill the need which you learned. You choose one which is aligned with your vision. You are optimizing the whole solution, not just single need. You are going toward your goal, your vision. And the vision declares your strategy. Brilliant.

Vision or strategy is there to help you when you learn more from the vision. Vision is like a compass that guides you to the north pole.

So what I learned?

In chess it is easy to understand game complexity. It’s there front of your eyes. In software development it might not be so obvious. Complexity makes it almost impossible to count all moves upfront. Same applies to software development planning.

When you learn more from the game or from the system then it’s the vision that guides which helps you to do new decisions. With the vision you optimize the whole system, go to the correct direction and not just react to single needs which will pop up.

It’s interesting to think that long term product road maps are strategical documents as well. What could be in the top row when thinking about product road mapping complexity board?


Storytellers in software development

Storytelling is the conveying of events in words, images, and sounds, often by improvisation or embellishment. Stories or narratives have been shared in every culture as a means of entertainment, education, cultural preservation, and to instill moral values. Crucial elements of stories and storytelling include plot, characters, and narrative point of view. (http://en.wikipedia.org/wiki/Storytelling)

To reach valuable solutions in software development you shouldn’t be the best requirement writer. Instead you should be a good storyteller. Why? Follow me…


One of the good point in storytelling is that it puts everything in context. I was listening Coplien in Tampere Talo during 2012 spring. His point was that user stories are not good enough as stand alone “requirements”. User stories are missing context.

Storytelling goes from beginning to end. From describing the initial “system” through changes to the happy end (or sometimes not happy end). All of this will set context for user stories. It will tell how small requirements will change the whole system.

Context sets the final value which system will got from the change. Beginning end in mind makes sure that every steps takes the team toward the right goal.

Decision makers

So we understand that context is important. But for who it’s important?

Poppendieck wrote about decision making. I specially remember a Marine team. In the team decision making is given to the front people. Why? Because complex problems can be dealt only on the front line. Poppendieck wrote about a study which result was that when front people are solving complex problems they will do less mistakes than  distant officers.

Poppendieck continued that in the Marines planning process focuses on understanding. This way the team can understand boundaries, simplifying assumptions, alternate approaches and strengths and weaknesses. They can do fast decisions when a mission is going on and act based on that.

Same way as you dig in to the source code and find out what really is going on in the function level. You find out what are real reasonable ways to solve customer problems. You can do best decisions if you have understood the problem and the context.

If you don’t understand the problem and find that some of the manager assumptions were wrong then you have two options: Call in manager for new decision making or do some guessing. Call in will take time and stops whatever you are doing and puts the task on hold. You need to get back to it later instead solving it right away. About guessing… well it’s guessing.


But how to emphasize understanding? As when setting context for requirements you can continue storytelling to help people to understand.

Tell about the users and the customer. Tell what kind of problem customer has and why it happens. Tell about the environment. Tell also about how customer now survives and which kind of consequences she is having. Tell about boundaries. Then move to the time after problem is solved.

Again highlight the value which customer or user gets after problems is solved. Also go through possible solutions which are discussed with the customer. List down pros and cons from different alternatives. That’s way to emphasize understanding.

Isn’t that just creating a good vision for a project?

Storytelling pokes imaginationNot exactly. The storytelling is something more. It pokes the imagination. And the imagination is the key for our emotions and learning.

With good storytelling you can visualize the context, the problem and the solution to other people’s minds. You can make them feel sad and happy.

The storytelling is what you need to do if you want people to stand in customer shoes. To feel the problems. Somebody once said that if you can’t visualize it, you can’t understand it.

So if you already write the vision for your project or product development, check that it’s not boring. Make it interesting.


The storytelling has many advantages. With the storytelling you can

  • Add context to the requirements
  • Create a clear vision about what happens when the problem is solved
  • Help front people to make better decisions
  • Have possibility to feel and stand in the customer shoes

How to find time for the storytelling? In previous post we had unhappy developer Cole. His project started with punch of the detailed requirements. At the beginning of the project Consultant should have been considered to replace most of the requirement details with storytelling. That would have helped Cole to do better decision.

My conclusion is that the requirement writers needs to learn to be good storytellers. The storytellers will put some drama, make people sad and happy. More better story you tell more better it’s remembered.

Working software over comprehensive documentation

Cole is a software engineer who is frustrated to software functional specifications. Sometimes there is details which are changing and sometimes needed details are missing. This happens project after project. With heroic last days work Cole can fix the last things and deploy to customers. But soon Cole has had enough.

In this post I’ll take a closer look to a Cole’s problem and why it happens. I’ll explain it based on principles related to software development and get back to the Agile Manifesto.

Principle based problems

I like three golden rules which have been introduced in the book called Agile Samurai.

  1. It’s impossible to gather all the requirements at the beginning of a project
  2. Whatever requirements you do gather are guaranteed to change
  3. There is allways be more to do than time and money will allow

Why I like those rules? Because those are concrete results from the fact that software project is about solving complex or mediocre problems. Think about present days ERP systems. Those are not simple, are those?  (You can find more about this from Management 3.0)

About principles, it’s again like a nature. If you eat too much fat, you will get fat. Damn fat.

If environment and processes are not set based on the principles then there is too often needed hero’s and flexibility. And only after heroes and flexibility there is change that project is success.

Cole’s challenging project

Cole started with the new project. The project had requirements specification done which were gathered by consultant with customer. All the requirements nicely ordered and all the details were considered and written down. “Very nice. Finally something which I can code from start to end without need to interrupt others.”, thought Cole.

Problem 1 – Missing details and missing feedback. After two weeks Cole faced the first problem. Even though document had a lot details, some details were missing. Cole asked about the missing details and it turned out that the answers were not simple to give. Consult were already busy with the new requirements doc (tying to put down every single detail to not fail again) and Cole were able to feel frustration every time they had a conversation.

Cole got the answers but feelings were not high. Cole decided to start to do his own assumptions instead of asking. Cole was engineer and his decisions were more from the technical point of view.

Finally coding was done and system testing started. Consult participated to testing to check that everything was ok. Testing phase showed that some Cole’s assumptions were not correct.

Biggest surprise was that when consult asked to run old interface for data which new functionality produced Cole answered that it wasn’t possible. Cole explained that he used new database architecture for data sets and old interface just didn’t worked on top of that.

Because there was things to be changed Cole and consult decided to move deadline 2 weeks to make things right.

Cole started to be in trouble as the needed changes were not in align with his architectural solution. To make the changes in 2 weeks Cole needed to do shortcuts in the code and in usability. Shortcuts were not enough and he needed to do long days to make it in 2 weeks. Time started to run out and not all testing were able to do all over again.

“Oh why he hadn’t tested my software earlier. She could have seen how I understood what he wrote in specs and I could have adjusted my work and architectural decisions based on early feedback. Now I have a lot of things build on top of things which I need to change” Thought Cole at one long evening at the office.

Problem 2 – Understanding based on concrete results. It was time to show 2 month (and 2 weeks) results to customer. Customer noticed that for getting the value out from the solution they needed to have almost perfect product name parameters in the system. Customer were very sceptic that they could have such complete data in the system in real life.

But they got an idea when they were using the software. If they could just have one new user selection state for their controller for the data which was produced, they could forget the whole product name parameter problem and go on with just 2 extra week coding with Cole. Together with Cole they found out that this last change to the requirements made unnecessary ¼ of code which Cole already produced in project.

“Why we didn’t thought this earlier?” Said customer. “Yes, why not. I could have been home with my wife and kids if you would have saved some of my time and some of your money.” Cole thought.

Cole was angry. Why everybody checked his work results when it was too late for it!

Understand the principles

Cole’s problems in the project are caused by process which is not the for complex problems. Roughly Cole’s project was done like this:


If you really believe that you can find the best solution before a single line is coded you are wrong. A problem solution process in complex or mediocre environment isn’t straightforward. Even though final solution might be simple and easy, path to find solution isn’t.

This means that work with requirements will not stop when development starts. Consults, customers, coders and testers needs to work together. They need to create a teams where customer and development point of views works together for the best implementation.

In practise there needs to be first created guidelines and only then nearest details are thought. Details which are not needed next are waste. When you build small part of the solution for a review, then team understands problem better and might end up with the better final solution. It means that rest of the requirements might and should change based on the new understanding.

Below you can see picture of a process where team works together with observation from the built solution. “What needs to be done” steers “solution building” and “build solution” steers “the need to be done next”.


Working software over comprehensive documentation

So iterative software development with observation makes sense. But it might be difficult to understand before you are able to admit that the software development is about solving complex or mediocre problems. When you understand it, then you are ready to use tools which are developed to handle such problems.

Use working software over comprehensive documentation. If you will not do it, somebody else will. If it’s your competitor, you might lose your Coles and customers.

Checklist to keep myself agile product owner

This post is related to earlier post: Reminder: Why I choose agile.

I experienced that even I found out reasons why to choose agile I don’t follow those in my daily work as much as I should. Because of that problem I decided to create check list for myself. I usually plan my upcoming work week at the last week Friday or at the beginning of the week. Following list will help me to plan my week.

  • Product
    • Will you get  feedback for the product?
    • Will you work with vision and backlog based on feedback?
    • Will you arrange possibility for development team to work with end users?
  • People
    • Will you discuss with team if they are having needed competences?
    • Will you let team to self-organize to make  best process for themselves to build the product?
    • Will you let team to find out best implementation for product?
    • Will you let team know to which direction it needs to grow to build the best product?

Additional note: Most likely you need to work with constraints like budget, time, quality, shared vision etc. If needed then communicate with all stakeholders. Don’t let constraints to be obstacle. Let it be possibility for new discussions.

Reminder: Why I choose agile

I’ll keep myself in most important things.

Most of the software projects are complex. This is stated in Appelo’s book and is based on research of many people. My experience is that one major reasons for complexity is need to do something which is difficult to explain for the users. And for users and customers it’s difficult to explain to you what they really need. Nothing can be sure  before you can see it and try it.

Other major thing is organization layers. Even if it is difficult to know what to build it is even harder when you have multiple people in communication chain. How to know that we are building right thing?

Also complexity exists in the product itself. There needs to be taken care of maintainability, security, scaling and so on. Also there might be 15 year old legacy code behind product core architecture. How to make sure that product is build right?

Agile methods for my product

So I can’t know 100% what user want’s. I need to get feedback for product and therefore I prefer to have check points where I can check if we are building correct things for the users. And if there is something going to wrong direction I need to be able to change my plans. As we know iterations works here nicely. Like I read from Toyota way book about continuous improvement with PDCA:

  • Plan
  • Do
  • Check
  • Act

Also it is important that there is reduced organization layers between development and customer. That is the way how people who actually are building the product can understand problem to be solved. Developers needs to be able to stand in customer shoes. Side-effect is that when people are able to empathize problem they are able for trying to seek the best way to solve it. Not just add feature after feature. That is the way to build best product.

Agile methods for my people

I don’t want to work with organization where can be stated that:  management want’s more out from the development and development thinks that not full of their capabilities are used. It’s one of the biggest waste. It makes me angry (this energy can be used to positive way like changing organization to be more effective). As we are working with complex environment, where I assume that nobody alone can’t understand all things, then we need to have teams. Teams which contains people with different competences. For teams we need to make environment where teams can use their full potential. For me it means things like:

  • Team can decide what is best way to work together
  • Listening team about solutions what could be used
  • Let the team build the software

Management needs to give direction where to go. For example: they need guide what problems team needs to solve and which quality level to achieve. It can be either customer problem or process problem.