Try "If the only tool you have is a portal server, you will see every web application as a portlet"... and probably add 20% to your project as a result of needless complication to design, implementation and development environments.

IMHO, portal servers (everything implementing JSR-168) are a technology still waiting for the right problem to come along. Unfortunately, too many companies have brought the sales pitch and fork over big $$$ for the IBM and BEA suites and are using it for all web application development, irrespective of how devoid of portal-specific requirements the problem domain is.

Am thinking ahead of my Driver
- What is the next test?
- What is the next requirement?

Fully understand what the Driver is doing
- Make sure they are constantly explaining what they are doing
- Slow them down if needed

Am performing a continuous code review
- Constantly looking for "broken windows"
- Refactor ruthlessly
- If a needed change is too disruptive now, write it down for later work, or...
- Add it to team technical debt board

Am fully engaged/not bored
- Ensure frequent Driver/Navigator rotation

Do not correct my Driver's spelling errors (when the IDE will pick them up)

Am aware of all the requirements of the story
- Have the story readily accessible, either printed or online

Look for similarities between this story and other stories

Keep my Driver focussed on short deliverables
- Red, Green, Refactor
- Am looking for the next check in opportunity

Make sure all the pre check-in tasks have been completed
- Tests
- Automated quality tests

Critically examine the development process
- How can it be done quicker, better, etc.

I should note that I'd observed this team's standups for a week or so and they were short, energetic and focussed. The only issue was the developer's not feeling they got a lot of value out of them.

Note: I take most of what should/should not be in a standup from Jason's excellent article.

• There is a single, centralized development team of 4-5 people all working on the same codebase
• The team works in short iterations of 1 week length
• Only the developers and Development Manager attended the standup (i.e., all Pigs, no Chickens)
• Although the development team is split across two separate rooms, there is a large amount of verbal chatter between the devs, within and across the rooms
• Status was tracked on a BVC visible to the entire company (of 14 people)
• The team had fallen into a nice groove of producing high quality code at a sustainable pace.
• The development team all signs onto a http://www.campfirenow.com/ channel as soon as they arrive in the morning and stays monitoring the channel throughout the entire day.

It's this last point which made the idea of not requiring a standup compelling. When observing the standups that were happening, I kept urging the team to present information that would be useful to their fellow developers... but they couldn't think of any. On checking the logs of the Campfire conversations, everything which I would consider gold standup material had already flowed across the ether at some stage during the day.

In short, I couldn't see any extra value that a standup would bring to the team. And the struggles the team were having in performing the standup were a sign of this.

I cannot see myself giving this advice to many (any?) other teams, but I think this is one of those situations where the team is communicating and performing at a level where no additional process is needed to support the way they are working.

The client have been doing a great job adopting lighterweight process just from reading books, so I haven't needed to suggest too many changes to their daily working lives, just a tweak here and there.

But by far the simplest change we implemented is bringing the biggest benefits. The development team were using a story wall on a pinboard to track work during iterations, but due to the layout of the office, the pinboard was located upstairs in the development area and therefore only benefitting the development team itself.

My suggestion was to move the wall downstairs so it was visible to everyone in the entire company. Almost as soon as doing this, the marketing and sales people started asking questions about the purpose of the wall and quickly understood what information it was showing. They were most appreciative of being able to see what features were in development, completed or not yet started. Based on this increased understanding, conversations between the business and the development team increased and were based on a common understanding of the current state of development.

So, with the cost of a longer trip downstairs to update the story wall for the developers, it's ability to act as an Information Radiator was increased greatly.

Postscript: 2 days after the story wall was moved downstairs, it was joined by another story wall created by the marketing team to track their tasks :-)

Dress it up with fancy names all you like, but at it's heart an estimate is a guess. Whilst I wouldn't recommend using these terms synonymously with clients, so many of the problems people have with estimates are based on over-reliance of their accuracy, so a little expectation setting generally doesn't go astray.

An estimate is not a quote

This is an old chessnut, but I found myself explaining the difference between the two terms to an experienced client PM recently, so perhaps it's not as common knowledge as I'd thought...

