Amount of information given by tests

The “amount of the information” given by failing tests about the broken functionality may vary because sometimes many tests may fail as a consequence of one single functionality broken. In the following example the amount of information tends to zero as the complexity of the tested object (a state machine) increases (in term of number of states), unless specific  programming practices and constructs are used (that in this case will be injecting the initial state by constructor ).

I have a state machine, that has an initial state A, that switch the state from A to B on input ‘ab’; and from B to C on input is ‘bc’

If there is no way to set initial state to B independently from the A->B transition then the tests become somehow dependents each other: the second tests need to do a setup that works only if the ab functionality, given by the first test, works.

So the amount of information given by a test failure respect to a broken functionality as the complexity of the state machine increases, tends to zero because every test need to start from the initial state.

In unit testing the problem is solved injecting the initial state by constructor, but in other type of tests the solution looks less obvious, with the cost of having tests with low information, and so low value.

BDD like specification of the behavior of the machine are:

Test 1 - “go to B, from A”

“given the state is A // (i.e. the initial state)

when the input is “ab”

then the final state should be “B”

Test 2 - “go to C, from B”’

given the state is B

when the input is “bc”

then the final state should be “C”

One way to prepare for the test 2 (the “given” part), that requires starting from B, is starting from A and going to B so “given the machine is in state B” were to become “given the machine is in state A, and the machine is given the input ‘ab’:

given the machine is in initial state A

and the machine is given the input ‘ab’ // going to state B

when the input is “bc”

then the final state should be C

In case of failure of the tests the amount of information provided by the failure is not always the same:

If the broken functionality is the  B->C transition, then only the second test is broken

If the broken functionality is the A->B transition, then both the tests are broken.

So we lack of one-to-one correspondence between failed test and broken functionality.

There is a fragility in tests: single broken functionality affects many tests as side effects.

It can be fixed if we are working at an object level, modifying the code in order to set the initial state by construction:

public class StateMachine {

public StateMachine() {

this(state.A)

}

public StateMachine(State state) {

this.state = state;

}

....

}

Now one broken state transition code affects only one state-transition test, and one broken test may means that only the “then” part doesn’t work (or that the constructor doesn’t, which will affect all the tests in that case)  so the “fragility”, (or “entropy”, or “unpredictability”, or “noise”....) is reduced.

A little bit more complicated is finding a “workaround” if we talk about tests from the user prospect, like in tests about the web navigation, where the “machine state” is basically a navigation path from the home page to the news, and from the news to the tech-news:

Test 1 - “see the news”“given connect to the home page

when I click on ‘news’

then the header of the page should be “news”

Test 2 - “see the tech news, subpage of news”

given I am on homepage

when I click on news

and I click on tech

then the header of the page should be “tech news”

If the “news” button does not work, both the tests are broken, as in the above example.

Here there is no a “straightforward” way to “set the state” relate to the “given” part in a way independent from the other functionalities, and so there is still the problem we talked about.

So for tests closer to domain it is more likely that the problem of “noisy” tests is reduced,

Keywords: “information theory” (Shannon), “Bayes Theorem”, “value of Information” (Book: “how to measure anything”).

The A3 can help keeping some human biases and fallacies at bay

I am describing here why in my personal opinion the benefit of the A3 problem solving method in removing some biases and fallacies ( straw man, or the slippery slope) that otherwise may arise in a method-less problem solving.

A3 is best described in some books, for example “Understanding A3 thinking” or “Toyota Kata”.

However, I’ll describe it a little bit here: A3 based on the A3 paper, used to take notes of the problem, root cause analysis, and possible countermeasures. The problem can be well described as a measurable gap between the current condition and a target condition (or “desired new standard”).
A deep root cause analysis is important part of the process, and one way for doing it is using Ishikawa diagrams and 5-whys. Countermeasures against (actionable) root causes will be considered only after a wide root cause analysis is done.
It is basically a “yes, and...” conversation: “we have this possible cause...”: “yes, and the cause of this cause can be  ...” (etc...) or “yes, and there also these other possible causes”, and so on...
It is important to do first the analysis of all the possible root causes, and then finding the countermeasures phase, because otherwise there is the risk of entering deeply on some specific deep path of arguing about actions, consequences, and so on considering too few hypothesys about some too specific, and unlikely scenarious.

