Better Criticism

Criticism is an attempt to influence

• Do not afraid to give feedback.
• Choose the appropriate time for feedback.
• Do not blame. Instead tell what  could be done better and suggestions of how to achieve it.
• Give criticism about work. Do not critique the worker.
• Present the benefits of improvement, rather than scare about risks and disadvantages of mistakes. List of failures does not motivate people.

Feedback is the breakfast of champions. -Ken Blanchard

kanban - how we implemented it

Kanban (看板) for Software Development

The word "Kan" means "visual" in Japanese and the word "ban" means "card". So Kanban refers to "visual card", "signboard" or "billboard".

There's excellent articles describing kanban boards and methods for software development . For example InfoQ has two free e-books that are quite useful for bootstrapping kanban board.

• "Kanban and Scrum - making the most of both" by Henrik Kniberg and Mattias Skarin
• "Priming Kanban" by Jespre Boeg

But if you want go beyond and learn more than just sticky notes on board, you definitely need to study The Kanban Method as formulated by David J. Anderson in his book "Kanban: Successful Evolutionary Change for Your Technology Business". The Kanban Method is "an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improving the system." Definitely more than just the kanban board (which you should always start with lower-case to distinct it to upper case the Kanban method btw).

But how we implemented kanban board?

I am not going to go general details covered by mentioned source. I just present some of our policies.

The Board

The Board

This board was actually used by one of our teams... Today it looks quite different but basic elements are there. Basic set of columns; Baclog; Selected; Develop; Testing; Done. And some WIP limits and avatars.

We are just installing automatic testing and staging environments and creating the separate end-user testing team. While doing, we separate developer testing and user testing to their own columns. Going away from multi-functional team, but the testing team also writes and updates the end user help documents and manuals on multiple languages while testing. And testing team will also do semi-automatic (at least minor) updates to selected production environments and pulling the tasks to final done column.

Visual Card template

Nothing very unusual here I think. Bug id is written if it exists on bug database. Harsh classification to Bug/Feature/Maintenance items. For Fixed Delivery Date (see below) items the obligatory delivery date and estimates are written to top-right corner.

Started On and Dev Done dates on bottom are for statistics and they are written on normal ballpoint pen instead of ink pen which is used for other items.

But one note; use the best sticky notes you can get. Otherwise you might end up having automatic expiration of items not handled in certain time when glue just expires. We have found that nothing compares to Super-Sticky notes from Post-It.

Class Of Service

We use quite directly the Class of Service concept from Anderson's book. Class of Service defines how items are pulled through the system. It determines priorities within the system. Currently we use 4 different levels which are visualized by color of the note. Later we are going to allocate capacity separately for different classes, but before that we can collect some statistics with just implementing the classes. 

Expedite

• Red cards
• Can break WIP limits
• Only one allowed at any given time per board or swim lane
• Anyone qualified have to pull the task immediately
• No estimation unless someone specifically request it

Fixed Delivery Date

• Purple Cards
• Obligatory delivery date is displayed on top-right corner of the card
• Estimated by T-Shirt sizes
• Started in "Good Time" so that delivery time can be respected 

Standard Class

• Yellow cards
• FIFO handling
• Usually no estimation unless "seems to be bigger than usual" 

Intangible Class

• Green cards
• common-sense / ad hoc handling

Swim lanes

We are working on multiple products of our own with multiple projects on each product. Problem domain for products are quite different. Even that basic code base for server development is same, the context where it is used needs special knowledge for development. So we have 2-3 more or less overlapping teams. And one separate mobile development team doing parts for all products since the actual coding is completely different than server based development. So currently we have 3 different server development boards and one mobile development board. No swim lanes. And it feels quite complicated.

But at the end of the year we are moving to new office and we are already thinking whether we move to one or two boards. And maybe swim lanes to different products. Suggestions are welcomed :)

Done Policies

Current Done-policies for columns are presented in quite general terms. No point to repeat them here since there is lots of room for improvements. But we have procrastinated fine-tuning them until the next set of column changes are done. But we have noticed these policies should be visible even if all think they are well-known. It's much easier to explain the board for stakeholders and newcomers.

