Monday, January 17, 2005

Personal Defect Rate

What’s your personal defect rate?

Do you ever stop to think about how many opportunities there are for defect insertion in knowledge work and do you measure how accurate your performance intent against action actually is? Do you study, even subjectively how this fluctuates with tiredness, distraction and at different times of the day?

Recently, I was in a meeting in my office with my graphic designer. I offered her a drink which she accepted. I said, I’d go to the kitchen as I wanted a cup of tea and I’d fetch the soda for her too. While I was at it, I would also photocopy the design specs that I’d drafted and give her a copy. So I set off down the corridor. Soon I realized that I’d forgotten my insulated mug. Oh well, I thought, no tea for me - lowering my standards to maintain conformance with specification for the trip Next I walked straight past the copy room and into the gents toilet and was surprised to find that there wasn’t a photocopy machine in there. 180 degree turn and in to the copy room. I made a copy. Went to the kitchen. Collected the drink for my colleague and returned to my office - only to realize that I’d left the master of the design spec in the photocopy room.

In the space of two minutes I had inserted 3 defects into my day. It was only 3.30pm and it was only Wednesday. So no excuse for being tired from a long week at work. Now it might just be me! I might be so totally absent minded that I shouldn’t be trusted with my own house keys. However, I fear that I am not unique. How many day dreamers do we have in high technology?

And people wonder why pair programming is effective?

Friday, January 14, 2005

Where have you gone Martin Fowler?...

...An industry turns its lonely eyes to you (woo woo woo)

It took a pack of lawyers for Simon and Garfunkel to persuade Joe Dimaggio that they weren’t criticizing him or suggesting that he’d disappeared from public sight or that the shine had come off the public image of a man who married Marilyn Monroe. In fact, as the lawyers explained, Joe had to get used to the idea that he was being used as a metaphor.

Recently, Martin Fowler has been offering us advice about how dangerous metaphors can be. They are confusing. The problem is two fold. Firstly, they don’t stretch well (as Alan Cooper famously explained) and secondly not everyone can see the abstraction and subsequent concrete example in another field. Joe Dimaggio was a metaphor for the all-American hero. Here Martin offers us a warning about Lean as the all-Agile productivity hero.

Where I want to differ with Martin’s view is in his characterization of Lean as a metaphor. Lean Thinking offers us a set of principles. Principles are abstract concepts rather than concrete ones. The all-American hero is an abstract concept. Joe Dimaggio on the other hand was a decidedly real example of a baseball player. As I explained before, the English language offers us 3 words for mapping concepts like this, which from strongest to weakest are: abstraction; analogy; and metaphor. Lean is an abstraction rather than a metaphor. Martin Fowler made his name teaching us about abstraction in his seminal work - Analysis Patterns .

At the heart of Martin’s complaint with the Poppendiecks promotion of Lean is the suggestion that “inventory” in software development manifests itself as documentation. As zero (or very low) inventory is a goal in manufacturing then zero documentation should be a goal in software development. Hmmm. Sounds metaphorical to me. So, let’s examine this. First off, inventory is an abstract concept which has a specific example in Lean Manufacturing confusingly often called inventory or goods-on-hand. Inventory comes in three forms: raw material, work-in-progress; and finished goods. All three of these terms can apply to the abstract or concrete. So, it’s tricky! The Poppendiecks thinking in metaphors (rather than abstractions) said, “Gee! Inventory in a factory is a pile of stuff. What looks like a pile of stuff in software development? Hmmm. How about a stack of documents?” It didn’t take long for a few of us to correct this notion and I notice that recently in the Lean Development Yahoo! group no one has been suggesting that “inventory is documentation”. So Martin is behind the times though doubtless countless others who’ve read some of the Poppendieck articles or book will have learned the same notion - that “inventort” is documentation. Both Clarke and Jason explain why the Lean abstraction does work and how to truly represent inventory in a software development process. All of this begs the question from the title…

Where have you gone Martin Fowler (international man of abstraction)? an industry still turns its lonely eyes to you…

Thursday, January 13, 2005

Layering Concerns

Martin Fowler blogs about a recent workshop where people were asked to rank principles for layered architectures. Interestingly, the concept of organizing teams around layers in the architecture emerges as an anti-pattern. I’ve heard this before often from people who should know better. I’ve also watched a colleague (back in 1999) - Peter Durcansky (some of you will know him as the developer of Playground, the Coad-Yourdon Notation modeling tool) - who had to rescue a project which went wrong mostly for this very reason - teams were organized to code in vertical slices. The code was poorly coupled and lacked cohesion.

Many agile developers believe that vertical slices are best. In fact the standard advice of “pick a pair, pick a story, TDD-it, and deliver it working” suggests vertical development across layers in the architecture. So why, when I generally believe in agile approaches, do I believe this is an anti-pattern?

