Self-organising teams. Introduction

Nowadays business have arrived to understanding that personnel is the key element of the success. One of the modern ways to organise employees is self-organising teams. Talking about software development, those teams have been successfully applied in agile development as agile methods promote a lot using this type of teams over others.

Self-organising teams or autonomous teams are employees teams having a high level authority in the organisation to make (independently) decisions on many (some) aspects of their work like planning, schedule, choice of tasks, budget etc.

Autonomy can be divided on external, internal and individual. The external autonomy of a team defines an influence of management and other groups of the organisation on the team and so how much they do restrict freedom of this group. The internal autonomy shows the the degree to which all members of the team participate in making decisions etc. This autonomy is low if there is one person making all internal decisions. Notice that the group could still will have a high internal autonomy having some type decisions made by one person if members delegated the right to do those decisions to that particular person. In this case they have a right to dismiss tis decision and returned to joined decisions once again.

Important requirements for creating self-organising teams are: such selection of participants that all team members have a similar level of knowledge and respect within the organisation; share a belief that collaborative work is "a must" in order to achieve project goal; and finally all team members are ready to give their best (not to wait each single minute been on work the day end moment).

Co-working - rules

Co-working is an interesting trend in the modern life. Once I will return to this topic, but now I just would like to share rules of such community hoping that they will not blame me for stealing their content: my intention is just to show how such community live by publishing the minimal law they figured out for themselves as a typical way to organise such groups:

GROUND RULEZ for Citizen Space

• we reserve the right to refuse service to anyone. if a key holder asks you to leave, you need to skedaddle
• no bittorrent, no pr0n
• clean up your garbage and recycle (blue bins are recycling, dude)
• you break it, you buy it
• coworking is an extreme sport, don’t sue us if you break a blood vessel in your forehead dealing with windows, apple’s DRM, or anything else
• don’t be a dIck

Software start to convert an ordinal car into a context sensitive vehicle

Today I have read a news that highlighted a trend appeared during last years - car manufactures started to convert cars (i.e. just a combination of metal parts moving by a petrol engine) into something I would call a context sensitive vehicle: "Ford's New MyKey System Helps Teens Drive Safer, Conserve Fuel; Gives Parents Peace of Mind".

The news says: Ford's MyKey feature -- which debuts next year as standard equipment -- allows owners to program a key that can limit the vehicle's top speed and audio volume. MyKey also encourages safety-belt usage, provides earlier low-fuel warnings, disables switching stability/tracking control systems and can be programmed to sound chimes at 45, 55 and 65 miles per hour.

More than half of parents surveyed worry that their teen-age children are driving at unsafe speeds, talking on hand-held cell phones or texting while driving, or otherwise driving distracted. More than a third of parents also are concerned that their teens do not always buckle their safety belts when driving.

According to the National Highway Traffic Safety Administration (NHTSA), teens are more likely to take risks such as speeding -- a contributing factor in 30 percent of all fatal crashes. Teens also are less likely to wear safety belts than older drivers.

Notice that this system is not the unique one. For example Green Road's system presented earlier this year is able to identify a lot of different aspects of the drive like acceleration level, breaks using frequency and so forth and report that to the front panel using light of different colours, so you [or parents] can identify the none-econimial driving mode [read unsafe] by the red one or even see that in the real-time if the car was let to a child or a friend of you.

Testing methods

Here I would lkie to give a short review of the article called "Evaluating testing methods by Delivered Reliability" as I find its approach to the testing process to be very interesting and slightly different from the classical one.

The paper states that there are two majour approaches in testing:
a) "debug testing" where the objective is to probe the software for defects so those can be removed in order to achieve adequate quality
and
b) "operational testing" where the objective is to gain confidence that the software is reliable assessing its existing quality.

Although both methods look very similar, that is a devil in details. The debug testing concentrates on probing all possible (available) features and their combinations and the operational testing concentrates on "real life" scenarios of using the software.

In the result the debug testing covers sufficiently more during the test process, but could actually lead to finding mostly unimportant bugs and force the team to spend valuable resources on fixing those (leaving us without test/dev team time and resource to test more important cases).
Here the importance of a bug is calculated as a probability that the bug case will appear in the real use of the software and if the probability is very low, then the bug is unimportant.
Notice that in the result of this, we can even state that sometimes the debug testing will find bugs, but will not lead to the real quality improvement as the massive low importance bug fixing is not worse to do in compare to fixing one real case bug.

The debug testing by its nature is an active hunting for bugs, while the operational testing is a passive one: test cases are just executed and testers are waiting for a bug to happen, rather than trying to imagine cases that could lead to errors.

As we are dealing with selection of scenarios to be used in the operational testing, we can say that the operational testing is a probabilistic testing: it selects a set of test cases to be used from all possible combinations basing on the probability of each one to appear in real customers processes (use). Therefore this kind of testing greatly depends on experts who are assigning those probabilities or write required real-life use cases.

Finally we would like to mention that nowadays wide believe that the testing is a very expensive and time/resource consuming process is produced mainly by the fact that industry uses exclusively the debug testing. There is just a very minor number of companies where the operational testing is applied, although the common shortage of resources should obviously stimulate wider use of the operational testing approach.