Things that matter most must never be at the mercy of things which matter least. -Goethe

XY Problem

XY problem seemed to be theme for many conversations I participated this week.

Someone asks how to do X when they really want to do Y. They ask how to do X because they believe it is the best way to accomplish Y. 

It's a pattern of miscommunication where questioner seeks premature closure with wrong assumptions. It's quite hard to convince questioner to accept any other solution than he originally considered the best. Usually the questioner have I-Know-It-All attitude, they just need help for doing their X.


XY problem can even be extended to XYZ problem

There may be a solution Z that is even better than Y, but nobody can suggest it if Y is never mentioned.

This is quite common time-wasting problem especially on customer support and help-desk work, but there have been documented cases even on project work.
It would be great that everybody would take time to learn  How To Ask Questions The Smart Way by Eric Steven Raymond :
"

Describe the goal, not the step
If you are trying to find out how to do something (as opposed to reporting a bug), begin by describing the goal. Only then describe the particular step towards it that you are blocked on.
Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realize that the path is wrong. It can take substantial effort to get past this.
Stupid:     How do I get the color-picker on the FooDraw program to take a hexadecimal RGB value?
Smart:     I'm trying to replace the color table on an image with values of my choosing. Right now the only way I can see to do this is by editing each table slot, but I can't get FooDraw's color picker to take a hexadecimal RGB value.
The second version of the question is smart. It allows an answer that suggests a tool better suited to the task.

"
But it could be inconvenient to RTFM the customers. If the question sounds strange one can apply simplified root cause analysis methods. Specially 5 Whys works quite well. You just keep asking "Why?" until the questioner actual tells the Y he wants to accomplish. It may sound childish and silly, but in the end save you both time.

Asking the right questions is much harder than giving correct answers

Silent Hour - Experiences

Week ago I blogged about our new experiment - Silent Hour.

Our team has just one room, people sitting next to each other and even if you are discussing with only one team member, others are also easily distracted. Headphones do help a little, but we decided to try something different. Between 12:00 to 13:00 we close doors of our team rooms to avoid all unnecessary disturbances both from internal and external origins.

For customer contacts we fortunately have first tier customer support which can handle easy tasks independently. Complicated tasks and problems are forwarded to developers, but during Silent Hour we encourage them to try little bit harder before doing that. Or they can take request for callback if the issue is not too urgent. But rules are not absolute; if they really needed help they can ask advice from developers anytime. Common sense rules.

On the other hand managers and salespeople tend to rush to ask questions from developers at any time. And just fiver minutes later they come back to ask follow-up question. Face to face communication is good thing -no doubt about that- but just when you are getting back to flow for programming, there is already new distraction waiting... With Silent Hour closed-door-policy should encourage people to at least think do they need the answer right away or could they wait 30 minutes.

This have been working quite well. After little over week of experiment I did questionnaire to all stakeholders including developers, customer support, managers and salespeople. Almost all answered. Results were quite encouraging. Nobody thought that Silent Hour-policy had made his own work more difficult. Even that sometimes people did not remember the policy and have to turn away when they noticed closed door, they did not feel that additional waiting time for their communication needs did do any harm.  Everybody understood the need for developers to have some time when they can just concentrate task at the hand. And naturally developers were quite thrilled for the uninterrupted time. Sometimes we got visitors even during silent period, but always with good reason. 

Conclusion was that we end this as experiment and make it as permanent policy.

Silent Hour

Agile puts great value for interactions and communications but sometimes too much communication can turn to waste. Interactions should not be part of WIP and should not have their own sticky notes on board.

The Agile principles embrace

Co-Operation

Business people and developers must work together daily throughout the project.

Communication

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 

But also

Sustainable Development

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Simplicity

Simplicity--the art of maximizing the amount of work not done--is essential.

