31 March 04 - 00:33Pragmatic optimists

I don't know which pleases me more, that Frank is reading my mind or that Heath Row is reading my blog. (Vanity - is that a form of optimism ?)

I'm not a regular Fast Company reader, but I know Heath Row by reputation, through being a member of the global network he somehow kickstarted, Company of Friends. Heath's relentless curiosity for new ways of doing business strikes a chord with my interest in reforming some management practices. I hope I have the opportunity to have lunch with Heath one of these days - I'll be expecting fascinating conversations.

Frank hits the nail square on when he ties the discussion of managing optimism with the magic word "promises". You might say I caught the "promises" virus from Frank and of course Hal Macomber, and the notion is very much on my mind as I discuss optimism, risk, uncertainty and projects.

Words of wisdom from Esther, another pragmatic optimist: "What could possibly go wrong ?"

- Blogversations - one comment / No trackbacks - § ¶

31 March 04 - 00:02Self-Organizing Teams

The Agile Manifesto states: "The best architectures, requirements, and designs emerge from self-organizing teams." Yet the topic of self-organizing teams seems to barely deserve a mention at conferences or in articles (compare the number of references in the Agile Alliance's article index - the Project Management section vastly outweighs the Self-Organization section, and of the few articles in the latter not all seem to truly belong there.)

Is this because self-organizing teams are a no-brainer, such an easy strategy to set up that nothing much needs to be said about it ? I very much doubt it. The fact is, it seems completely paradoxical to propose something like self-organizing teams in the context of a discussion on development "processes". Mention "process", and the immediate associations are with management choosing, defining, and imposing a process; no team who is being told to follow a process can rightly be called self-organizing.

Still, the Manifesto's statement has always rung true to me. Teams who can achieve a purpose without the need for a leader's direction must be more effective than teams who require constant or even regular intervention on the part of a manager. The capabilities of an "externally organized" team will be constrained by the leadership skills and the availability of its manager; not so a self-organized team.

Together with Emmanuel Gaillot, I will be hosting a workshop at the XP2004 conference on the topic of self-organizing teams. My primary objective is to learn something about the subject; I expect and hope that every participant there will also find something to learn.

This is a call for participation, of sorts; if you're planning on coming to XP2004, you're welcome to register interest at the Wiki I've set up for that purpose.

- Management - two comments / No trackbacks - § ¶

29 March 04 - 07:45Optimism management

My postings on risk management have attracted some attention and feedback recently, yet I'm wondering if risk is entirely the appropriate focus of our "management".

If by "manage" we mean something like "control the amount or supply of something", then risk is for the most part not something we can manage. What we can control is our attitude to risk - and in that respect, the most serious problem in our industry is optimism, the belief that we can make plans and expect things to reliably unfold according to these plans.

Optimism has its place in project management activities. It is a key component of entrepreneurship, and entrepreneurship is at the heart of the sort of management which projects require. Thus, I often argue that optimism is the occupational disease of managers in project contexts, from startups' CEOs to project managers in larger enterprises.

At the same time, optimism may well be a leading contributor of project failure, as a factor of blindness to project risks. "We're not really late yet, we'll catch up". "It's just a trivial change, it shouldn't take five minutes". "I don't see why our customers wouldn't like that". We can all reel off dozens of these phrases which are usually the harbingers of project disasters.

I suspect it's optimism, not risk, that most needs to be managed.

- Management - one comment / No trackbacks - § ¶

18 March 04 - 15:33What you check at the door

I've been following Colin Morley's blog, Empowerment Illustrated, for a while now. I have little love for mucking around with the tools of blogging - it's the writing practice that keeps me at it - but Colin's blog was the impetus for putting aside this distaste and equipping this page with a blogroll, so he could be on it. (There are others just as deserving, who'll be appearing on the list as time goes by.) This entry of Colin's made my day earlier this week. I want you to go read it now, and while you're at it check out the rest of Colin's blog, before you come back here.

Many people are uneasy with the word "soul" enters into a conversation. I'm one of these people. Don't be distracted by the word, and consider instead the question of whether you come into work as a whole person, or whether you check at the door any part of who you are: your feelings, your ethics, your passions, your vulnerabilities, your ambitions.

If you do, you are not as powerful a person as you might be - at least in your workplace.

This is a key lesson from practice and from my readings over the previous three or four years, from Jerry Weinberg to Peter Block through Tom DeMarco, Barry Oshry or even Michael Bosworth or Jacques Werth. Bring the person you are, entire, to the work you do.

- Blogversations - four comments / No trackbacks - § ¶

18 March 04 - 14:49Mutiny

We now speak the language of self-management, but it is still difficult for a group of subordinates to call a meeting that excludes their boss. We bear the imprint of the fact that in times past self-management was called mutiny.
-- Peter Block, Flawless Consulting

- Management - one comment / No trackbacks - § ¶

09 March 04 - 15:54The absent customer

I've recently been talking about customer unresponsiveness with a client of mine, and a perfect example of our persisting wrongheaded attitudes in this respect just crossed my inbox, courtesty of the online mag StickyMinds.

Peter Clark discusses "bread crumbs" - leaving a trail of written traces to document important decisions affecting a project. One of the cases Clark examines is a customer or key stakeholder failing to approve requirements by an agreed date:

The second strategy involves sending a letter to the customer stating that he has missed the previously approved date, and giving him a drop-dead date to approve the specification. Inform him that after that date, you will consider the specification approved by default. Any changes after this date will require a change to the contract, resulting in increased cost and/or schedule delays.

The phrase "approved by default" is making me angry even as I read it for the tenth or twentieh time. Approval - the declaration of customer satisfaction - is an active process, not something you can pretend has happened "by default". If we want to be honest, we'll inform the customer that absent a response by the "drop-dead" date (nice thing to wish on your customers, by the way) we will assume they have withdrawn from the contract.

Clark correctly stresses that the worst possible strategy is to say nothing and forge on with the project. But it's all too likely that in such a situation, we have already failed to monitor and manage customer involvement in previous phases of the project. For instance, did the customer make a reliable promise to sign off on the requirements by the agreed upon date ? Or did we suggest a date, for instance by sending a milestone list, but fail to explicitly reach an agreement on what the customer was to do by then ?

The "approved by default" tactic is just setting up the customer to be blamed for the project's failure. That can't be effective - it will lead to more blaming, this time from the customer, and eventually to sour feelings all around at best, costly litigation at worst. If the relationship is broken, the project can't succeed; better to acknowledge that, and work on repairing the relationship - which can entail severing it altogether.

Pinning the problem on an "absent customer" is also a nice way to avoid facing our own responsibilities in creating the situation.

- Software Development - one comment / No trackbacks - § ¶

07 March 04 - 21:16Agile Product Build

Phlip kicked me off on the subject of build discipline, with the wonderful question: "In an agile context, how do new people on the team get up to speed on how we compile, build, package and release the product ?" Phlip mentions a classic solution, in which the project's "eldest guru" assists the new person in setting up their workstation.

My recommendation: "All release builds are to be done off a virgin workstation."

Tools like VMWare or Virtual PC provide an economical way of getting a virgin workstation whenever you need one.

If you release frequently enough (like once per iteration), that rule would flush out the appropriate solutions to that problem in your context. (There's a meta-pattern here - "Prescribe the problem".)

"Eldest guru" is an antipattern. The new guy has to be able to make a product build, provided only a pointer to the source repository and a page of documentation. The dark lore of what incantations are required to reproduce a build needs to be extracted from the gurus and stored in the form of shell scripts and (lightweight) docs. "What we need to do a build" is part of the intellectual capital tied up in the product, just as much as the source code. It must be inspectable, reviewable, modifiable, just as much as the source code.

I've consulted to one firm where the people thought they could do a build without the Eldest in attendance. Then one day they actually tried that, at my prompting. Surprise...

As for third-party version issues, there are different kinds of dependencies involved, and thus as many different kinds of solutions. "Nice" components (dependency is on a single file, such as a JAR file) go into a "binary" directory of the version control tool; the file needs to be adorned with a version number. Components with a more complex directory structure can reduce to "nice" components if you zip up the whole thing. Nice components can be stored in a configuration management tool. In a pinch, a "binary stuff" directory in CVS will do. Component files should be named to reflect the version of the component your build depends on, such as "coolcomponent-1.3.jar".

"Nasty" components (such as Oracle or Sybase DBs) are a different problem. One solution is to install those on your virtual workstation, off a "clean" OS, and snapshot the workstation's hard disk. Label the snapshot file with a version number and store it with binaries. As soon as you have more than one "nasty" component, that stops being as good a solution - you get closer to "clone a developer's hard disk".

A top-level "manifest" file lists all the third party components, with the component's version, and the name and more importantly the URL of the vendor for each component.

Vendors go out of business a lot more often than you think, compared to the lifetime of a project or product. A reproducible build discipline insures against that risk. If you don't insure against it, I guarantee you will have a nasty surprise at some point.

The following spiel is how newbies would ideally be greeted by their mentor for their first day of actual coding:

"Hi Dan, this here is your brand new workstation. Please take ten minutes to pull down the sources from the CVS repository 'CoolProduct', which lives on the server named Gandalf. Run the top-level make script; when you get to a green bar, raise your hand and I'll scoot over to pair with you, and introduce you to the story I'm working on. We'll see how well that twenty-minute presentation of the metaphor from this morning worked. If we've screwed up and you don't get to a green bar within twenty minutes, just holler."

- Software Development - one comment / No trackbacks - § ¶

05 March 04 - 20:45Jumping straight to code ?

Does XP recommend jumping straight to code?

Cleverly hidden in the chapter "Lifecycle of an ideal XP Project", we find the following recommendation from Kent Beck in Extreme Programming Explained:

You are done with exploration when the customer is confident that there is more than enough material on the story cards to make a good first release and the programmers are confident that they can't estimate any better without actually implementing the system.

Now, "You are done with X when Y" does not necessarily mean "You are NOT done with X until Y". But it is perhaps wise to read it so.

An XP team would, however, expect to get through exploration rather faster than a team planning to g through a more formal process of requirements elaboration. An XP team usually assesses the risk of speculative overdesign as larger than the risk of insufficient initial exploration of the requirements. To an XP team, the correct way to mitigate the latter risk is to have exploration of the requirements continue throughout the project.

- Extreme Programming - No comments / No trackbacks - § ¶

04 March 04 - 21:29Software processes as risk models

To the computer security specialist, one of the basic tools is the threat model. This is a model that gives you an idea of where, when and how an attacker is likely to compromise a system's security. The model must be clear and simple, because all security decisions must relate to it in some way. For instance, the threat model to which we owe innovations such as SSL is the "man-in-the-middle" model.

In large part, methods such as Extreme Programming, the Unified Process or the Dynamic Systems Development Method (DSDM) are the expression of a model. The model concerns the main risks that face a broad category of software projects, and drives your risk management activities. In this view, the key differences between one method and another are the type of risk they take to be most important.

What distinguishes XP, for instance, is that it pays serious attention to human risks, such as burnout, bad expectations management, or "job security" (a.k.a. truck number) issues; it stresses particularly the risk of low internal quality; it is heterodox in contending that, in the presence of comprehensive automated testing, overcomplex design is more of a risk than simplistic design; and it places a lot of importance on schedule risk.

If you look at defined software processes as risk models, you might come up with different answers to questions such as "Which process to choose", "Can we mix and match practices from different processes", or "Which practices should we begin using first".

The first thing you would do is review the risks that your projects have been most vulnerable to. Then you would look at how candidate models address these risks. You would focus on the practices which deal with your top risks, and try to mitigate the meta-risk of adopting new practices by assessing the effectiveness of your favorite methodology in a "laboratory" setting - practicing on a toy project or small pilot, attending a workshop, etc. Lastly, you would look for any risks introduced by your candidate method, and whether you need to do anything about these.

- Extreme Programming - No comments / No trackbacks - § ¶

03 March 04 - 20:41Just another road wreck

Today's thought is just a quote:

An organization that can accelerate but not change direction is like a car that can speed up but not steer. In the short run, it makes lots of progress in whatever direction it happened to be going. In the long run, it's just another road wreck.

-- Tom DeMarco, Slack

- Management - one comment / No trackbacks - § ¶

02 March 04 - 21:43Rituals

It's been one of these days of mostly staring at the screen, struggling with any number of things that have to be done, not being able to decide which of them to do next, and ending up doing damn few of them overall. I've started and thrown away more blog entries than I wrote last month.

This isn't a crisis for me. Working for the most part alone, which is the aspect of being in business for myself that I like least, I've had to find ways of dealing with ups and downs in inner motivation, since I can usually not rely on someone else providing motivation.

As the day draws to a close, though, I find myself better for having a small, simple ritual to take comfort before going to sleep and finding a better day tomorrow: a simple, ordinary evening cup of tea.

Rituals anchor identity - small things that we rely on to stay constant in otherwise fluctuating lives. I find myself wondering how teams and projects, too, use rituals in difficult or frustrating times.

- Private Life Of The Brain - one comment / No trackbacks - § ¶

01 March 04 - 09:18Building blocks of project plans

I've recently read DeMarco and Lister's "Waltzing with Bears", a short and useful book on risk management which confirmed some of my own prejudices on the subject.

One idea in particular stood out and made me look at project planning in a new light:

A very simple test for risk management is to look at the project plan laid out in Project or in any other scheme, and ask the people involved, the people who understand the project, to point to a task that might not happen at all. In most projects the personnel will stare at you in complete lack of comprehension. They say, “Well, why would we have something on the project plan that wouldn’t happen at all” and my answer to that is: because that’s a risk.

If you have a background in programming, consider the following analogy, which might be more convincing to you. One early breakthrough in our field was Structured Programming. One key idea of Structured Programming was that a vast number of algorithms, even extremely complex ones, could be expressed in terms of just three fundamental elements:

• Sequence - do A, then B, then C
• Alternation - depending on some condition X, do one of A, B, or C
• Iteration - repeat A, until some condition X becomes true

Structured programs are hierarchical breakdowns of a task to be accomplished into sub-programs, each of which is exactly one of the above forms.

For instance, a simple algorithm to report an account balance is, at the top level, a sequence: "initialize balance amount to previous balance", "add transactions to amount", "display amount". The second step is further broken down by expressing it as an iteration: "repeat 'add current transaction amount to balance amount' until 'there are no more transactions'." Within this, the logic to handle each transaction may be expressed as a choice between two different processes, one for a credit and one for a debit.

In terms of this model, most people's understanding of project planning is restricted to just one building block: Sequence. This is insufficient; you would be unable to express most algorithms if all you had at your disposal in a programming language was a way of stringing operations together in sequence. Project planning approaches in strict Waterfall mode are similarly unable to cope with realistic levels of complexity. Well-managed Waterfall projects may of course react in more sophisticated ways to actual events; I'm only saying that the description of a project plan as a sequence of tasks cannot be an accurate representation of most projects.

More modern approaches embrace iterative development - essentially adding the Iteration building block. That does not mean that we dispense with the Sequence building block - within an iteration, there are still things that will be done in a determined order. Still, iterative processes emphasize only two of the three building blocks from structured programming; no provision is made at a relatively high level for Alternation.

(Update: I knew I had stolen this idea from someone, but couldn't remember who; I've remembered now - I got it off Alan Francis' Wiki.)

- Software Development - No comments / No trackbacks - § ¶