Jay Fields' Thoughts

Last weekend, at the Hacker B&B, I mentioned to Jason Rudolph that my current team has no cardwall. He was a bit surprised and asked what we do have.

We track what needs to be done in 3 stacks: Eventually, This Release, and Tech.

Our stakeholder gives us requirements all the time. We also think of things that need to be done on a fairly regular basis. All requirements are captured on an index card with about 5 to 6 words. These cards are not the entire story (pardon the pun), instead they are a placeholder for a conversation. That's fairly standard for the projects that I'm a part of.

New cards are put in Eventually, unless they need to be done for This Release. When a card is done, it's put in a Done stack. Our stakeholder goes through the Done cards every few days and discards them after a quick once-over.

That's it for requirements. It's a very slim process. We estimate at the release level, not the card level.

Some cards are purely technical. We put those in the Tech stack and the team prioritizes as they wish. In general we work on Tech cards when no-one is available to pair. However, sometimes a Tech card is the highest priority and it can get picked up instead of a This Release card.

I mentioned to Jason that I believe we can be successful with this process because of the trust that our stakeholder has in us. As a consultant, I always felt like a vendor instead of a partner. Now that I'm full-time, we're all on the same team. When you're on the same team you don't seem to need as much ceremony and information radiation. This definitely isn't universal, but it's been my experience since I joined DRW.

I definitely prefer the slimmed down process, but I only see it working in an environment with a very high level of trust.

Update: Credit due to Chris Zuehlke for leading the fight for the slimmed down approach. We are more productive thanks to his efforts.

I recently published an article about estimation on InfoQ.

One of the great things about working as a consultant is the ability to try out many different ideas and adapting your personal favorite process to include things that work. This article gives the details about user story estimation techniques that I've found effective.....

read more...

the simplest thing that could possibly work -- it's a phrase held dearly to all agile developers, but it's also a common source of disagreement. I recently saw two different interpretations of the phrase that I considered to be worth sharing.

Often the emphasis of the phrase is like so: the simplest thing that could possibly work. However, recently Ian Robinson was discussing the idea that the emphasis should be: the simplest thing that could possibly work. The difference is only emphasis, but it's a change worth considering.

I was also part of a discussion the other day where a developer was following a pattern correctly, but it was causing us to add a significant amount of additional code. This code would have supported several features that seemed nice to us, but our domain expert hadn't asked for any of those features. I would have been happy to go along if there was a small amount of code or if the nice features were on our roadmap, but neither of those things were true. I began to advocate for breaking the pattern and doing only what we needed to do. It allowed us to delete ~60% of the code we were currently working with.

At first the developer said "this is where we're going to disagree on the simplest thing that could possibly work." He argued that we were backing ourselves into a corner by not following the pattern; therefore, what I was suggesting couldn't possibly work. I took a few moments to consider his point of view. I concluded that he might be right, but deleting 60% of the code we were currently working with meant that the remaining 40% was so small that if we did need to rewrite in the future it would actually be easier than the amount of effort required to maintain the prematurely put in place architecture.

I believe there are occasions where the simplest thing that could possibly work is writing 10 lines of code today that do what you need, and deleting them tomorrow in light of new requirements.

There are, of course, a few caveats. I had been pairing with the developer for about 4 hours and was able to accurately assess what the difference actually was between what we were doing and what we could be doing. Once we both saw how much effort it was to follow the pattern, it was easy for us to trim to the simpler version. I think it would have been more painful to speculate on the pattern implementation effort, and we may not have agreed on the outcome.

Also, painting yourself into a corner when you can jump over the paint is fine, but if someone else keeps painting on the other side, you may not be able to get out. The small amount of code that we wrote can be rewritten in about an hour, but if someone else was going to add to that code then we would have probably gone down the more complicated path. No one was building on our code so we weren't as worried about the foundation we put in place.

Time is one of the most valuable resources.

Because I believe the above thesis, I value Agile because it strives to provide constant feedback. When given feedback, I can adjust for success (which saves me time), or fail faster (which also saves me time).

Pair programming is a controversial topic. The majority of the projects I've been involved with always have at least one skeptic on the team. The skeptics always cause me to take another look at the practice and see if the specific project provides a new point of view to the discussion.

On my last project I learned that large gaps in talent can turn a teammate into nothing more than a spellchecker. This generally seemed to happen when one member of a pair was significantly more skilled than the other. In the case of an experience gap the more skilled pair can slow down and mentor the junior pair member; however, sometimes a story needs to be completed as soon as possible. In the cases where time is very valuable it seems to make sense to rotate in a more experienced teammate or to split the pair until a more experienced teammate can join the pair.

While I generally prefer pairing, if a teammate is providing nothing more than spelling suggestions it is probably not the best use of his time. Furthermore, when an experienced teammate is required to slow down to explain things, then the pair is not closing the card as quickly as possible.

