Note to self 009 - it's called Hanlon's razor

And it goes: Never attribute to malice that which is adequately explained by stupidity.

Although sometimes Heinlein's Razor or Napoleon's unnamed version of it seem more appropriate...

Heinlein's razor:
Never ascribe to malice that which is adequately explained by incompetence, but don't rule out malice

Napoleon's unnamed epigram:
Never ascribe to malice that which is adequately explained by incompetence.

See http://en.wikipedia.org/wiki/Hanlon's_razor

Note to self 008 - It's not "You are " it is "I observe "

Dear Michael, [talking to myself as usual] I noticed that you complain about incompetent people. When I hear that I tend to put you in the category "egomaniac". What can we do about that?

Sounds much nicer than: "Michael, you are an egomaniac. I know that because you complain about incompetent people" doesn't it?

Even if you're convinced that the other Person (or team for that matter) is malicious, unhelpfull or in any other way "bad" remember that that's just the way you perceive it. Talk about yourself - that is something you can be sure about and that can't be argued away. [It is very hard to tell somebody "no, you do not feel that way" - although sometimes there are people who try.]

Note to self 007 - I still can't handle incompetent people

More a point I still have to work on than an actionable note to myself:

Don't get overconfident. It's not enough that somebody is incompetent - you've got to be able to convince people of this seemingly obvious fact. If you can't pinpoint it - just let it go for the moment. Especially if you can't put a number to the incompetence.

As a matter of fact this is something that I've never really gotten around to. 

[Explanation of the note for reader who are not myself] 

There is a certain kind of incompetent people (e.g. they just have no expertise in the very thing they are doing, they are literally incompetent in such a way that they lack the competences that they need to perform their job) that I still don't know how to handle - those that don't know the details of the job their doing but are yet well versed in easily graspable abstractions of the work they should be doing. 

The only way to handle these people - who sometimes have a real bad effect on the morale of whole teams - seems to be a very detailed breakdown of their shortcoming. But that on the other hand leaves me in the position of a nitpicker [erbsenzähler] who wastes everybodys time - including my own - by going through seemingly unimportant details.

Of course - applying the rule of three - that can't be the only solution - but although I've been trying for years I haven't  been able to find any other angles. At leas not up until now - still trying!

Notes to self 006 - Be aware of the focus of the reciepient