Think of it this way: ask someone how long it takes them to travel to work each day. Now ask them the same question again, adding that if they're later than they said, they'll be fired immediately. Now look at the difference between the two responses. The first is an estimate, the second a quote.

All estimation is analogous... eventually

Analogous estimation is the technical phrase applied to the technique of "if it looks like a duck and walks like a duck, then it will probably take 10 weeks because I built a duck last year in 10 weeks". All estimation models were derived from empirical research and are therefore effectively analogous estimation.

Why is this important? Because once you realize that all estimation models are based on numerous highly variable assumptions, you start to see the reason why so many estimates are staggeringly inaccurate.

The quality of the estimate will not exceed the quality of the analysis upon which it is based

I think this pearl of wisdom was passed to me by Robin Gibson a few years ago - not sure of the original source.

This is another take on the Garbage In, Garbage Out principle. In short, you cannot expect a high quality estimate without high quality analysis as input into the estimation. If there are high levels of risk around requirements or large numbers of requirements are missing, then the quality of the estimate will suffer. There is no way around this.

The precision and scale of the estimate should match

(I've seen this one in popular software engineering literature somewhere, but cannot for the life of me remember where.)

There's no point presenting an estimate for several years of work in days. Similarly a short estimate of a couple of days should not be presented as a fraction of a month. Make the precision of the estimate similar in order to the scale. In other words:

Given the imprecise nature of estimation, there's no point in over-specifying the precision: doing so will lead to a false sense of confidence in the accuracy of the estimate.

There are always too many variables in an estimate to quantify/predict

So assuming you did build a duck last year in 10 weeks, how likely is it to take 10 weeks this time around. Consider the following:

• Is it exactly the same sort of duck? Are there no hidden requirements that end up making it more of a goose?
  
• Will you be using the exact same team as last time? The same developers? The same testers? The same BAs? The same infrastructure and support teams?
  
• Will you be using the exact same technology stack as last time?
  
• Will the environments into which your duck is being deployed be the same as last time, or is there a new version of PondSphere (TM) to contend with? And a new team to manage the deployment?
  
• Does all forms of duck manufacture now have to be certified as SOX compliant?
  

Invariably the answer to at least one of these questions is "no", at which point your use of analogous estimation will give a rough guide at best.

Padding an estimate only gives the impression of accuracy

Although most people have seen the research stating the only way to truly get accurate estimates of any kind is to get right into development, I've worked in many environments where estimates within a 20% tolerance are required well before any form of development has commenced.

Practically, the illusion of accuracy is usually achieved by padding the estimates so amply that the risk associated with early estimation techniques is mitigated by the size of the contingency.

Achieving accuracy in estimation isn't worth the effort

Of course, this all depends on your value system, but I think it is fair to say that there should be more important things in a development project than accurate estimates - faster time to market and responding to changing customer requirements being some of them.

Unfortunately, I've seen way too many project environment where external constraints (often project budgeting mechanisms) force accurate estimation and planning to be a more highly held value than they perhaps should be.

Estimates are quantifiable, people aren't

For some inexplicable reason, people working on software development projects tend to not like being considered as quantifiable resources with predictable behaviour. We're still some way from generating an estimation model that can factor in the marriage breakup of the lead architect half way through the first release and the growing animosity between the BA and PM since the Christmas party.

But as long as people accept that an estimate is a guess likely to be inaccurate for the vast majority of the time, this shouldn't be a problem, should it?

Note: by the time of the technical interview, the code review has already been checked by other people and considered to be of a sufficient standard to continue the recruitment process.

There are many ways to discover information about the quality of the candidate in this part of the process: some obvious, some not so obvious...

• Why did you choose the Strategy pattern for this solution? Would any others have been appropriate?
• What do you think of how you've tested this method?
• Did you consider any alternative solutions to this problem?
• Can you refactor this class to make this dependency injectable?

In many cases, answering these questions mandates the candidate using the keyboard to navigate around and/or change their code review solution to implement suggestions given by their interviewers. For me, a big indicator in determing how experienced a candidate is how effectively they use the keyboard and keyboard shortcuts to modify code. If I'm interviewing someone who says they have 5 years experience as a developer, yet they are still using the Edit menu to cut and paste code, then I know they're either:

• Nowhere near as experienced as they claim to be, or
  
• Not competent enough to look for and find mechanisms to increase the speed of their typing (e.g., keyboard shortcuts)

Likewise, there is a strong correlation between years spent developing and general typing speed. Someone who is cutting a lot of code is going to have developed fast fingers. Ditto for IDE familiarity: I've interviewed people who have used Eclipse for years yet have no knowledge of the refactoring options available on the context menu. This level of ignorance doesn't make my think they're lying about their experience necessarily, but it certainly casts some doubt over their ability to extract the most power out of their tool set.

The absence of any of these indicators is not necessarily a deal breaker for me in an interview situation, but it does make me probe even deeper with questions to ensure sufficient technical knowledge.

However, I think I may have found a potentially valid reason why ClearCase is the installed VCS in so many shops - and it's all down to the value system of the customer...

The meeting was somewhat unusual in that whereas I was suspecting it to degenerate into a scrap between the two sides over relative merits, it ended up being very civil and with little/no rebuttal of any of the points I had made. Also interesting was the realization that I don't think anything I said made a scrap of difference as none of the people I was talking to were developers, they were all release engineers.

Release engineering is another task that I believe should be incorporated into the development team rather than separated into a specialty profession. If the development team has no responsibility over releasing their software, there is no driver to produce software which is easy to release. I'm from the "eat your own dog food" school of thought and prefer to have the development team share the pain of software that is difficult to release.

However, in environments with specialized release engineers, I can see the attraction of a VCS which makes constructing a software package from a variety of disparate code branches and labels relatively straightforward. ClearCase certainly seems to provide a lot of inbuilt support for this phase of software engineering, certainly in comparison to the CVS/Subversion family of VCS which state openly that they don't wish to play in this area.

So in places where the voices of the release engineers are louder and/or more influential than those of the developers, it probably is no surprise that ClearCase has been successful in establishing a beachhead... and even more of a reason to combine the release engineer/software developer roles to ensure the best tool is chosen to satisfy the two main parts of software engineering which depend most on the VCS.

Thinking back over this period and my own behaviour, I've noted a couple of work habits which I began using in a fury and then have dropped off quite substantially of late: debugging and IDE-based global string searches across the entire codebase. On reflection, I think both of these techniques are strong indicators that a developer has a poor mental model of the overall shape of the codebase as there should be no need to resort to using these very blunt instruments in an ongoing fashion when there are far superior alternatives which should make the need for debugging and global searching almost disappear.

Unfortunately, I didn't have the foresight to actually measure the number of times I fell back on debugging and/or global searches to answer particular questions, but I think it would make interesting reading as I know the number have dropped off markedly of late. Perhaps on the next new project...

A coach needs no deep knowledge in the subject's domain to assist them in discovering their particular solution, but is well versed in applying a question-based framework to encourage the self discovery necessary for the subject to uncover the solution.

Does this distinction matter all that much? Not really. I'll still describe myself as an Agile coach in all but the most purist of circles, although perhaps there is a need of differentiation between a "Coach" (the profession) and "coach" (the task).

Which is the conclusion I came to when I decided not to continue trying to integrate Log4J with Websphere (which is apparently not the walk in the park it should be) and just allowed Websphere to use it's native logging.

In the end, using the native logging system (Java Logging, methinks) gives me everything I need and the pain we were experiencing trying to force Log4J into the picture just wasn't worth the hassle.

One to the the Wookie!

"How many emails do you receive from your manager which have been originally sent to him and he's then forwarded them to you (and possibly others) with no change apart from the addition of an 'FYI'?"

In other words, how much value is being really added to the organization by this individual? Working within a large corporation, I'm frequently the recipient of emails containing up to three levels of nested "FYIs", as they've trickled down the corporate hierarchy to the worker bees.

Of course, if you find yourself forwarding on the same emails to others with nought but an extra FYI, then you might want to ignore this post :-)

Not surprisingly, the larger the bureaucracy, the more intractable the rules. For example, these are a couple of ones I've come across on client sites over the last few years: