Open space meeting technique

Yesterday evening I visited a nice meeting of nl-scrum. I had no scrum experience, though I do have a long standing interest in "light weight methods". The topic was user involvement. User involvement in scrum is organized through the presence of a Product Owner, who withing scrum has his / her own set of challenges. It was nice to hear some Product Owners speak about their experiences.

Contrary to most meetings, presentations were just a minor part of the evening. The main part of the evening was devoted to "Open space". A nice concept, which I really like. Te concept has been used for meetings with 5-2100 people. It seems the history of Open Space Technology is detailed in the Introduction to "Open Space Technology: A User's Guide", by Harrison Owen.

There is a wall where anyone can post a topic. This is sometimes called the "bulletin board". The "open space" is sometimes called the "marketplace", and has several places (for example labeled A, B, C and D).

Topics can be noted on the bulletin board using whiteboard markers, post-its or any other convenient way. Example:

A	B	C	D
Product feature: colour	Sales channel fb	Patents: now or later?	Legal harassment risk: look alike
No menpower for design	product feature: keyboard	wow factor?	org barriers

The topic initiator, also called a facilitator, is supposed to move to his corner of the open space. Anyone else chooses the topic he is most interested in.

Rules are: The first rule, Whoever comes is the right people, simply makes sure that everybody is welcome in any discussion. Nobody should be locked out of a discussion.
The second rule, Whenever it starts is the right time, acknowledges that you can not force a discussion to start. Discussions start only when people care about something.
The third rule, Whatever happens is the only thing that could have happened, is meant to have people concentrate on the AREs, not on the SHOULDS, COULDS or whatever.
The fourth rule, Wherever it happens is the right place, reminds us that it is not important where a discussion takes place. If it happens to be at the coffeemachine, fine. This rule is not mentioned by everybody.
The fifth rule, When it's over, it's over acknowledges that discussions are over when a consensus has been reached. It has no use to draw out a lengthy discussion for the sake of discussion. Discussions can not be planned, some will take more than one round. They can be re-planned on the bulletin board again for a new round.

Law of two feet:
- if you neither learn nor contribute from a discussion, move on.
The law of two feet makes sure that people feel free to move around. Find another breakout session, another discussion, make sure you use your time useful.

The discussions/breakout sessions are alternated with round ups, where all participants are standing or sitting, preferably in a circle, and topic initiators present the result of a discussion.

The literature mention two types of people:
Bumblebees fly from conversation to conversation, picking up ideas from one and insert them in others. Butterflies fly from discussion to discussion and pick up ideas for later exchange.
Except these 2 roles there are those of facilitator and participant.

The Open Space Meeting technology has been used in open source, engineering, legal, and many other environments. They make sure there is cross pollination between different discussion groups.

In the links below there are people who say that you can use the technique only or best when:
- conflict is present,
- things are complex,
- there is huge diversity of players
- the answer was needed yesterday
I'm not sure all of these conditions are needed. Yesterday there were no pressing problems, just a bunch of 20-30 interested people. No conflicts, hour we were a very diversified group.

Quote:
"The 2 days of Open Space that followed were a success, a miracle in the words of the CEO and he added that 3 years ago they received a thick report from ___ (a famous international strategic company meeting in Israel) that cost $1.5 milion, and they could implement a little. Now we produced something much better in the cost of 1 page of their report, and it seems that we can implement it all." – Avner Haramati

Links:
wikipedia
out of the jungle blog
just another site

off the shelf software and FPA

The Dutch Nesma counting guidelines 2.2 have an interesting section on off-the-shelf applications.
They identify three areas of functionality:
A - functionality wished for by the customer, but not offered by the application
B - Functionality wished for by the customer, and offered by the application
C - Functionality not wished for by the customer, and offered by the application
Visually:

A is functionality that the customer wants, but does not get. This means additional costs. C represents functionality the customer pays for, but does not need. B is the area for which the customer can make a price comparison.

This model, like all models is i.m.h.o. a simplification. Using MoSCoW prioritization, one might group all "Must" and "Should" into the area "wished for", but one might also decide to add the "Could" or even "Would" groups to it. This might give considerable differences. For example, functionality not listed as required by the customer, might turn out to be a secondary wish not listed. Indeed, an inspection of the functionality of some off-the-shelf applications might yield considerable new insights. The nesma counting guidelines correctly mention the problem of counting the information model when counting off-the-shelf applications. One aspect they do not mention is the current trend of feature lists. Feature lists, for those not yet acquainted with them, are lists with short summaries of functionality. They may be formulated as the features found on the box of the product. For example, a word processor feature list might be: * the user can easily enter and correct text * the user can do elementary formatting such as bold, italics and underlined. * the user can use several fonts and character sizes * the user can print the text * the editing is wysiwyg * the user can create mailings by creating a document and connecting it to a variety of sources and so on. Feature descriptions sometimes are too short to make an FPA count. The person performing the FPA count will have to do some inquiries about the nature of the features.

