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)

scm & build: Levels of configuration

Here's the first little part of the (to be - or not -) series on configuration management and build management.

Although I wanted to start with some clarification on "Task level commits" I actually concentrated on different levels of configuration in a build environment. Here we go...

The levels of configuration

One of the biggest differentiators between a one-man-show and a team-effort-project are the different levels of configuration that have to be managed – and this is also a point where the quality of the whole build process can be heavily influenced.

Basically – unless the application-to-be is monolithic – there are four levels of abstraction: Machine dependent, user dependent, purpose dependent and (last but not least) project specific configurations. Each of this has to be managed separately and consciously to avoid (to much) manual intervention. Talking about indirection let me cite (once again) David Wheeler to whom the phrase “Any problem in computer science can be solved with another layer of indirection. ” is attributed. As he stated in the second part – which is often omitted – “[But] this usually leads to another problem” so let's have a look at the relative pros and cons of this fine distinction. To start of lets examine each level a bit closer.

Remarks:

By the way: Of course there are at least two Dimensions involved in this topic as well: run-time configuration and build time configuration. For the sake of this argument I'll postpone this discussion towards the [[build]] topic.

Purpose dependent configuration

Let's start with the purpose dependent configuration since this is a concern covered in most modern environments. The purpose I'm talking about is also known as build type or target environment or something similar to that. Typical purposes are “Test”, “Debug”, “Release” or – a bit less frequent – “Integration”. Depending on the purpose of the build there usually are a number of things that differ. For “Test” there might be some hard-wired shortcut to circumvent server-roundtrips or a “don't really send to printer”-entry or some other special behaviour that is meant to make testing easier (or even possible) without imposing side-effects on already installed systems. If you're building for “Debug” – one of the most commonly differentiated purposes – you'll certainly want to include debug information into your code, something you probably don't want to ship (although that could be disputed, but that is another story). “Release” of course is the purpose with which you build the shippable product once all test and QA-work has been done. The necessity of an “Integration” purpose arises only in projects where you need to integrate several sub-products and usually has rather project-specific configuration needs.

And of course there are some things (e.g. logging) that need to be configured differently for each of these levels. But speaking of logging we encounter another type of configuration that should not be mixed with the purpose specific configuration: the project specific configuration of components. While I'll go deeper into those in the next paragraph, the important part with respect to things like logging is to be aware of the fact that some thing have both – a project specific configuration and a purpose specific one. Trying to manage both in the same way can create real nightmares (I guess, everybody who has tried to keep Log4J configuration files useful for an extended period of time without that conceptual distinction knows what I'm talking about)

Project specific configuration

This usually is the first configuration option you come across. Almost any project nowadays uses some reusable libraries. Those of course have to be adapted to the specific needs of the project and thus the first level of configuration indirection comes into existence.

Although these configurations are applicable on many levels – from configuration information specifying a windows' layout to the much mentioned log-file configurations – at least they have a clear association. They are “just another kind of source code” and thus relatively easy to handle.

Machine dependent configuration

This one strikes as soon as there is even one more developer! The path which used to point at /usr/bin has to point to /usr/local/bin, the drive for intermediates that used to be C: has to be E: and the monitor resolution goes from 1024x768 to 1600x1050. Consequently some things have to be configured somehow – and here we definitely need a distinction between build-time and run-time.

User dependent configuration

The distinction between user dependent configuration and machine dependent configuration is a bit hard to make in a time where the correlation of people:machine moved from n:1 to 1:n. But even now – where lot's of people have more than one computer the real relationship is more like n:m since some computers are still shared. Especially build and integration machines are prone to sharing. Now, even on the same machine, the configuration might differ in paths, desired screen resolutions and mounted network shares, so there is basically the same set of configuration information as there is in the machine dependent part, but it needs to be managed in a separate space.

To summarize: We have the purpose specific configuration which is a central [[build]] topic, the project dependent configuration that correlates to source code, the machine dependent configuration that correlates to hardware configuration management, and the user specific configuration that somehow correlates to profile information. All of these should have traceable connections to identify possible configuration errors.

After I have raised all these questions of course I should also answer them – I'll do so some time in the future and will provide a follow-up link in this post...

I think that even the concept to have different levels of configuration enables people to create more stable build environments.

Cheers
_MM_

Best Practices - like everybody does it?

In a recent Dilbert comic strip the much cited protagonist replies to his boss: "If everybody is doing it, Best Practices is the same thing as mediocre"

Made me think...


_MM_

Build-, Version-, Configuration- and Sourcecodemanagement,

Lately I found myself talking about buildmanagement and configuration management a lot. And since this blog lies deserted in the wild anyway I think this is the perfect place to ramble about that stuff so I can point other at some more ressources than I can right now. (And of course other can point me to my own ramblings if I get lost in the discussion)

Topics I’d like to discuss (although this probably wont ever come to an end) include simple, practical, down to earth things like

• The simplest way to set up svn to work with xcode for a small workgroup
  
• How to set up (any) DVCS for XCode
  
• How does SCM-integration work in XCode
  

but also things that seem to be intuitive to some but controversial to others

