Wednesday, October 08, 2003

Respect for Artifacts

I think that Paul Glen, author of Leading Geeks may be on to something with his ideas about archaeology for software engineering artifacts.

I have recently been helping out elevate a constraint by actively joining a domain modeling, Feature analysis and architecture activity on two projects. As a result I’ve been playing with Post-It notes on white boards and getting back to full fitness as an object modeler. Several people have commented on the neatness of my models, on the aesthetic quality that they have. Our office manager commented that the latest one looked “pretty” and another developer is privately known to have called the earlier one “a work of art”. Note these comments are not aimed at the effectiveness of the object modeling, merely the aesthetic of how it is presented. Once, I’ve settled on a model. I will create an electronic version in Together and print it out in color. I then put the finished domain model on the wall for everyone to reference.

What would the archaeologist learn about me from this behavior - simply put - I value analysis and design. I see analysis and design as valuable deliverables. Just as we have coding standards to make code look neat and provide for clarity and readability long after code was written, so I believe that models should also be produced with care, follow a style and be clear enough to have value long after they were first created.

Bottom line, if your team isn’t producing neat work for activities such as analysis and design, but merely a few scribbles which may never be preserved then they probably don’t value this activity. This is likely an indicator that they aren’t making their best efforts at it. This could ultimately be wasteful. Is there a relationship between respect for activities other than coding and the ultimate quality of the delivered code?

Tuesday, October 07, 2003

Getting to ‘norming’

I learned one of my best lessons in management from Peter Coad - the team development cycle of ‘forming’, ‘storming’, ‘norming’ and ‘performing’. Peter had in turn learned it from Fred Racey and he documented it in The Coad Letter #40 - Lessons Learned from Fred. I later found a more formal presentation of these ideas in another of my favorite management books, Managers as Facilitators.

The key management concept to take away from this is that in order for there to be a normal working relationship in a team - no matter how large or small - there will inevitably be a period of pain and angst while the group goes through its ‘storming’ stage. There MUST be ‘storming’. It is unavoidable. The experienced manager learns to expect ‘storming’ and to accept it as a necessary part of growth. A good manager will coach a team through the storms and help them to reach the mutual respect and understanding that comes with ‘norming’. A bad manager will take fright from the storm and will seek to punish individuals for undesirable behavior. The result will be a fallback to ‘forming’ and a resultant lack of productivity.

Recently, I experienced a dynamic between two people, one of whom I knew well and respected as a professional. He had recently joined a team which though not fully established had been in place for a few months. He immediately butted heads with the current team lead who had gained some respect in the organization. For almost two weeks, the scene was ugly. Some others might have wondered if the new guy was a trouble-maker. A less experienced manager may have been tempted to intervene. Indeed the individuals may have wanted intervention - some higher authority to rule on who was right and who was wrong. But it was better to let it be.

Eventually, a design was agreed - painfully. A deadline was approaching and a hard weekend of overtime was required to create the code. This was the crucible - differences were put aside and everyone focused on the goal. By the end of the weekend, the code was complete on-schedule. A weekend of ‘performing’ had achieved the result. A new found mutual respect existed and a team that had been publicly ‘storming’ for weeks had finally reached ‘norming’.

The moral of this story is that managers should try at all costs not to interfere with team development and inter-team dynamics. Maintaining a hands-off approach will ultimately deliver the best productivity.

Sunday, October 05, 2003

Zeitgeist and the Barista as CCR

Here is another real world example of constraint theory in action.

In Seattle, we are famous for our coffee. Seattle is the home of Starbucks, Tully’s, Seattle’s Best Coffee and Torrefazione. It also has a healthy collection of independent cafes. My favorite one is called Zeitgeist at the corner of 2nd Avenue and Jackson St. Despite the fact that there is a Tully’s across the street, a Starbucks on the next corner and a Torrefazione just around the next corner, Zeitgeist is often so busy in the morning that the line extends out of the door into the street.

In Zeitgeist like so many cafes, the operational CCR is the espresso machine and the barista operating it. In fact it is often a 2 person operation - one stocks the machine with coffee and passes the order to the next who makes the drink. At Zeitgeist to maximize Throughput at busy times and to reduce the length of the waiting line, the till operator will make drinks which need not pass through the espresso machine (the system CCR). Hence, if you order tea or drip coffee, the till operator will turn away and get your drink before ringing up the till. She will not pass it to the barista who is busy on the espresso machine.

This makes sense because the rate orders can be rung up at the till is not the constraint. The rate the espresso drinks can be made is the constraint. By not ringing up orders until they can be filled, the system is subordinated to the espresso machine constraint and the line grows. The line is reduced by processing non-constraint orders using other resources. The effect is an overall increase in Throughput (dollars of revenue) without elevating the constraint. The constraint is merely exploited to the full by never passing a non-espresso order to the barista working the espresso machine.

Friday, October 03, 2003

Throughput and America’s Dentists

Sometimes it is easier to understand the concepts of the Theory of Constraints with a practical real world example.

I’ve lived in a few countries in the world and attended a dentist in each of them. Generally, the model is simple. A dentist works in an office with an ante-chamber waiting area. Patients are seen one at a time. The dentist starts and finishes a patient’s dental work before seeing the next. In this model the constraint is the dental office and its contents such as the dental chair. To maximize the Throughput in this system the dental office (and chair) must be kept occupied as much as possible. Everything else is subordinated to this decision. The patient scheduling is done to provide one and only one patient in the chair at any given time.

In America, dentists have learned to elevate the dental office as a constraint. By providing several offices (or chairs in a larger office) per dentist, the chair/office constraint is elevated. In this new model, the dentist him/herself is the capacity constrained resource (CCR). The dentist will hire additional assistants. With this model several patients can be seen at once. Each assistant will take a patient and seat them. The assistant will do as much work as she/he is licensed to perform - only involving the dentist for the actual dental treatment. For a typical 30 minute appointment, a patient may only see the dentist for 5 or 10 minutes.

The net effect is that the number of patients processed by a dentist is increased. As the revenue for the system is generated by dental treatment, i.e. the work of the dentist, then by maximizing the number of patients that the dentist can treat in any given day, the overall Throughput of the system is optimized.