Uncovering the best local knowledge

When you have questions about a certain city, place or region it is often still difficult to find answers quickly in the big , not always well organized, stack of information you will find on the web.

It would be nice if for every place, city, town or neighborhood a local collection of questions and answers exists which can be updated and improved by everybody.

That also crossed our minds which resulted in the idea for RegionQuest.

All the answers for every local question

Sprint outcome

The sprint outcome must be a potential shippable product, it doesn’t have to add business value !
It should be an input for the next sprint.
Focus on feedback given by all elements in the development process; team members, customer, tests, systems.

Making the retrospective more fun !

In many teams I have experienced that the retrospective is a meeting people are not always excited about. Why is that and how can we make the retrospective meeting more fun ?

A typical retrospective is having team members sitting around a table and the question is asked, what went well and what to improve ?
People start scratching their head and neck and after some time the first remarks are made or red notes are put on the whiteboard.
Then long discussions are held how to solve or improve the “to improve” items.
After some time, one hour or even more, the discussions are dried out and the team has to leave the room because the next meeting room reservation is already waiting outside the door.
The thing is that nothing really happens with the “to improve” items.

What is wrong with this approach ?
– Meetings are lengthy.
– Meeting can be dreadful.
– It’s difficult to find solutions in just a single meeting.
– Not everybody participates with the same enthusiasms.
– Many times the meeting produces no outcome or result.

How to avoid this ?
Approach the retrospective meeting as a short game with a playground, actions, artifacts and goals.
Make the retrospective short and dynamic, without lengthy discussions.
The amount of time people can give their maximum attention is about 20 to 30 minutes, so this should be the length of the retrospective.
The possible improvements that people come up with can be wishes or so called fuzzy goals, it doesn’t matter, anything is possible.
Try to find actions that can lead to (small) improvements instead of finding complete solutions.
Important is to realize that many “to improve” issues are wishes, and wishes can’t be tracked or measured on success. Always translate wishes to goals and actions.
For example a to improve item can be : “communication with customer”. Try to define actions that will lead to small steps of improvement for example : setup a meeting with the customer to brainstorm about this or ask the customer’s opinion about spending one or more days per iteration with the development team.
So, how does this retrospective game look like ?

A whiteboard is the playground (dedicated white board !)
Artifact, Actions
An important artifact is a so called Who/What/When matrix, this can be a sheet with three possible improvements and their supporting actions to get closer to these improvements and the names of the persons who will do the actions and when these actions will happen or are due.
The goal of the retrospective is to find the three winning possible improvements :
“To improve items” and “Went well items”.
The three possible improvements are a result of a voting game where people can give 5 points in total to possible improvements.
The ultimate goal is to successfully close all actions on a Who/What/When matrix at the end of the iteration.


A volunteer can lead the retrospective preferable like a stand-up

In practice
The team gathers around the whiteboard and writes on post-it’s what they think that did not go well during the iteration, the “to improve items” and the things that “went well”
Better is when the notes are already put on the whiteboard during the iteration so time is not wasted thinking of subjects during the retrospective.
Different notes sharing a common subject are gathered to make issues more visible.
Every note/common subject is introduced by a volunteer and a small discussion is held for a maximum of 3-5 minutes
5 points can given by each team member. A maximum of two per note can be used to avoid veto votes.
The 3 winning “to improve” items with the most points are written down on the Who/What/When matrix.
Just a small discussion is held about the three winning “to improve” items what actions can be taken to make a (small) step to reach the goal.
One of more volunteers can attach their name to one of the three subjects to define actions during the next iteration that can be taken to improve the winning “to improve” items.
These actions must be done in the next iteration. Important is that they don’t have to be solutions, just a small step towards the solution is enough.
Actions can be :
Organize a meeting to discuss ….
Write an email to ask …..
Look for a tool that can help with ……

The “went well” items are also important in such a way that they can be used as :
How can we make sure that in the next iterations these items continue to go well or how can we let other teams also benefit from our knowledge to make these items go well.
An idea is to discuss two or more times in the next iteration the Who/What/When matrix and discuss the progress of the actions.
After the sprint review the subjects on the matrix can be closed, the ultimate goal of the game.
High score, game over !

Feature costs

Refinement of the product backlog will tell how many user stories a feature consists off.
Team guesstimates how many iterations it will take to deliver the user stories for this feature.
The “manager” (should) know the (average) cost of the team per iteration and therefore the total costs of the feature can be guesstimated.
Easy not ?
Or is it more complicated….. ?

Feature cost

Quality of software versus quality of software product

How is quality of software determined ?
We have to distinguish in quality of software and quality of the software application (product) that is developed. Let’s take two cars manufactured in different countries with different quality reputation. Car A and Car B. Both cars can have exactly the same specifications regarding top speed, number of doors that can open and close, windscreen wipers etc. But do the have the same quality ?
No, of course not would the average petrol head claim. Why is that ? Well Car A will start loosing horsepower after already 3 years and not reach it’s claimed top speed anymore, the doors won’t close anymore after 1000 times using them and the windscreen wipers will not remove rain and debris from the windscreen without squeaking and groaning. Car B is still doing all of that without any problems. So does this say that quality is not the same as specifications ? Well, it depends.
You could also specify the number of years the top speed is kept or how many times the doors can be opened and closed without falling off etc, but these specifications are not to be found at the car dealer’s showroom. Maybe they are specified in confident financial accountant files and material buyers documentation but they are not for public eyes. So how can we quantify quality then ? Well it has a relation with specifications and how long these will last so we could say that product quality is inversely proportional to the rate original specifications drop. The same with a software application, we want it to run with the same speed, responsiveness, behavior at the last iteration as it did with the first iteration. A definition of done can help to guarantee this; do everything in an iteration that will give you maximum feedback regarding code quality, tests, performance, load, integration, deployment, specifications, etc. With continuous inspecting, adapting and improving these items in every iteration quality and therefore the specifications of the product is maintained.
What about the quality of software ?  This is best defined with the code quality and this is determined by how fast and easy the software can be maintained, adapted, expanded, tested and deployed. SOLID Design principles  will help to achieve that. So software quality is guarded by SOLID principles, software product quality by using a well defined definition of done in an iterative development process.


Point is, what’s so wonderful is that every one of these flowers has a specific relationship with the insect that pollinates it. There’s a certain orchid that looks exactly like a certain insect so the insect is drawn to this flower, its double, its soul mate, and wants nothing more than to make love to it. And after the insect flies off, spots another soul-mate flower and makes love to it, thus pollinating it. And neither the flower nor the insect will ever understand the significance of their lovemaking. I mean, how could they know that because of their little dance the world lives? But it does. By simply doing what they’re designed to do, something large and magnificent happens. In this sense they show us how to live – how the only barometer you have is your heart.
How ?
When you spot your flower, you can’t let anything get in your way.