Passwords - some practical remarks

There is a well known problem with passwords: they should be easy to remember, yet be long and complicated enough not to be detected by automatic password crackers.

The story is in the news today again for the umptieth time, with mashable reporting a list of the 25 most common passwords

Here are some of them:
password
123456
12345678
qwerty
abc123
monkey
1234567
trustno1
baseball
111111
iloveyou
Of course the guidelines for good passwords are well known:

1. Use a combination of upper and lowercase, digits and other signs such as "_", !, & and so on.
2. Don't use your name, names of relatives, or hobbies, birth date, and so on. Instead, do use combinations of words.
3. Let your password have a sufficient length. Experts differ in opinion, and applications differ in possibilities. For instance, on windows 7 administrators can set the minimum password length anywhere from 1 - 14. Google apps recently increased the minimum length from 6 to 8.
4. Use different passwords on different sites.
5. Change your passwords frequently.
6. Don't write your passwords down.

How, with these guidelines in mind, how can you choose passwords which on one side comply with these rules and on the other hand, are still useable in real life?

Here are some suggestions:

1. Use something from your most recent holiday: hotel, restaurant, camping, guide, recipe, and so on, and mix this with numbers and other characters. For example, if "haggish" was a recipe you liked when on holiday in Scotland, you might choose "Scotland-Hag*2011*gish" as a password. This will encourage you to change password your password again after a next holiday. Not frequent enough, but it is a step.
   A friend of mine went to Argentina, and used the names of all the small villages there as the base for his passwords.
2. Do you have a favorite song, poem or book? Use a combination of words, intermingled with numbers and other characters. For example, if you love the Rolling Stones, you might pick one of their songs: "You can't always get what you want", and choose a line, such as: I saw her today at a reception, and intermingle it with digits and other characters:
   "I08saw*her_today at a reception".
   If you change your password, don't just change the number, also periodically change to the next line of the song.
3. Including year and month in your password has advantages and disadvantages. One advantages is that it is easy to remember, and another that it reminds you to change your password again. An obvious disadvantage is that these parts are easy to guess, and certainly this should not be the only change in a password.

Now there is something to say about the rule: Don't write your passwords down.. First, to have a different password for every site, virtually forces one to write your password down, or frequently to ask the site to reset your password.
Personally, I don't think the rule can be taken as an absolute. Certainly it is not good if an office employee has a yellow note at the screen with his or her password. A better wording would imho be: write your password down at a secure spot.
If you are at home, store your passwords of internet sites on pencil and paper in a secure spot - where it can be found easily, but not at first sight.
As for the office, unfortunately there are still many employers who don't have single login enabled for there applications. Ask your employer for it - the problem belongs to your employer. Meanwhile, you probably have one main account. You will have to memorize the password for that account, and maybe you have a private area where you can write note your other passwords securely in that spot. Or maybe you can synchronize your passwords, changing them all at the same time?
One secure spot to write your passwords down is a password store. They allow you to write down your passwords for numerous internet sites and applications, together with the name of the site or the application. They need a password to open, so that is the only password you need to remember. And oh, you will want to backup this utility frequently. One which is free and open source is Keepass.

FPA - Some changes are no changes

Or in other words: Some changes are free

The definition of a maintenance project according to NESMA is: A project in which functional changes with regard to an existing information system are realized. In the information system functions can be added, changed or removed.
The first conclusion is that technical changes can not be counted with this guideline. Organizations which offer maintenance based on fixed price/function points may have a problem here, unless they make additional agreements with their customer, which is done often. A good question is if bugfixing counts as a change. My opinion tends to be: This depends. If the bug is of a technical nature, the functionality is not changed. An example might be a programming error where the system occasionally crashes. If however, the system requires that data element z should be equal to a + b, and the bug is that z = a + b + c + d, then the functionality changes, and this should be counted as a functional change.

It is important here to distinguish between the question: ‘Should we count this?’ and the question: ‘Should we charge this to the customer?’. The first question can be answered from the counting guidelines, the second by the contract. It may well be that the change may be counted, but not billed. The reverse situation, that the item may be billed but not counted, is something I see less often.

A second conclusion is that we must differentiate between the documentation of specification of the information system and the information system itself. The specifications and the information system will generally not correspond 100%. What concerns us here is that we count functional changes to the information system, regardless of the documentation. This is why some bugs, if they are functional in nature, may and should be counted even if the documentation does not change.