This may open the door to some fallacious arguments.
Example: in an hypothetical context of solving the problem of how to reduce criminality an argument related to a possible root cause is about the circulation of cash: “untracked cash is one of the causes of the prosperity of many criminal activity”.
At that stage, if we avoid the exploration of other possible root causes (for example adding something like “unemployed people are more easily involved in the gangs”), and instead we follow any possible path of the consequences of this first root cause, then we may get stuck on a single path and just “hypothetical” consequences, and objections, that create a sort of paralysis.
“so do you want us to be controlled in each transaction so making us losing our privacy”?
This is a sort of attacking the straw man argument, because is an objection to the hypothetical countermeasure to such root cause that is not the same thing as the the original argument, no matter if the arguments against this countermeasures could be justified, because it is just a separate thing
This going deep into objecting just hypothetical side effects (straw men) can be avoided if we separated a wide root cause analysis from the countermeasures analysis.

Another example: “our stream value map, and also our kanban board, show that the process of setup of the official build takes time X, which is greater than the time Y, that is the gap that we want to reduce, according to the target condition”.
This claim says nothing about what to do, if possible, to how to reduce this time X (e.g. automated builds etc...).
It is completely neutral and objective at that stage. It just invites to consider that we may reduce such time with any countermeasure _that we are going to discuss later_, then we can have some chance to reach the target condition of reducing the cycle time.
The straw men that comes into the “conversations” could be “I know those guys: they do a great job, and they strive working overtime many days. I have seen that. Are you saying that they don’t know how to do the right thing?”.
Nobody is claiming anything about people doing their job good.
The fact that the process clearly separates the root cause analysis and finding countermeasures helps keeping those pointless fallacious “deph first” discussions at bay.
Only after all the root cause are considered, then there is the phase of finding “countermeasures” to address root causes. Countermeasure can have also some weight related to the the hypothetical cost/efficacy ratio,  just to make sure everybody knows that not all the countermeasure are equal. Moreover some countermeasure could also be not pleasant for anyone addicted to some complexity. Yes, unnecessary complexity, messy situations, big ball of muds can be addictive (according to system thinkers there may be concern in really addressing problems "What will life be lie when the messy situation is no longer a big worry? Sometimes 'owing' a big insoluble problem is almost adictive" - Rosalind Armson, Growing Wings on the Way).
Countermeasures usually means try to improve in some area, and that is one of the main reason that we need to make sure that there is always respect for the people. The analysis is focused on understanding, and not on judging. Is the facilitator/mentor the guy who will hopefully be able to create a safe learning environment such that the sense of satisfaction about improving is  greater than the disappointment of uncovering flaws in the process (just because saying that the problem could be on people happens to be unfair -  or I’d say, even impolite?).
So the countermeasures found can take place in order to validate their hypothetical impact in term of getting closer to the target condition. Everybody makes sure that the experimentation will be “safe-to-fail”, and nobody expects that everything will magically work. How to measure the result, and when to go and see what happened is part of the the A3 check phase.
In the Cynefin approach, there is a "complex area", where the cause-effect are not clear there is the need to experimenting by "probe-sense and respond". Anather analogy is the variety in nature and the Fisher Foundamental Thorem: making more experimentations is like creating more variety, and, the theorem finding is that this variety is proportional to the increasing of the rate of fitness, in term of genetical selection.
The A3 also establish in advance what to do if the experimentation will be successful (example: if it will be successful, then we will do some training to other departments about new good practices discovered by this experimentation. If it will not be a success, then restart again considering the using other countermeasures), which is the “Act” phase.
Everything basically is follows the Demming’s "Plan, Do,Check, Act" cycle, close to the scientific method.
More often than not the solution that are likely to be found via A3 are not so complex, but I think they are not meant to. In my experience, the solutions need to be simple, and I also found in books like “The Checklist Manifesto” and “The Influencer” how simple solutions can create dramatic improvements, as long as the solution are carefully studied, and experimented. In Checklist Manifesto, the title says all. In "The Influencer" you can see that many simple solution may just be there, it's just a matter of discover them and "adapt" to make them used by all, like in the story of attacking the diseas of the "Worm of Nueva Guinea" (that in fact has been almost eradicated by now). In that story it has been simply discovered that the disease did not attack people used to filter water simply using their skirts.