Firstly, I do admit it works on smaller projects and for small tasks such as change requests. At 4thpass/Motorola in Seattle we did assign individuals or teams to do vertically partitioned development for change requests and minor upgrades. However, I do believe it is an anti-pattern on larger projects with more than one team (i.e. more than 6 people) on a project intended to run for quarters or years where the software will grow into a large code-base. Why? There are two reasons.

The first is rooted in a pattern identified as good in the ranking, “low coupling between layers, high cohesion within layers.” Equally, it’s good organizational skill to create teams which are highly cohesive and loosely coupled. Hence, if the teams doing the work are highly cohesive and loosely coupled, and the layers are highly cohesive and loosely coupled, shouldn’t these be aligned? If the team spans the layers then it encourages poor cross layer cohesion (between code from different teams) and poor coupling between layers (as teams won’t feel compelled to enforce loose coupling within their own code). [XP with its refactoring and shared code ownership allows an anyone goes anywhere policy and this in theory fixes the problem. However, with large code bases, teams tend not to wander all over the code base, refactoring other teams’ code. So the problem remains.] Code cohesion will suffer when the organization and the architecture do not align. This is yet further evidence that to be an effective manager of software development, you must understand how code is built.

The second reason relates to scheduling and the uncertainty or variation implied by another principle agreed as good in Fowler’s survey, namely “separation of concerns”. The reason this makes sense is that it allows things to vary independently and the degree of variation, change and uncertainty will be different for each class or component. We “separate concerns” because we know they vary independently. There is another advantage to understanding and separating out variation. It lies in Critical Chain theory. The size of a buffer can be smaller when the uncertainty is smaller. Hence, in a project schedule for a network of components being developed in parallel by more than one team, the schedule can be shorter if the uncertainty is isolated effectively. Reinertsen explained, in Managing the Design Factory, that coupled tasks assume the uncertainty of the greatest element. Hence, cross-layer tasking maximizes the effect of uncertainty. Separating teams across layers, having them work only on code in that layer, facilitates minimal uncertainty. You achieve minimal uncertainty with a schedule that has tasks for each layer in the system, as shown here.

It is certainly true that an immature team cannot run with a Critical Chain schedule. The concept of tightly synchronous iterations such as Scrum Sprints works much better. However, once you’ve controlled chaos, the next step is to look for continuous improvement. One way to achieve better throughput is to switch to asynchronous scheduling and reduce buffering by separating out differing degrees of variation in the architecture and the task network for the schedule. Hence, small teams doing vertical slices is probably the right answer for chaotic teams on smaller projects. Longer term, the most productive answer is to separate out teams across layers.

Wednesday, January 12, 2005

Chiglets

Line managers complain to me that they are never sure whether or not they are chickens or pigs. Should they even be in the morning standup meeting? I’ve vacillated on this before too. My opinion is that when everything is running well then the line manager is pretty much superfluous unless they also play another role such as architect or domain expert. However, under chaotic conditions, the line manager is a useful member of the scrum. So, is a line manager a chicken or a pig?

Line managers are seldom the scrum master. Scrum masters usually report to line managers, in my experience. So in theory the line manager is a chicken - merely involved, someone who receives notification, output and occasionally is consulted for input. However, when a special cause event happens and an escalation is needed in order to remove a blockage and get the backlog moving again, then suddenly the line manager is a pig - committed, doing the work, both accountable and responsible.

Hence, line managers live in a world of oscillation between two states. Never quite stable as a chicken or a pig. They are chiglets! If we’re not happy with the idea that a chiglet isn’t permanently committed but sometimes merely involved then I suggest we designate the role and responsibility relationship of the chiglet as “facilitates”.

Hence, a agile ARCI model would have three designations

• F - facilitates
• C - committed
• I - involved

Tuesday, January 11, 2005

Chickens and Pigs

Ken Schwaber introduced the concept of chickens and pigs with the daily scrum. Each attendee is either a chicken or a pig. The metaphor comes from the idea of a project to make breakfast of bacon and eggs. In such a project, the pig is said to be committed but the chicken is merely involved.

Committed and involved could be mapped to the ARCI designations for roles and responsibilities. This might help to map an agile process into a more formal or traditional organization.

• Committed (pig) is the equivalent of A(ccountable) and R(esponsible)
• Involved (chicken) is the equivalent of C(onsults) and I(nformed)

This CI or pig and chicken designation removes the problem of command and control by merging the doing, with the giving of orders. Committed designation allows for empowerment and its alter-ego self-organization. Committed allows for shared responsibility (in the common sense) and shared ownership. Everyone on the team, doing the work is committed and they are all jointly accountable.