Following a previous entry, Stories are Placeholders not Buckets, Aman King states:

A blog entry from you on "estimating" and how you go about it (for various types of stories/buckets) would be a big help.

On the projects I'm generally involved in each story is estimated twice.

High level estimate
A high level estimate is usually helpful when a story is created. The high level estimate can be used to determine where it belongs in the current release (or in a subsequent release). I prefer that high level estimates be done by 3 or 4 developers. I also prefer the estimation scale be the same as the scale that will ultimately be used for the iteration estimate (i.e. don't use small, medium, large for the high level estimate and 1, 2, 3 for an iteration estimate). A high level estimate usually begins with a subject matter expert (often an analyst) explaining the details of the story. These details aren't the full details of the story, but the key aspects that effect the estimates. Following the explanation and any questions, the devs will independently determine their own estimate for the story. If all the devs agree (or are close) then you move on; however, if the estimates are wildly off then a conversation is had and the independent estimation process will occur again.

Iteration estimate
An iteration estimate is helpful for getting the entire team on the same page and determining which stories will be played in the next iteration. At ThoughtWorks we generally have an Iteration Planning Meeting (IPM) before each iteration. During the IPM the subject matter experts (again, usually analysts) explain all the details of the story. Following the explanation and any questions the entire* dev team will independently estimate the story. If the estimates are consistent, you move on, otherwise more discussion needs to occur and the independent estimates need to happen again (just like high level estimates).

Having 2 estimates is helpful for a few reasons. While the original estimate is good for planning purposes, the iteration estimate is better for determining what goes in the upcoming iteration. The iteration estimates should be more accurate because more people have the chance to participate in the estimation process, and (it's likely that) more information is known then when the high level estimate was taken. Given more accurate estimations and a known team velocity, predicting what can be done in each iteration should be a fairly easy task. Also, it's valuable to track if the high level estimates are generally lower or higher than the iteration estimates. Knowing this statistic can help make the high level estimates more accurate for release planning.

*Generally teams contain between 4-8 developers. For teams of this size having the entire team estimate seems to work well. However, if your team has more than 8 devs, I would suggest breaking into two estimation groups. Splitting the team clearly has consequences. At a minimum you will want each story to be started by at least one person who estimated it. Also, you'll need to find a way to communicate the details of each story to the half of the team not involved in estimation. I've seen this handled 2 ways.

• The details of the story are presented to the entire team, then the team is broken to estimate.
• Team Split 1 presents their stories to Team Split 2 following estimation and vice-versa.

I've used both, and they both seem to work fine.

Despite the consequences, splitting large teams for estimation has been much more effective in my experience.

Agile methodologies often use stories as requirement documents. Stories are placeholders that signify conversations that will need to occur between the customer and the developers before features are implemented. A story gives a high level idea of the required functionality; however, the details of the functionality live in the mind of the customer until they are expressed to the development team.

Stories are generally concise and purposefully vague; however, they do contain enough detail for the developers to estimate the level of effort required to implement the feature(s). Accurate estimates are crucial because they are used to plan what is in and out of scope for a release. Clearly, inaccurate estimates create volatile scope.

The importance of estimates has the following implication: Stories cannot be used as Buckets.

An example of a bucket would be:

"Create Reports" or "Deploy the application to a production environment."

If the 'production environment' is known this is a perfectly valid story. However, the story cannot be accurately estimated if the 'production environment' is a box that will be ordered later in the project and the platform is still undetermined. A story in which the details are unknown at this point is nothing more than a bucket.

The largest problem with buckets is that they generally end up being far too small. Traditionally, buckets represent the more complicated parts of the system because they aren't yet understood or defined. Since they aren't fully understood, often buckets are pushed off until near the end of the project. Because buckets are generally addressed at the end you are generally already working with a mostly written system that hasn't taken in to account the effects of the bucket. While everyone should be striving to write systems that are flexible and maintainable, having any system at all often makes things more complicated than when the bucket was originally envisioned and estimated (which is another reason buckets are often underestimated). Another problem with buckets is that they often end up with things that don't belong in them. This is also a product of defining a bucket toward the end of a release. Since the release is nearing it only makes sense that the business would like to put as much in a bucket as possible. Of course, overfilling buckets doesn't work either. As Martin already noted:

You can't put ten pounds of shit into a five pound bag.
--Anyone who has tried

Unfortunately, over-estimating buckets is also problematic for the planning process because it breeds distrust between the developers and the business.

This does not mean that buckets do not have their place in agile projects. It is always important to capture required functionality whether or not it is well defined at this point. However, buckets simply cannot be stories or the planning process will break down. Any bucket that must be in the current release likely represents the largest risk for the current release. Therefore, the current release should be limited to stories and buckets should live only in subsequent releases.