So effective solution can be simple, and backing to team, process problem you may discover that they are:

- find the right checklists,
- make sure that information radiators are kept up to date
- make sure that you ask some specific questions
- make sure everybody knows that is in charge for reminding good practices by checklists to anyother no matter of their authority
- introduce some unofficial “shortcuts” shortening the feedback cycle in the formal delivery process between development and tests
- be sure that someone of your team will attend other teams daily Scrum meeting if you have some dependencies

and so on...
So what’s the point of using the A3 method if the solutions are so simple? Couldn’t  we just figure out such “solutions” without having to set up a specific method?
Well, at least in my experience, the point is pointing also to the “invisible elephant in the room”,  mental traps like "habit" or “history”, get rid of the blaming-culture, and get properly out of their comfort zone, without falling directly into “panic”.
I don't think that Top-driven changes without any bottom level  involvement can go very further because of risks of being too much based on wishful thinking, to be not systemic, neither resilient (where a definition of resilience that I like is "The capacity of a system to absorb disturbance and re-organize while undergoing change so as to still retain essentially the same function, structure, identity and feedback")
I think that a necessary condition to make a change in some action systemic is by the rule “I need to know why, as well as what, in order to decide an appropriate how”, because "Knowing the purpose of an activity creates opportunities to do it well" (from "Growing wings on the way - chapter 13").
By A3 it is at first clear, and well defined, the what, in term of target condition, (and also the way in term of an higher order target, or better, in term of "vision" - see picture from Toyota Kata), and the aim of the process is just to discover the how. After people learned the “how”, they still have to remember the “what” and the “why” because they all together worked to figure out the discovering process starting from them.

Let’s also take a look at the “hindsight” bias, and why A3 can take this bias at bay.
We, as people involved, need to work together at the first place so it is less likely that someone  could come up after all with the “I already knew it, if I were there, then I could already tell you”. Everybody involved should already be there at the first place if he or she can help. This helps reducing this hindsight bias abuse
You cannot know how honest is any claim related to the “I already knew”.
As Tetlock shown in studying the “hedgehogs” against “foxes”, in Expert Political Judgment, many people that act as pundit, happens to be expert just because are able to explain everything with hindsight, and in the case they are invited to speak before something happens, and then fail, still they are likely to abuse of self-sealing / no true scotsman based explanation of their hindsight  claims.
So basically, in the kaizen process guided by A3, we are invited to make hypothesis and experiments, and have a clear measure in advance about how to measure the progress, and check without fearing of bad hypothesis, and we know that failure is a crucial learning (safe) part of the experimentation.

I have experimented A3 in the past, but unfortunately I am afraid that I haven’t been in a position to make always sure to protect these points in the process. “With hindsight” I’d say that some simple rules like the Scrum “pig” vs “chicken” must be strongly protected always, in a phisical way. Also there is the need of a “sufficiently powerful guiding coalition” (lack of it is error 2 of the 8 defined by John Kotter), to ensures that the message of the importance of those tools is never underestimated.

References:
Books - Toyota Kata, Understanding A3 thinking, Leading Change, The Checklist Manifesto, The Influencer, Expert Political Judgment

Just for fun about the "hindsight bias", you may take a look to this part of “Captain Hindsight” episode of “South Park”

(note: I am not responsible for the content of external resources content, that, moreover, may change since I finished writing this post)


























Reasoning, arguing, is related to to supporting conclusions, explaining a position, discovering some truths, by logic and rationality.
I think that having a conversation is more than arguing.
Conversations may question the already established truths and their supporting arguments, and conversations skills are about the techniques used to help uncovering those facts.