FPA had several formulas for maintenance projects, that is, for changes to existing systems. One formula is for the size of the system:

PROD_New= PROD_Old + FUN_Added – FUN_Removed + (CHANGED_New - CHANGED_Old)

This formula is given on page 15 of the NESMA counting guidelines reference manual.

The other formula, which is given on page 18 of the NESMA counting guidelines, is the size of the project.
This formula is:

PROJECT = FUN_Added + FUN_Removed + CHANGED_New

An example of both is given in between these two formulas, which is strange, as it introduces the project formula in an informal form before it is explicitly defined. Several conclusions can be drawn from this last formula. The first one is:

1. 1) Any functional change to a function should be counted as if the function has to be build anew.
This is of course not very accurate. There generally is not very much discussion about = FUN_added + FUN_removed. But CHANGED_New is another matter. Changes may be big or small, and I know of at least one softwarehouse that varies the number of function points depending on the number of data-elements involved in the change. This will generally please the customer: they will pay less than in the case of a full count as prescribed by the NESMA guidelines. There is a considerable drawback imho: Counting a reduced number of function points for some small changes makes it doubtful if they can still be considered function points.

It is understandable that some customers get upset if a customer has to pay for say a nearly identical extra data element to be added to 100 screens as if these screens should all be build from scratch.

A second conclusion is:

1. 2) Non functional changes should not be counted.
Cosmetic changes may be chosen as an example. A complete whole-over of the layout of a website might well result in 0 function points, while it requires a considerable effort to realize. Again: if these changes can be billed also depend on the contract. Contract definitions are very important in this respect. If the contract specifies that all functional change requests will be billed a E xx per function point, cosmetic changes might still be charged as they are not covered by the contract. If the contract stipulates that all changes will be charged at xx per function point, the supplier might have a problem.

In the long term, the effect of 1) and of 2) might cancel out each other, but short term fluctuations might be large. One way to solve this dilemma would be to agree that exceptional circumstances might be offered on a non FPA based estimate, but that is an option that would not please most FPA afficionados. Neither would it please the lawyers and management negatiotors, as it would be hard to define what is exceptional.

FPA updates

Some quick FPA Updates:

1. In the Netherlands, FPA certification has been transferred from Exin to Cito. A quick look showed that the sample examination is still the same, with just a name change.
2. There is an interesting discussion on linkedin about the pros and cons of Cosmic and FPA.
3. The Nesma newsletter of october 2011 mentions that the yearly fall conference will be on November 11 in Scherpenzeel.
4. At this conference Carolyn Mair, Senior Lecturer in Psychology at the Southampton Solent University (UK), will give a presentation on why experts estimates on the same subject might vary wildly.

Simplified TRIZ

Today I was able to read some chapters from "Simplified TRIZ", by Rantanen, Kalevi, and Ellen Domb. ". St. Lucie Press. © 2002. . (accessed September 9, 2011) . It's only the first two chapters yet, but they did introduce me to some basic concepts:

1. Contradictions. Every problem to be solved is aimed at solving one or more Contradictions. There are Tradeoff Contradictions and Inherent Contradictions. A contradiction often consists of a tool and an object.
2. The Ideality of the system. A measure of how close it is to the perfect system.
3. Unseen idle resources.

Let's try these on an example.
For example, how can we serve customers in a restaurant faster without increasing prices? The tradeoff contradiction is that we can increase the number of waiters, so that more customers can be served at the same time, but that costs money and the restaurant would have to raise prices. So something good (faster service) also means something bad (higher prices).
We could compromise: hire waiters only at peak times, or fire all waiters and hire them back at a more flexible rates and times. But TRIZ does not seek compromises.
In the ideal solutions all customers are served quickly and costs remain the same.
There is an unseen or hidden resource: the customer. If the customer serves as his own waiter, the cost is reduced and the customer can be served much more quickly. Now the concept of a self service restaurant is well known, but it took from 1948 to 1954 to get established.

Definition: A good solution is one that resolves a contradiction.. Another concept is that of Patterns of Evolution. Systems evolve according to certain patterns, and these patterns can be used in many ways to get new ideas and predict the evolution of the system. Finally, there are 40 innovative principles that give concrete clues for solutions. Let's have them in a diagram:

Figure 1.

Innovation

TRIZ, theory of Inventive Problem Solving, based on the work of the russian inventor and researcher Genrich Altshuller, is slowly gaining the popularity it deserves.

I discovered a nice series of you tube movies, see http://www.youtube.com/watch?v=zcKy0psDlf4.

In addition my own employer Capgemini will be using the principles and has appointed qa special innovation officer.