In order to put more emphasis and improve the latter two we now are in progress of testing the new practice we call Silent Hour. Between 12:00 to 13:00 we close doors of our team rooms to avoid all unnecessary disturbances. We urge everybody to think at least twice before distracting developers during Silent Hour. Average waiting time is 30 minutes anyway, so it should not be any problem. Also developers avoid any unnecessary chatter. Some developers are also going to test the Pomodoro Technique® since there is just enough time for two pomodoros.


This is just ongoing testing and rules will surely evolve, but it has received quite good acceptance with developers and also with other stakeholders.

Edit: There is also followup post with more information and experiences: http://ikettu.blogspot.com/2011/11/silent-hour-experiences.html

Performance = potential - interference (P=p-i). Tim Gallwey 

Back in Business

I managed to recover my lost blogger password finally. 

So I'm back in business. 

Actually I'v been quite busy on "real work" :) 

But since autumn conference season is opening, it might be good time to restart the work.

Friday Special, Beauty of Waterfall

Visual Waterfall

Everybody keeps telling me that agile is better than waterfall. And then they are telling me that lean is better than agile. And kanban is better than anything.

Quinault Waterfall by Robert Kraft

But their visualization
is so beautiful.

U.S. Department of the Interior

They power your team.

They have endless flow.

It is part of complex system
which is rather easy
to understand
but hard to predict.

Lean principles - Deliver Fast

Deliver as fast as possible -- Customers like rapid delivery.

After deferring the commitment it is finally time to do the real work; Programming, integrating, testing, deploying and finally delivering. And this stream should be as fast as possible. When it is decided that something have to be done, it should be done quickly so that customer can provide feedback. And if you like procrastination; the faster you can deliver, the longer you can delay decisions.

Use short iterations where new, functional software is delivered to the customer in closely-spaced intervals to have limited number of requirements waiting for feedback.

Empower your team and use pull model where team and individuals pulls the tasks for themselves. Utilization keeps high as tasks are pulled as soon as there is capacity to do the task. On the other hand, team does not saturate under overwhelming workload. Saturation just leads waste in form of unnecessary task switching and partially done work. To prevent team saturation to be bottleneck, limit concurrent Works In Process (WIP). Make rule that there can only be X amount of features in development, testing etc. Kanban provides means for both pull system and WIP-limits.

Finally some practical points.

Automate anything you can.

Automate your delivery/deploy pipeline. It is more productive to use your time for programming and testing than going trough delivery checklists and manually copying files from servers. You also gain repeatability of process, delivery errors are reduced etc.

Use proper tools.

It is well worth of paying extra money for productivity tools and proper hardware. On software business we do not have to invest ocean-going cargo ships, but we have to invest on people and their creativity. On could do the mathematics and calculate:

10 builds/day * 30 seconds faster / build with new hardware
 = 300 seconds / day => 1,5hours / month

But those 30 seconds can be essential to keep coder on the flow.

   Ilpo Kettunen

See also

• 7 Lean principles

“busyness is not good business” -- Alan Shalloway

Friday Special, Yet Another Kanban example

Photo and arts Jari Jokivuori

Does kanban boards have to look so boring?

Two weeks ago I blogged about one team having their small board upgraded to bigger one. The old board rebirth as 2.5D Backlog.

And here is what the team did for extra space they have on new bigger board...

I think Beagle Boys stole our WIP limits, but fortunately Phantom is on rescue. Darwinism got hold on your develop column and natural selection cleared the select column. And still there is on log on the back...

Since it's almost May-Day I tried to find some balloons to picture, but could not find any...

Yet Another Kanban

Lean principles - Defer Commitment

Decide as late as possible.

Defer commitment to have as much as possible information to back your decisions. Delaying irreversible decisions at the last reasonable moment allows time to learn more about problem in hand, which results in better decisions. Deferring commitment is positive procrastination.

But do not close your options too early. Sometimes it is worth to pay added cost that options can be held open, allowing decisions to be delayed until more information is available. Decision should be made at the moment at which failing to make a decision eliminates an important alternative.