The need for













I want to discuss an argument, from this little book available on line: http://www.newrepublic.com/article/books-and-arts/magazine/100978/form-fortune-steve-jobs-philosopher#

“He saw revolutionary potential in the most obscure things; he even claimed he had “never seen a revolution as profound” as object oriented programming—a niche field that was the focus of his work before he returned to Apple”.

For me the argument is really bad if is meant (as probably is) to talk negatively about the guy, as probably it is actually.

I’d use a parallel reasoning argument to make it clear:

“he saw revolutionary potential in the most obscure things; he even claimed he had “never seen a revolution as profound” as the film making - a niche field that was the focus of his work from 1895 to 1900”  

To be potentially revolutionary something has to be obscure, otherwise there is no need of a “revolution” to make it spread. So in that sense the argument is begging the question.

A little bit better the argument is if the story is that the film making was a niche field in that era, and has been always niche field until now. “such film stuff was obviously destinated to still be a ‘niche field’”

But it did not turned in this way: if the movie industry turned into a commercial, artistic, cultural revolution, then the argument is unsound.

I think a possibility to make it better is if we want to argue that the guy is smart: “he saw the revolutionary potential of the movie making, when it was still was a niche field!”

Back to the original argument “the smart guy did see the revolutionary potential of the object oriented, when it was still was a niche field!” I want also to say why the parallel arguments fits:

object oriented was actually a ‘niche field’ in the period the author talks in the sense that the mainstream programming languages were not object oriented (as Basic, Pascal, C, ...).
After some year, the mainstream programming language became Object Oriented (Java, C#, C++, Objective C, Ruby), so he after all was not so wrong in consider such discipline a potential revolution.

Basically the argument is not good.

What do you think?
(p.s. a friend of mine answered that “object oriented programming” is actually a “niche-field” in the sense of “well done object oriented programming”, and it reminded me the “no true scotsman fallacy”  http://en.wikipedia.org/wiki/No_true_Scotsman but, it’s enough for now... )

The calibrated estimator contest

In this post I’ll talk about a game related to estimating with weights, and verifying how “calibrated” are the estimates. I will just use two sizes (Small and Large) to make the game simpler.
If the experiment succeeds, that means finding calibrated estimators with certainty level closer than 100% than to 50%, then more complex experiments with more sizes can be done. The aim of the game is not to give an answer to the question if estimates must be done, but only about if estimates “may” be done. A paradoxical result could be when the winner, the most “calibrated” estimator, will be the one that gives the maximum uncertainty (50%), so confirming that the “right answer” should has been be flipping a coin.


A calibrated estimator is someone who is able to correctly weight, using confidence intervals (or probabilities in case of binary-true/false questions), his uncertainty related to an unknown values.
To measure your skill as calibrated estimator: you are suggested to guess some unknown value answering questions (like: "The internet 'Arpanet' was established as a military communications system in what year?"). The answer must be a confidence intervals of 90% (an interval that you would bet will contain the real value with 90% of probability). You are considered a calibrated estimator if you will be right 9 times on 10.
(of course it applies only if you don't know or don't remember the real value!)
People are mostly overconfident (i.e. when they claim 90%, they are right only 60%, 70% at most), at least before doing practices with some calibration exercises.
For binary (e.g. true/false) questions the procedure is as follows: you answer to binary questions, and give certainty levels like 50%, 60%, ... 100%, and convert such values in probabilities (0.5, 0.6, ... 1). You are considered a calibrated estimator if the number of this sum  should be  the same as your correct answers.
Here I want to suggest an application for a "game" game the I would call "the calibrated estimator contest".

This apply in any situation where you (or a team) have a todo list of working items represented by some cards or sticky note.

1) consider two sizes for any working item: Small and Large
2) select some high priority items (10 of them is a good number I think) from the todo list, and for each of them, invite players to write secretly her large/small guess with a probability (from 50% to 100%).
3) ask each player to put her guesses in closed envelopes with her name.