In an oversimplified view there are generalists (often sporting an NT of NF in MBTI speak) and there are "detailists" (often sporting an SP or SJ in MBTI speak).
You (I'm talking to myself here) are a NF generalist. If you want to convince an detailist you need to use arguments with lots of actionable detail - not the abstract mumbo jumbo you're used to.

(Wish I had thought about that two weeks ago)

Notes to self - 005, Get it in writing - even if you have to put it there yourself

As I wrote a while back it is always a good idea to get important agreements in writing - Today I just had to remind myself that - especially in these days of electronic communication - there is always the option to put it writing yourself.
As a last resort - e.g. if an official protocol would be taken as an offense - I take the tangential approach as in "When we agreed on we also mentioned - would it be OK for you to treat these separately?" thus getting a written - and circulated - record of without offending my negotiation partner.
I most cases though it should be quite OK just to communicate openly and agree on putting the agreements in writing just to make sure that there are no misunderstandings.

Notes to self - 004, Keep local backups - The Cloud might dissolve

Keep local backups - The Cloud (aka the web) might dissolve locally

Just now a wiki that was on my list of important resources (the former wiki of the AYE conference) vanished with no clue about it's future.

It not only sadden's me because Cool URIs don't change but also because there was a lot of content even at the simple members pages, that I didn't bother to make a copy of.

The saddest thing is that it would have been easy for me to make a local copy of the wiki - after all, that is what tools like SiteSucker are for, right?

I just have to use them more often...
Therefore this very serious note to self: Keep local backups!

====8<------ End of Note to self

Comment to self:
Now the last resort for this case is the Way Back Machine, but that of course doesn't always have snapshots that include all I want to retrieve.

Notes to self - 003, Write each email as if it will reach your worst enemy

=====8<---------- Start of note-to-self 003, Write each email as if it will reach your worst enemy ----

Write each email as if it will reach your worst enemy because the chances are - it will!

Email might look like instant messaging or conventional mail - depending upon your background - but it isn't.

While it's not very common for IMs to get copied and pasted (although it happens) and conventional mails are only forwarded for a fee it is common practice to just press "forward" on an email. Considering that you might want to re-consider the idea to vent in an e-mail like "Hey Adam, I can't get Bob to do [whatever] - he's just to stupid and ignorant. Please do something about it".
Chances are that Adam just presses forward, adds "Bob, please do [whatever]!" and sends it directly to Bob.

If Bob wasn't your worst enemy before he probably won't be after - but I think the chances are high that your relationship with Bob won't exactly get better after this exchange.

As usual YMMV. I just had to remind myself about that yesterday. Again. (But at least I caught myself in time.)

=====8<---------- Start of note-to-self 003, Write each email as if it will reach your worst enemy ----

Notes to self - 002, Keep Records! Measurement & Calculation beats guesswork

=====8<---------- Start of note-to-self 002, Keep Records! Measurement & calculation beats guesswork ----
Sometimes I have to reminded myself to "eat my own dogfood" (or "take my own prescriptions")

Why should I not apply the same principles to facilitation that I recommend for software development?
Yesterday's Weather is perfectly applicable to meeting facilitation - if you know your tasks.
It's rather a high probability that the same task with the same amount of people in a retrospective (e.g. gathering data via a FrIm Chart) will take more or less the same amount of time.
So - to develop a plausible agenda - it's helpful to record the time each task took and the relevant circumstances (Time of day, number of participants etc.)
Therefore: Keep Records!
In the case of retrospectives you get a very sound foundation base your planning on data instead of guesswork very quickly. I'd say 3 Iterations should gauge your instruments [for that team] pretty precisely.

=====8<---------- Start of note-to-self 002, Keep Records! Measurement & Calculation beats guesswork ----

Notes to self - 001, Always put up a visible agenda

Each working day I learn something new - or relearn something old.

=====8<---------- Start of note-to-self 001, Always put up a visible agenda ----

Today I recalled a lesson from AYE - When facilitating a meeting with different personality types it helps everybody to set up a visible agenda and adhere to it - as log as it leaves enough room for deviation.

Some people need a clear picture of where the discussion is going while others are comfortable by "going with the flow". While it doesn't do harm for the latter if you put up an agenda - as long as the topics are liberal enough - it enables those who are in favor of the clear picture to focus on the topic at hand without worrying to much about what might come next.

The fact that the agenda might be helpful for the facilitator as well might be noteworthy as well - for example as a tool to direct the focus or as a tool to postpone the discussion to a later topic. Mixes well with a 'parking lot' to keep track of topics/issues to cover. But of course YMMV

[And of course "Always" should always be used with caution - in this case it is
meant to be read as "Whenever it is applicable, use common sense"]

=====8<---------- End of note-to-self 001, Always put up a visible agenda ----

What are these notes-to-self?

As Alan Weiß' calculation "if one improves 1 percent a day, one will be twice as 'good' in 70 days" shows the possibilities for self improvement are enourmous. (according to Kn = K0 * (1 + (p/100))^n => 1 * ( 1 + (1/100))^70 => 1.01 ^ 70 => 2.0067633... it is even a little bit more...)

But in my experience that math doesn't compute - or at least not for me.
Although I do work on getting better every day there also is a constant loss going on with me. I forget things, I don't apply learnings to new situations, I fail in the application some piece of knowledge that I posses and so on.

When (and if) I realize these events I have a chance to get my 1 percent for that day. (Nah - not really - make it 0.1%)

Up until now I tried to make a "mental note" of these learnings - both old and new. But after only one year it's hard for me to go over 365 purely mental notes, so I thought I should explicitly put them somewhere.

Starting today I'll try to pick the most important one of these aha-effects for each working day (no correlation to business days - I work freelancing) and put it down here. Each note-to-self will consist of the note itself plus a short explanation of it's meaning and context, as can be seen above in the first one.

Topics might be from a very wide range - don't expect notes on CxO level if I spent the day knee deep in code. I guess I'll cover:

• very low level (like: Note to self: ci in vim is important or Note to self: make sure you're laptop is in powersave if you give a presentation in an hour)


• development related (like: rvm helps with the descendants of the dll hell)


• coaching related (Note to self: What looks like resistance is often lack of safety)


• Facilitation related (see above)

Or something that I haven't yet thought of.

Estimate - 'an' or 'to'?

A couple of days ago I got into quite an interesting discussion [cited below] with David J. Anderson (http://www.agilemanagement.net) on Twitter about the need (or not) of estimates in Kanban. 
From what I learned 'estimate' has quite a different notion in my book than in his. Considering the fact that with me 'in my book' is only a manner of speaking while David actually 'wrote the book' (on Kanban in software development that is) I thought it would be a good idea to question our differences a little more thoroughly.
The initial difference is the statement, that in Kanban there are no estimates (missing source, perhaps misquoted) while on the other hand (as Olaf Lewitz noted [see below]) in the definition of service classes (on pg. 131 to be exact) David states "No estimation is performed..." but "Standard class items may be analyzed for size. Large items may be broken down into smaller items.".

Two things are notable here for me - the first one is, that I filtered out the second half of the first sentence. What he really says is "No estimation is performed to determine a level of effort or flow time." 
The second one is my reaction to the idea of "No estimation but analysis".
For me it is very important to tell people, that you don't have to know the exact size/effort/duration of a task but that it's OK to estimate. So the point for me is 'to estimate' is important to get over the negotiation phase and to avoid getting stuck in analysis paralysis. From what I read from one of Davids tweets I gather that for him it's important that the analysis of a class item should not contain any assumptions about how long it will take and when the item could/should be delivered. (On the other hand I could off course also have a complete misunderstanding of his intentions...)
So now it seems:
'to estimate' => good from my point of view because it frees from BDUF risk
'an estimate' => not so good from Davids point of view because it implies known effort and delivery date

But on a related note David wrote:
"so in general i believe in analysis to break things down to identifiable size/complexity but not in estimation"

As much as I can relate to that point of view I still have a great problem with the wording because ever so often when some (not all) developers hear/read that they don't have to estimate any longer if method/process is applied they interpret that as 'now I can just code and don't have to make any commitments beforehand'.

So, even when applying Kanban I would still like my teams to have the freedom to give estimates on item sizes - especially on big ones. And even on small item I would alway want a way to include a "give or take" to any number that's being passed around. And for me this leeway is what differentiates an analysis based on exact calculations from a plan that is based on estimations.

So David, should you read this (as I hope you will) - is our difference just a question of wording (English is still a foreign language to me) or is there really a fundamental difference in our position?
 

Just for the record: the original Twitter threads:
Thread 1:
 (ended at msg. id:16427657813)

agilemanager says:
@MMahlberg "'too large' is an estimate" only in the most degenerate of senses. It is not something you can plan or commit from

MMahlberg says:
@agilemanager analysis!=estimation: ok, estimation!=decomposition: ok, but decomposition involves estimation (e.g. 'too large' is estimate)

agilemanager says:
@MMahlberg for me estimation involves a time and a delivery date. it's not decomposition. analysis is not estimation

MMahlberg says:
@agilemanager @OlafLewitz I'm puzzled: p131…items may be analzd 4 size/lrg items may be broken down. Like estimation fwik. Pointers 2 diff?

agilemanager says:
@OlafLewitz no! I do not consider analysis or work type identification as estimation but can see how you could argue that is is

OlafLewitz says:
#Kanban detail question (@agilemanager), p.131, Standard class policies: No estimation, but analyse by size. Isn't that the same thing?


Thread 2:
(ended at msg. id: 16426940354)

agilemanager says:
@MMahlberg so in general i believe in analysis to break things down to identifiable size/complexity but not in estimation. is this clearer?

MMahlberg says:
@agilemanager agreed: UML != estimation (notation/language vs. activity)

agilemanager says:
@MMahlberg for example you would never describe UML as an estimation technique

MMahlberg says:
@agilemanager @OlafLewitz I'm puzzled: p131…items may be analzd 4 size/lrg items may be broken down. Like estimation fwik. Pointers 2 diff?

agilemanager says:
@OlafLewitz no! I do not consider analysis or work type identification as estimation but can see how you could argue that is is

OlafLewitz says:
#Kanban detail question (@agilemanager), p.131, Standard class policies: No estimation, but analyse by size. Isn't that the same thing?

Is emergent design possible? (I think it is!)

Just the other day I had a discussion with a really experienced lead developer about the feasibility of the no-big-design-up-front-approach and the necessary circumstances to make emergent design work.

Along comes these series of articles from Abby Fichtner that I stumbled upon last night.

And although there's more to emergent design than Bob Martins SOLID principles I think these articles make an excellent starting point for a deeper discussion of the subject.

• SOLID Code with Emergent Design - Part 1
• SOLID Code with Emergent Design - Gimme an S
• SOLID Code with Emergent Design - O, I get it
• SOLID Code with Emergent Design - The L
• SOLID Code with Emergent Design - The Other ISP
• SOLID Code with Emergent Design - The Final Chapter

Cheerio

MM

Something completely different - Software I'd really love to buy...

...if it only existed...

(Mac mandatory of course)

• A word processor that really separates style and content - and still has a wysiwyg interface.
• A content managements system that does the same - minus the wysiwyg and plus a clear separation between content management (code) and delivery (from a pure static server, as they are available as commodity nowadays)
• Access done right -
  
  1. For the Mac
  2. For different backends (mySQL, posgreSQL, SQLite, ...)
  3. Less Wizards - more ER-Modelling
  4. Keep the grid view, the forms and (especially) the reports
• A stand-alone, sql-based, cross report generator with pdf (and perhaps rtf) as target format
• A format translator for Text-Files for all the different formats people want out there. Just feed in the Markdown, MultiMarkdown or Asciidoc Styles on one side, match them up with the respective publishers Word, LaTex or openOffice styles and ... presto - your final draft comes out

... wanted to do all of these myself ... never found the time (of course) ... so, if anybody out there is just looking for a cool idea for her next project - feel free to implement any or all of the above...

Cheerio

Michael

Oh, and BTW: I'd volunteer as beta tester...

How many Backlogs do you need?

Hmm... there used to be two backlogs in scrum IIRC:
the product backlog, owned by the Product Owner and the sprint backlog owned by the team.

Nowadays, scanning through contemporary tweets and blog entries, there are at least (in various amounts)

• Product Backlog
• Sprint Backlog
• Impediment Backlog
• Technical Debt Backlog

So I wondered: Do we really need them?
Right now my answer would be "Yes" and actually I think most of us use them already - albeit more or less secluded.

Of course the Product Backlog and the Sprint Backlog are completely visible all the time.

The Impediment Backlog and the Technical Debt Backlog OTOH are not quite as popular - mostly because we "should not have them" in the first place. If all "impediments are resolved within 24 hours" and "technical debt is paid back before a task is completed (aka Done)" and we "leave everything cleaner than we found it" both "Backlogs" are more like personal lists with a lifespan of less than a day.

Unfortunately reality is slightly different in lots of places and so we should recognize this fact and install corresponding backlogs with a fitting set of attributes.

So, what could these attributes be?

For the Impediment Backlog I'll try:

The usual stuff:

• ID (Yes, I need an ID - but YMMV )
• Synopsis (An understandable but very short description of the impediment that can be scribbled during the standup meeting )
• Description (A longer description, that explains the impediment to the non-initiated)
• Date created (well...)

The specific stuff for the impediment backlog:
(All of these should be considered optional and used as growing lists - just to make sure the impediment gets the attention it deserves)

• Number of Mentions (A counter - implemented e.g. as a tally chart on index cards - to determine if the impediment is really such an impediment as it first seemed)
• People affected
• Tasks affected
• Stories affected
• area(s) affected (e.g. Specs, Tests, Coding, Deployment, Design etc.)

For the Technical Debt Backlog I'll go with…

The usual stuff (what did you expect?):

• ID (Yes, I still need an ID - but YMMV still )
• Synopsis (An understandable but very short description of the dept imposed than can be scribbled during coding or the standup meeting without much of an interruption)
• Description (A longer description, that explains the debt and its effects to the non-initiated, probably written later)
• Date created (well...)

The specific stuff for the technical debt backlog:

• Area affected (e.g. Architecture, Design, Delivery, Deployment, Stability etc.)

Hmm.. that's not so much - I wonder if the list will grow over time.
I'd expect some of the TDB (technical debt backlog) to turn into tasks eventually, but they might also vanish simply because of DoD (definition of done), "no broken windows", "leave everything cleaner than we found it" and other related practices.
I wonder if it would be possible to derive the interest rate of technical debt... but that's quite another story.

Continuous integration in the German blog

Did I mention my new article on continuous integration in the german blog?

You can find it at shu-ha-ri (never mind the typo in the url - I somehow lost a n and an u when entering the title and since cool uris don't change - according to w3c - I decided to keep it like that for now)

Cheers
Michael

Get it in writing

I repeat this lecture ever so often.
Whenever possible "Get It in Writing" - not only to have proof of agreements but even more to make sure that both parties have the same understanding of them.
And sometimes it also provedes the means to make sure that you and the person you're talking with have the same understanding of implicit assumptions.
The most compelling story to back this was told to by a tour guide in New York when we drove along 42nd street.

When William Van Alen was hired to construct New York's Chrysler Building he was so sure of himself - the tour guide told us - and so well versed in the trades of the craft that he didn't bother to get a written contract. After all 5% of the buildings overall building cost was a well established fee in the market
After the building was completed - beating the Bank of Manhattan in the race for tallest building of the world - Chrysler refused to pay Van Alen with words like: "We don't have a contract. You should take more care to always get it in writing". Of course I don't know if this is a true story or not, but at least it serves well to remind me of my own advice.

OTOH it's hard to capture everything beforehand and some thing are so engrained into our perception of the world that I also tend to put more trust in the co-operation than I should.

Cheers
_MM_
(BTW: The story itself is of course backed - at least somehow, although with slightly different numbers - by wikipedia in the last paragraph about William Van Alen's Life)