Active customer participation helps to defer Commitment: Involving customers throughout the process eliminates the need to make decisions up front. Keeping decisions about features and the development of those features close together leaves less room for change.

Break dependencies so your decisions are separated to each other for easier procrastination.

On the other hand, committing early can be motivating. It also changes risks and opportunities. So there could be some value making early choices.

Keep your options open. Do not block your options by delaying too long.

If you wait too long, you could end up dancing with your sister instead of second best cheerleader.

See also

• 7 Lean principles

“Making software is really hard: it is non-sequential, non-linear, unpredictable work”-- Jan Machacek

Friday Special, Automatic backlog expiration.

In addition of 2.5D Backlog, we also kind of implemented Kanban backlog where tasks will automatically expire when they have been on board too long without anybody touching them. You only need no-name sticky notes with bad glue… And large garboard box under board to collect dropped task notes for second review before housekeeping get to handle them. This actually works since we are using magnetic avatars over task notes when work is on progress… Anderson suggest using models for improvement opportunities and making small continuous, incremental and evolutionary changes that stick. This is kind-of anti-stick non-model, so I cannot suggest it? 

But seriously; we are in process to create simple tools to improve our measurement part of Kanban. “Stay tuned”… 

“Kanban is so simple! No plans, no estimations, no iterations, no overhead” - Unknown Besserwisser

2.5D Backlog

Since we already are visualizing the flow, defined WIP’s, established some measurements and agreed what “done” means, it’s time to use models to suggest improvement opportunities.

So my first suggestion is to use Cost-Benefit / Effort-Value models as improvement opportunity to visualize backlog. First little background; we changed one A3 sized whiteboard to larger model in one room. I started to think what to do it or should I consider it as waste. After hard thinking and 2 cups of coffee I had the Illumination. Let’s put there some axis and have at least 2D visualization of something. After yet another thinking session it finally came to me; The Backlog. So we got this.

2.5D Backlog

X-axis shows business value of the task. Y-axis is combination of known effort/cost and technical risks involved to task. There is no defined scale or values to axis. Task notes are just put to board relatively to each other. Now we can see Easy-Wins from lower right portion of backlog to be priority candidates for selection. Not forgetting that Technical-Risks with great business value on top-right of chart should start as early as possible. But actual selection criteria can vary from project to project or even during the project.

Everybody is allowed to change position of notes. Fortunately our customer proxies do not touch on cost dimension. Currently project manager does check and pull the tasks he wants to the “selected”-column on Kanban board, but on long run I think we can get a rid of the “selected”-column all together and let the team to do decisions themselves. Project Manager just checks and realigns notes taking special care of tasks with hard deadline or where value has dependency to time.

The colors represent different types of tasks. That's the "point five" dimension. We use red-defect, yellow-improvement of current feature, blue-complete new feature.

There have been some discussions lately if estimation is even needed in Agile/Lean development? (we do estimations - at least for some tasks…) Our 2.5D backlog is more team visualization tool rather than formal estimation, but I think it can replace formal estimation at least for some domains.

We are also in process to create simple tools to improve our measurement part of Kanban. “Stay tuned”…

Lean principles - Amplify learning

Most things I have ever learned, I learned from failures. Not necessarily my own failures but something somebody has tried and failed so that I have not need to try it myself. Fortunately sometimes I have also learned from other people's success too. And I have to say; sometimes I have success before failing and learnt. And after all, I have gained experience while trying or following others.