Start working and tracking the actual time.
It is suggested to track in real time using "prisoner metrics", i.e. tracking using a checkmark for each  quantum time.

After the items are done:

order incrementally the items by actual timeboxes (it should be easier having used prisoner metrics), from the left to the right.
Spot the median, and consider the items on the left of the median as small, and the items on the right of the median as large (about the median: put it on the less numerous set, or flip a coin).
Each player then will open the envelope, get her guesses and do the following:
Count how many actually Large or Small values correspond to the guesses.
Then count the sum of the probability given for her guesses.

The one that is more calibrated than others (i.e. has a total of sum of probabilities closer to the actual number of times she was right) , will be celebrated as the winner.

Use cases:
If I mark my guesses as 100%, I’ll win if all the actuals will correspond to my guesses. I should do this kind of bet if I think that there is high predictability (at least when considering the items compared relatively).
If my guesses are all 50%, then I win if I am right 50% of the time, so more or less I play in this way if I think that there is no better guesses than flipping a coin.
This can be a funny exercise for deciding if we “can” estimate.
In fact we “can” estimate if:
1) there are calibrated estimators
2) the certainty given by those estimators are closer to 100% than to 50%.

I said we “can”, not we “should”. “should we” it’s another story.

The "wisdom of the crowd" variant is another possible game activity: make an average of all the guesses, and find how good they are.

Note: I have not tried the game until now. I’d like to suggest anybody interested to try it, but there are no guarantees.  I’m looking for feedback about.

Here you can see some part of "How to measure anything" book that inspired me, particularly in the "calibration" part.


Variation for “estimating the value”: another possibility is guessing the "value" of a feature, for example providing confidence interval related to how many times a new feature will be used. The procedure essentially should not be so different, I may blog about later.

That’s all, thanks for reading, I’d like to get feedback.

p.s. warning: I did not quote definitions from the book, so I may made some mistakes. I apologize just in case. You are invited to read excerpts from the original books in case of doubts (and hopefully give me notices about any mistake).

Value of Estimate as Value of Information

The claim of this post is that estimates are information that (should) reduce uncertainty about decisions that have economic consequences, thus they (should) have value.

Here is why.

A mantra of any Agile method is that you need to produce value, and you have to do it as soon as possible. A new mantra is that estimates do not provide any value. Thus you should drop them,
Why?
If doing an activity will take time T, and you add the time t for estimating T in advance, then the total time will be T+t instead of T. Thus, given that spending time t+T costs more than spending only time T, you should not estimate.

There is an argument for estimating instead:
Suppose that the stakeholder needs to select between two features F1 and F2 with values V1 and V2.
If their costs C1 and C2 are not the same then she could decide a trade-off, for example comparing V1/C1 and V2/C2. (max value, min cost).
The cost is the time, of course.

She actually does not know exactly the values V1 and V2, and the costs C1 and C2 neither.
She can be better than the technical team in "estimating" the difference between V1 and V2, but in the same way is the technical team that should be better than her in "estimating" the difference between C1 and C2.

So it must be rational trying to maximize the V/C having a discussion with the team about comparing C1, C2...

So the estimation provides value because it determines actions that have economic consequence (and the difference between those consequences is the value of that information.)

All this means, simply, that despite estimating has a cost (t), it conveys value (value of information) as any other team activity.