• Command line builds
  
• To branch or not to branch
  

and more conceptual topics (the most important to me) as

• Releases, Versions, Variants and other “Numbers”
  
• What is Multi-Dimensional SCM
  
• Staging and promoting 
  

Stay tuned for the first episode in about a week (and nudge me if I havent published it in two weeks!)

Cheers
_MM_

Strange ordering...

Strange - a few days ago I finally edited and released an entry from about a year ago - it still shows up in the old position. 

So - just to make it evident that I'm writing a little more again - I wrote this entry. The post in question was about the simple but disputable question "Are technical topics no business topics?"

Agile discussed by Jerry Weinberg

In an interview with PMBoulevard Gerald M. Weinberg states his opinion on agile Methods.

From that interview:

Q4: What is the future of Agile?
First we will drop the capital A. Then we will drop the term "agile" altogether. Agile methods will be successful if and when we stop seeing them as anything other than normal, sensible, professional methods of developing software.

That even someone as renowned in the field of "conventional" software development as Jerry Weinberg points to the common sense embodied in these methods makes me hope that someday the waterfall-style methods might vanish alltogether.
(via Jerry – of course)

Divas and Geniuses

In a blog entry from the start of the week Mark Masterson cited from the lessons learned document of a past project:

"Change the design / architecture to reduce reliance on the divas"

That reminds me of a former client of mine who used to say

"If you've got a genius in the team - get rid of him"

At first that's rather sad, but after a while - and with changing responsibilities - I came to realise that there can be situations (actually lots of them) where the advise is absolutely sensible.

It can be sensible because most developers are of average capabilities!
After all - that is exactly what average means.
Therefore the probability to have "above average" developers declines with the size of the project (and the organisation) simply because of the definition of average.
Even if all (or at least almost all) the developers in a certain team are "above average" (e.g. compared to some outside group of reference developers) most of them will - by definition - be of average skill within the team. That's where the "get rid of the genius" sets in.

If one of the persons on the team is way ahead of all the others - lets say she is a specialist in compiler construction - their advantage can become a disadvantage for the team as a whole. For those "geniuses" TSTTMPW (The Simplest Thing That Might Possibly Work) probably is quite different from the things the rest of the team perceives as "simple".

Configuration files are a good example - while plain text with very little syntax is the "simple" thing for most of us a specialist in compiler construction wouldn't mind using a sytax that is "syntactically a little richer" to gain simpler implementation. He might end up with a configuration language like sudoers' - where guides to the grammar (defined in EBNF) and the grammar's grammar are provided in the manual pages just to give the average user a chance to understand sodoers.


Actually I worked on a compiler project myself way back in the 80ies and used to be kind of fluent in BNF, but figuring out sudoers still took me a while. And judging by the amount of

<username> ALL=(ALL) ALL

(basically: allow <username> to do everything he wants as root)

that I've seen on other peoples Macs not many of them go to great depth deciphering the format...

Back to projects: Of course the idea to get rid of every smart person in the team would not be the best option - unless you want the project to fail.

But the "geniuses" - or, to be fair: those who have advanced knowledge and/or experience compared to the rest of the team - have to be handled carefully. Only for very isolated tasks they should be left to work it out all alone.

For the rest of their work they ought to work closely together with other team members as long as their personality allows them to adopt their ideas to a level thats appropriate for the whole team. Should the latter not be an option then option one is valid again of course - the team should get rid of 'em.

But in my experience that is seldom necessary Most geniuses are quite willing to agree on a sensible level of "simple" as long as their is a sensible discussion.

So after all it no so sad anymore. The bottom line of my job is not to get the "best" possible solution but to make the team as a whole as effective as possible

_MM_

Contracting Principles by Gerald Weinberg

I may not agree with everything he said, but the principles lined out by Jerry in his post on how to prevent consulting misery are a good starting point for everybody who is trying to figure out how to shape their relationships with their clients in a healthy way.

New Blog in Town

Since not all the things I want to talk about are really that relevant to an international audienc I just started another blog for the local topics.

...ups wrong link at first - sorry ...

From Cavedrawings to Hyroglyphs to Times New Roman - and back to Cavedrawings.

Sometimes I don't understand our business...
Just recently I listened to an interview with Grady Booch where he (once again) emphasized that he never intended the UML to be used for programming (i.e. as a programming language).
I‘m a proponent of visual modeling myself and after experiencing the method wars of the nineties I'm glad that such a thing as the UML unifies the meaning of arrowheads, boxes and dashed lines.
But I just can't understand why people think that they will be able to describe complete software systems of all kinds in pictures (although it's quite possible for some domains and to a certain level).
When thinking of the written word and picture I just can't avoid to think about cave drawings and "real" writing.
It‘s very common to judge the development of a civilization by it‘s capabilities to write. Or as Wikipedia puts it:

„Historians draw a distinction between prehistory and history, with history defined by the advent of writing. The cave paintings and petroglyphs of prehistoric peoples can be considered precursors of writing, but are not considered writing because they did not represent language directly.“

So where does it put our so called "industry" when some of us attemp to describe complex systems in pictures alone?