( success | failure ) of (your | other people's)
-> experience
-> skills and knowledge

Sharing information regularly creates group knowledge from individual knowledge. Daily Standups are your local best friend.

Competence = skill * discipline * knowledge * social connectivity
And connectivity has more effect than knowledge
@jurgenappelo: from "The Hidden Power of Social Networks", Cross, Bob et.al

But usually I tend to give away little bit discipline by varying my methods. Doing little changes to project plan on every project. Using different test libraries on different projects etc. Some changes are rejected, but best changes remain in effect. It's kind of genetic algorithm for developement process.

Although you can learn some ungooglable little things with other ways too.


Get feedback.

Getting constant feedback from customer, and more importantly from the actual end-user, is essential way to learn about the problem we are trying to solve with the end product. By (my) definition Agile requirements management is a learning process where both the customer and the developer are working together to learn more about the problem. But even then requirements are constantly evolving and only way to make things work is have continuous feedback from actual users of the end product. So you have to commit to continuous integration, deployment and delivery so that the customer has something she can use to give the valuable feedback we need.

Use pretotyping to get feedback (actually you are trying to get prefeed...) on early stages. The main objective of pretotyping is to answer questions about the product's appeal and usage: Would people be interested in it? Will they use it as expected? Will they continue to use it? ... Failing ideas even before prototype stage is much cheaper and you have more time for new ideas to prototype.

Use prototypes to learn about technical challenges you are facing before starting large scale production. The main objective of prototyping is to answer questions related to building the product: Can we build it? Will it work as expected? How cheaply can we build it? How fast can we make it?

But sometimes you can introduce deliberately failures to learn. For example Netflix uses system they call Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within their architecture to learn what happens during outages.

See also

• 7 Lean principles

"I have not failed. I've just found 10,000 ways that won't work." -- Thomas Edison

Lean principles - Eliminate waste

Provide market and technical leadership by creating nothing but value. By definition waste is anything that does not contribute value to the final product or customer. Also first principle of Agile Manifesto says: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Everything else is considered to be waste.

Mary and Tom Poppendieck later mapped original seven wastes from Toyota Production System to wastes we found on software development. (Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.)

1. Partially Done Work
2. Extra Features
3. Relearning; Extra processes
4. Handoffs, Motion
5. Delays; Waiting
6. Task Switching
7. Defects

With value stream mapping we can try to identify steps on processes that add value to customer. But how we can measure direct value for example Configuration Management or Risk Management?

Root cause analysis can be used to try to find what was the original problem. There exists many methods, but I have find most effective to just ask enough why's to get the answer. Official name for this is 5 Whys. IMHO Most of time (1-5) whys should be enough.

But even then seeing the waste is hard. And is it actually always necessary?
If carrying along few extra unnecessary lines of code does not cost you anything, is it just waste of time to remove them? Is refactoring always necessary?

Manual work is eliminated by automation. But which one is waste; spending 4 hours to create one time script or doing 2 hours of manual work that accomplishes same thing?

We all are happily carrying 90% unnecessary DNA with us. I don’t want to eliminate it even that I do not know what to do with it. So my best practice for eliminating waste is; use your brain - or 10% of your brain, since nobody knows how to use the rest of it.

See also

• 7 Lean principles

"Just because something doesn't do what you planned it to do doesn't mean it's useless." -- Thomas Edison

Pro waterfall?

<humor>

The customer knows what he wants; developers know how to build it and nothing will change along the way? If that’s your context you should take look on waterfall manifesto or attend some conferences.
</humor>

Otherwise agile manifesto is way to go.

But is there actually anything good on waterfall or v-model?

It seems that it easier to sell and buy projects with predefined focus and clear ending than “we just do what you want”-kind of deal. Are we bold enough to share the risk with customer and can customer participate enough for "Money for Nothing, Change For Free".

Or do auditors like so much the verification and validation that there's no way to use agile methods on certified quality management system?

Most of time we have to do some compromise between traditional and agile methods, but I think that's actually good thing. Isn't it actually more agile to use even waterfall if customer really wants that than selfishly trying to push scrum? 

Introduction

Several years I have been consuming open source projects and reading published text from other people. For some time I have been thinking how to do my own contribution. So I finally decided to start my own blog and try to give something back to community.

I am CTO at FastROI which is small software company based on Joensuu, Finland. We are making our own products which we are mostly selling by SaaS model. We are learning and implementing Lean and Kanban practices. Same time our quality management system is being prepared for ISO 9001:2008 compatibility. We are trying to sell customizations as agile contracts to quite “old-school” customers.

Definitely there is a lot learn on these areas and I hope I can share as much I can during the process.