(Yes, but the economic consequence of the order in picking up the F1 or F2 first or not cold be less valuable if F1 and F2 need to be done both for sure, and nobody is going to use the product before both the features will be done.  That's another story. If you think in this way for all the "already known" features F1, ... Fn of a Product, then all of this becomes a little bit unflexible, not realistic, and not... Agile anymore)

(book: How to Measure Anything, Douglasùùù W. Hubbard)

Usare metafore nelle retrospettive. Dalla "un-conference" Ale2012

Marc Löffer nella sua presentazione ha suggerito un formato per la retrospettiva basato su metafore.
Per esempio la metafora calcistica prevede un vocabolario basato sul calcio e di raccogliere i dati dell'ultimo Sprint come se questo fosse l'ultima partita giocata (in sostanza, la cronaca dei momenti salienti della partita).
Le fasi successive (raccolta dei dati, generazione di "insight", deciere cosa fare) dovranno rispettare sempre la metafora.

Dopo la sua presentazione ha proposto un Open Space per continuare l'argomento e provare altre metafore.

Nell'Open Space sono state prese in considerazione diverse metafore: le avventure di una banda di pirati, una arrampicata in montagna, un viaggio di vacanze.

A riguardo della metafora dei pirati, il periodo assimilabile ad uno Sprint potrebbe essere quello che va da quando si salpa per un assalto o per la ricerca di un tesoro etc... a quando si torna a terra a godersi il bottino.

Per il vocabolario abbiamo pensato a termini come:
veliero, mare, cannoni, terra, uncino, tesoro, assalto, bandana, benda copriocchio, spada, pistola, pallottole, e così via...

La raccolta dei dati verrebbe tratta dal diario di bordo.

Poi ci siamo fermati, ed abbiamo deciso di approfondire una seconda metafora piuttosto, scelta tra l'arrampicata e la vacanza, ed abbiamo preferito quest'ultima.

Per quanto riguarda la raccolta di termini abbiamo elencato:
carta di credito, biglietti, documenti, albergo, manuale-guida, cartine...

Per la raccolta dati abbiamo suggerito le foto, le cartoline, le telefonate fatte a casa, qualsiasi tool usato per condividere le esperienze (magari i messaggi su un blog o su un social network...).

Per la generazione di insight abbiamo pensato alle risposte a domande come: "se oggi ti trovassi nell'ultimo giorno di quel viaggio, che cosa lo renderebbe memorabile?"
Altre domande, per il decidere cosa fare: "cosa porteresti o no con te la prossima volta? Dove ti piacerebbe andare? Quale è la cosa più importante che hai imparato?".

E' probabilmente una tecnica in grado di rendere la retrospettiva più attraente, anche magari va ben preparata in modo da evitare metafore forzate, pesanti, o che non riproducono una sufficiente complessità.

Penso che questo approccio "fantasioso" possa essere utile anche per sdrammatizzare (per il fatto di evitare di ancorarsi troppo all'evento concreto e al richiamo delle relative emozioni, soprattutto se negative).

Una nota positiva è che in questo Open Space tutti sono rimasti fino alla fine (senza applicare la famosa regola dei due piedi). E' stata una conversazione proficua in una atmosfera rilassata.

(p.s. vedere anche http://finding-marbles.com/2012/03/19/retrospective-with-postcards/)

About understanding the value of Technical Stories

In software development, Technical Stories are activities that don't provide direct business value. Their aim is "just" putting the code in a better state, improving the process, reducing the technical debt .

However tech story actually have indirectly a business value, though, because their effect is making the cost of the next features cheaper, more closer to their “intrinsic difficulty” (some other terms are used here, for example “essential complexity” or “essential complication”, opposed to "accidental complication").

Under these simple terms  technical stories should have the maximum priority and there is no point of procrastinating them or giving them a low priority.

That means that there is no any “decision problem” here, because the answer is  always “yes” (ok, almost always, see later).

Second claim: trying to involve someone that is supposed just to deal with R.O.I. (the Product Owner in Scrum), will probably end up in a not rational decision.

Let’s see (my) why.

1)     They must have maximum priority

Suppose that the cost of the story is R.

If we leave the code base (or our process) as it is now, so we don't implement the Tech Story, then the cost of any other new story will be higher, say 20% higher.

The decision problem, with the goal of minimize the costs is like this:

If the cost of the remaining stories to finish the project (on a clean base code) will be T, then, if we work on that story, spending an extra R, the total cost to finish the project will be T + R.

If we don't work on the tech story then the rest of the stories will cost 20% more, i.e. the cost to complete the project will be T*1.2

So the solution to the decision (to minimize costs) will be: add the story only if T+R < T*1.2, i.e. R < T*0.2 .
Looks a very simple model, that just comes out from the definition of the tech story (something that reduces the cost of the work we are going to do later).

Probably we can't show those numbers for real, but it does not matter so much as long as we are talking about what may happen in the long run.

In fact, if we just assume that the extra cost without implementing tech story is positive (no matter how small it is), then the equation that must hold to decide doing the story is R < T*X.

Increasing T (basically the amount of work to be done to complete the project), the coefficient X of extra cost for not paying the technical debt, with a total T*X, is very high even for very small X (we just have to assume it is positive, of course).

So when we reason by this model, there is not any "yes or not". it should be always yes. We do the story, as soon as possible, for long term outcomes.


2)     A guy that just cares about the outcome from the “business point of view” supposed to do a decision about (usually the Product Owner), will likely end up in making an irrational decision.

This statement comes out as a variant of the S. Petersburg Game that simply states: you want to pay very little on the short terms when the outcome is very big (virtually infinite) on the long term. Irrational but human.

We heard or read somewhere that the P.O. must be accountable for prioritizing the tech story, but an alarm should trigger in your head here.
I would say that under these term the P.O. must be just informed, not involved, accountable, or responsible. Moreover the sprint burndown should be related only to normal user stories, leaving out the tech stories. (possibly we may have separate tech story burn down, or a separate technical debt backlog, something like that).

(In some exceptional case we may take out the technical story for some reasonable short term outcomes, for example a "go-no go" deadline).

Now I want to go deeper about how to make sense about the value of user story in a way more related to conversations and system thinking.

We need to promote good conversations if we need to involve people. The old habits are radicated in the corporate culture. A model like the simple one I used probably is not enough to convince skeptical people.

There can be a kind of addiction to a bad process, because it can be easier keeping there the option of blaming: blaming the process, blaming the guy that worked before us, and so on…

So, teams got stuck in a bad process trap that introduces waste difficult to escape from. Everyone is, or appear too “time crunched”, being unable to effectively care about improvement. It’s hard to help taking a breath and fix the process, one piece at time. (Actually the A3 based improvement is for me a very great tool, and I’ve seen some concrete progress about, but this is another issue. Also useful hints to promote the change are described in “Driving Technical Change”).

Another useful way is trying to promote and facilitate conversations with the P.O. like this one described by Henrik Kniberg in “Scrum and Xp from theTrenches”:

Team: “We have some internal tech stuff that needs to be done.
We would like to budget 10% of our time for that, i.e. reduce focus factor from 75% to 65%. Is that OK?”
Product owner: “Hell no! We don’t have time!”
Team: “Well, look at the last sprint (all heads turn to the velocity scrawls on the whiteboard). Our estimated velocity was 80, and our actual velocity was 30, right?”
PO: “Exactly! So we don’t have time to do internal tech stuff! Need new features!”
Team: “Well, the reason why our velocity turned out to be so bad was because we spent so much time trying to put together consistent releases for testing”.
PO: “Yes, and?”
Team: “Well, our velocity will probably continue being that bad if we don’t do something about it.”
PO: “Yes, and?”
Team: “So we propose that we take approximately 10% off  of this sprint to set up a continuous build server and other stuff that will take the pain off of integration. This will probably increase our sprint velocity by  at least 20% for each subsequent sprint, forever!”
PO: “Oh really? Why didn’t we do this last sprint then?!”
Team: “Er... because you didn’t want us to...”
PO: “Oh, um, well fine, sounds like a good idea to do  it now then!”


In this example technically the P.O. was stuck in a “quick fix trap”, the team clearly realized this, and just needed an effective conversation to convince the P.O. to approve an escape strategy. Makes sense.

Another interesting way related to conversation is via system thinking tools. We can involve people making “snapshots” of  all their views in term of systems (Snappy Systems).

So let’s figure out the use of the tool in this situation:

Phase 1. List all systems about a Tech story:

The generated ideas can be like follows:

-         a system to remove accidental complication
-         a system to reduce the cost of adding new features later
-         a system to keep the base code steady
-         a system to keep the process health
-         a system to reduce the probability of making the code unstable
-         a system to apply continuous improvement
-         a system to learn writing clean code
-         a system to implement kaizen
-         a system to reduce the possibility of ending up with conflicts and blame games
-         a system to reduce the probability of having more bugs later
-         a system to reduce the time needed to fix the bugs
-         a system to reduce the global cost of development
-         a system to reduce the global cost of maintenance
-         a system to work at a sustainable pace
-         a system to pay technical debt



Phase 2: list of the stakeholders:

-         the development team
-         the customer
-         the company
-         the version control system
-         the Integrated Development Environment with refactoring tools
-         the build script
-         the continuous integration system
-         the automated test suite
-         the testers
-         the CEO
-         the market
-         the Communities of Practices


Now the system from the perspective of some other stakeholder.

Happens that the stakeholder is the market

-         a system to reduce hidden costs
-         a system to have a long term efficient competition
-         a system to reduce waste
-         a system to make the customers happier
-         a system to create a healthy market competition
-         a system to reduce the “market of lemons” syndrome
-         a system to promote the professionality
-         a system to ensure that the company will be long living


It does not matter so much how true they are, it’s just about promoting a discussion and share insights.

Now, the Sinister Systems, most important for dealing with conflicting views:
         
-         a system to violate the rule “if it works, don’t fix it”
-         a system to excuse for not doing the things right at the first place
-         a system to avoid commitments to [short term] business goals
-         a system to do something that nobody outside of the team can understand
-         a system to add learning activities at the expense of the company
-         a system to deprecate how we have been working until yesterday

Enough for my "homework" in Model and System Thinking.

I like very much the “sinister system” approach, because it is like acknowledging what could still go wrong and why (a sort of "pre-mortem" analysis).

Ok that’s all, in my mind comes a lot of ideas about it, there is something for more posts and more experimentation. Hope this reading will help someone. Feedbacks are welcome.

Il Gioco Dei Nomi in Multitasking

Come recita un antico detto cinese "Dimmi e dimenticherò, mostrami e forse ricorderò, coinvolgimi e comprenderò."
Cosa c'è di più coinvolgente di un gioco?


Il gioco in questione è il Gioco dei Nomi in Multitasking (ovvero: Quanto Ci vuole per Scrivere un Nome) di Henrik Kniberg, descritto in un articolo di 21 pagine, anche in Italiano (traduzione mia).


Il concetto che questo gioco vuole trasmettere è l'effetto positivo del lavorare concentrati su una cosa per volta (o comunque di limitare la quantità di cose che si fanno contemporaneamente, il cosiddetto wip). La cosa è un po' "controintuitiva"  perché implica che bisogna iniziare le cose più tardi per finirle prima!


Fare tutto nello stesso momento, e continuare ad iniziare nuove cose senza finire quelle in corso significa non sapere quando si finirà, fare peggio, lavorare sotto stress, aggiungere spreco dovuto al tempo necessario a cambiare contesto tra un'attività a l'altra, e così via...


Insomma il multitasking sembra essere proprio il male assoluto!


Questo è quanto si evince nel gioco.


Sarà solo un gioco, ma dimostra soprattutto quanto "non sappiamo" dell'effetto del multitasking,  quanto rischiamo di non renderci conto della sua profonda inefficienza, per lo meno nel caso proposto dal gioco in questione. Bisognerebbe poi chiedersi: se nel semplice problema posto dal gioco si scopre (come probabile) di aver pesantemente sottovalutato l'effetto del multitasking, non c'è alcuna ragione per escludere che questa sottovalutazione non sia in atto anche nel proprio lavoro e con conseguenze importanti.


Poi, come dice l'articolo alla fine, si è liberi di trarre le proprie conclusioni, o di decidere se e come questo si applica nel proprio contesto, se si vuole iniziare a tentare di rilevarlo con delle misure, e se si vogliono prendere le relative contromisure (cioè, banalmente, limitare il wip e fare pressione perché si agisca sulle cause delle interruzioni).


Da provare con i propri colleghi o con il proprio team, E' semplice, divertente, breve, e consente una proficua discussione.


P.S. Qui c'è il link diretto alla traduzione italiana.