Pretend you have a team cranking away at a production app (likely full of technical debt). Part of the IT staff, so to speak. Management has a year’s worth of features, and of course wants to be able to plan when things will get done. This was my response to an agile coach who is working with such a team that is having trouble with their estimation accuracy.

Please have a seat. Yes, over there by the window is fine. Buckle up. You may experience some turbulence.

If you want to know “when you can get all that stuff done,” sit the team in a room, show them the list of stuff, and ask them. I’ll give you an hour. I suggest you have them use seasons from the sounds of the current mess 🙂

If you really want to know within a month as to when the list of 1000 issues will be done (including the 250 that you don’t yet know about), then wait until you are about to release, and you will have a very accurate estimate.

I doubt that estimating accurately or poorly will help all that much in knowing when an entire list of stuff will be done. Especially when the list changes over time. Given that, why spend any/much energy? “Don’t polish a turd.”

Why not simply guarantee to management that the team will do their best effort. Just grab a stack of important (i.e., prioritized) stuff to do (loosely based on a logical roadmap/release plan), track the amount of things done each iteration on a chart. Skip the up-front waste of time estimating everything in detail. I mean really… just take a stab at “we can do these 20 things this iteration” and see how it goes — adjust as needed. The effort should take all of about 30 minutes each iteration depending on your tools and your team collaboration, and ability to know what those 20 things are.

Put an indication on the chart of number of total issues — but be ready to continually update this as new issues/bugs arrive (it’s lots of fun to watch the goal continually move further away). Or have the chart represent the bare minimum marketable features (bigger ticket items without the details). Now anyone can sense the rate of closure of the team towards the goal as each iteration piles on more closed issues. After two iterations, you can draw a straight line, after three, you can use fancier curve fits and show the least squares correlation coefficient <g>.

Instead of spending time estimating, spend time making the project progress “information radiator” as meaningful as possible. Believe me, developing software is merely working a to-do list. Anybody can watch a list of things getting ticked off and do a mental estimation as to rate of progress. Build a better view into what the project is actually doing and let people think about how it might look going forward — no need to debate future predictions. After all, at least your historical data is guaranteed accurate!

The only time I would estimate “more accurately” is if I have competing ideas or ways to solve a problem via wildly differing approaches. Then maybe we might want to weigh one versus the other from a business point of view because it could make a big difference in the long run.

But for an entrenched team on an entrenched product to estimate each little feature/issue/bug fix/story at the outset of each iteration? I question the value of the team’s time being spent doing that. I gave it up for Lent.

Try not doing detailed iteration estimation. It can be very liberating to just do the work as best and as fast as you can.

At some point, you and management will realize that it doesn’t matter if the team is good at estimating or not. At some point you may realize that most of the estimation process is an illusion, a grand trip into self-delusion fantasy land. The same amount of work will get done (well, more will likely get done if less time is spent estimating).

If you need to control what work gets done by when, then you prioritize mercilessly and do a good job to make development efficient (which includes smart architecture and design, among other things). If you need to speed up when the work gets done, then you need to consider resources (better or more) and/or reducing scope.

Now, if you want to spend time making the team better at estimating for their own edification (a la PSP), let them do their own estimates and track actuals and try to improve over time.

(My agile coach friend drew some aircraft analogies…) If only software were as simple as aerodynamics. I can predict quite accurately how a NACA airfoil is going to behave in 2D and 3D airflow. I have never been able to have a software team predict to that level of accuracy. Predicting software is not much different than predicting a relationship between groups of people.

Something to ponder… Why bother with estimates at all?

1. Who needs them and what are they for?
2. What happens if you are dead-on accurate?
3. What happens if you are off by 100%?
4. What if #2 == #3??
5. Are the workers going to be fired with poor estimates? Given raises with good ones?
6. How did they estimate before?
7. Is estimation the best use of their time?

We’re now ready for take-off!

Okay, well more like:

Kent Beck Suggests Skipping Testing for Very Short Term Projects

As discussed by Mark Levison here.

It’s like many things in software — a judgement call.

I agree wholeheartedly with Kent.

If you are in a highly exploratory phase… just trying out a few ideas to see what might work before committing to an approach, why bother with TDD?

Now, if you are lousy at design and doing exploratory work, and you prefer TDD — then use it! Use your best judgement to make that decision based on your current situation.

Caveat Emptor: I am not an expert in TDD, nor have I done it more than a handful of times.

Aside #1

I have always wondered this… as it seems to be a built-in assumption on the part of TDD advocacy. Does TDD necessarily lead to good design? Philosophically, I don’t see how it can be an immutable assertion.

Aside #2

In 2001, when we were in Snowbird for the Agile Manifesto gathering, I remember doing an example of TDD with Bob Martin. After we did a simple example in Java, I turned to another technique to “write” the tests and code. In Together, we had built a feature that allowed sequence diagrams to generate code. Writing tests as a sequence diagram was fun… create test classes, invoke application objects, create the classes for those objects, create methods, add code, execute the tests. Rinse and repeat.

Aside #3

Typically I design by starting with objects… I don’t need tests to tell me the core aspects of the system — but that is my personal choice. Features typically indicate core methods that are needed. When we need to flesh out nitty-gritty logic and what not, then I will turn to sequence diagrams — which could be done with TDD.

Aside #4

I can see where TDD would really help to benefit in ensuring folks stop coding just as soon as the test passes — assuming of course that the test is at the proper “correctness” level.

Summary

For me, I chose to be pragmatic, NOT dogmatic. I chose to use my brain to do what makes the most sense in every circumstance, not a blind allegiance to a process for process’ sake. If barging forward and doing “design and coding” works best for you and your team to flesh out ideas, go for it. Just be sure to go back in and “do the right things” once you commit to an approach that is going to stay in the code base.

In response to a twitter

“I’m tired of the Big Design On The Front. Any advice for persuade other folks how eliminate it?”

I posted some ideas here.

Following on a tip from Uncle Bob Martin, I am going to try this out

Pomodoro Technique in 5 minutes

While I already use a timer for activity tracking, the method is not as nearly as refined and intriguing as Staffan’s

From Alan (a thread on agile project management forum):

Now as to the why-bother:

1. Government reports require (a) a summary and explanation of R&D activities, and (b) an auditable tally of hours spent doing this.

2. To develop some basis for estimation, I need to know how much effort goes into development. My time is very irregular, and I honestly have no idea how many hours are put into programming on any task. I don’t know if it varies from week to week. I don’t know how long it will take to finish a project AT ALL.

I am suggesting that tracking hours is but one small wee part of estimation… and it must be combined with other, larger pieces of the puzzle to impact estimates. Unless of course, your work is repetitive and non-thinking. Like stamping out license plates.

Though you can certainly have everyone track hours & tasks to the minutest detail… what is the other unit of measure? Lines of code? Features? Story Points? That is, will you strive to be able to predict Lines of Code per hour? Hours per feature? Days per Story Point?

See rest of post here:

Tracking Hours for Every Task

Responding to:

John Hebley said the following on 10/20/08 11:08 PM:

Philippe, Jon

May the force be with you. I was about to rant and rave about incompetent managers etc, but that would be just preaching to the choir.

That is a new topic, if you want to discuss it. How do you work with these, often senior managers, that have no idea what you are trying to do, and insist on applying 1970’s thinking?

John

I find it very common that many folks (yes, some of these are “older” managers) retreat to the comfort of what they were familiar with in the “good old days”. Probably human nature when confronted with being out of the comfort zone. I have been doing agile development since the early 90s and have been taking unique approaches to solving problems for longer than that. I am familiar with folks who don’t “get it” or who need a preponderance of evidence to be won over.

A partial list of my responses to an “older manager”:

• I have to suppress being impatient (see personality profile

  below)… You see, for me, many times it feels like battling the

  Flat Earth Society; or the “Gravity Points Up” mentality; or “The

  Ostrich Society”

  • By nature I have always been an early adopter.
  • By nature I am an engineer
  • By nature, I trust, but verify
  • By nature I am impatient to get results
• When I feel stressed by those that seem to “take issue” with what

  I am trying to do to achieve (largely their) business success, I

  take it as a sign I need to do more educating, show more, explain

  more, assume they have validity in their feelings.

• I ask them for things they would like to see that would “prove”

  (to them) whatever the particular matter is at hand

• Funny thing, many times they can’t think of what to ask for, they

  just know “it doesn’t feel right”… Sometimes I find myself

  moving the level of thought “up” for them and I provide ways to

  achieve degrees of “proof” that never before existed at their

  company or in any other project.

• I am profuse in beating the drums of process, quality, testing,

  automation, and many small bits that make up a high-performing

  team and on-track project

• I will make uncertainty, variability, and risk more visible to

  combat the illusion that traditional Gantt charts or Work

  Breakdown Structure approaches to managing software feature

  development are better than the way I run iterative development.

• I will try all sorts of approaches to communicate if at first I

  don’t succeed

• The project wiki is a huge part of this
  • I blog about the project (“News”)
  • I stand up special pages when I have to address yet another

    “senior management” challenge

  • I ensure as many stakeholders and other managers as needed

    are in the loop and are helping to allow the whole extended

    group to “get it”

• When it might be “embarrassing”, I keep the education private (and

  when it would benefit all, I make sure the wiki post or blast to

  the development/project mailing list is not tied to the requestor).

• I work very hard to shelter the team from the details of these

  sorts of “senior management” moments. I let the team know if/what

  folks are “asking”, but I like to minimize those moments that are

  more distractions on the core development trajectory, than helpful.

At the end of the day, I know I am doing my best, often working harder than anyone to achieve the ultimate business goals that the project has been chartered to achieve. I live and breathe the project business goals. I let the chips fall where they may.

For obvious reasons (to me, anyway), in any complex project that I am involved with, there would be no chance of me doing it as fixed-price work. That would compromise being able to respond to the “human” parts of the project and client needs.

— jon

ps: My personal response can range widely, I am sure. Here is the beginning of one (of many) behavioral profiles for me:

Jonathan likes to be forceful and direct when dealing with others. His desire for results is readily apparent to the people with whom he works. He is driven toward goals completion and wants to be in a position to set policy that will allow him to meet those goals. He displays a high energy factor and is optimistic about the results he can achieve. The word “can’t” is not in his vocabulary. Many people see him as a self-starter dedicated to achieving results. Jonathan is aggressive and confident. He is deadline conscious and becomes irritated if deadlines are delayed or missed. He is a goal-oriented individual who believes in harnessing people to help him achieve his goals. He needs people with other strengths on his team. He is often considered daring, bold and gutsy. He is a risk taker who likes to be seen as an individualist. Jonathan may have difficulty dealing with others who are slower in thought and action.

Many times, we in the technical community are faced with well-meaning users and stakeholders that ask for something “their way.”

My wife and I stopped in a fine Italian restaurant for lunch. Sue ordered a risotto dish, while I ordered a grilled salmon over mixed baby greens. When the risotto was served, the waiter offered to sprinkle fresh grated cheese. I was ready to get a fresh spoonful of that cheese deposited right in my mouth, it looked so good.

Then the waiter turned to me and my “salad” and offered pepper. I blurted out that I would like some cheese. (Sue cringed, as she always tries to remind me that Italian fish dishes should never be served with cheese with seafood. )

Back to the technical point… the waiter was very diplomatic:

“I would advise against that.” he said. “Oh! That’s right, no cheese on seafood! What was I thinking?” “Well, rules are meant to be broken, so you may do that if you like. I would just advise against that.”

He didn’t say I was wrong. He didn’t say I couldn’t have what I had asked for. But he carried a certain authority of being “in the know” and I trusted his judgment.

I hope to use this gentle technique the next time I need to respond to a user’s well-meaning, but “wrong” request. Maybe it will help you out as well.

In the agile usability forum, Steve Gordon astutely observed:

“Making these choices is a business decision that requires balancing strategic and tactical considerations in the specific context.”

i agree. imho, one of the roles we, as software professionals play, is to provide the business with some “cost” information and some potential alternatives. when a specific feature idea comes forth from the business side, we are to provide cost (in terms of effort, schedule, and even downstream ramifications). We can also discuss various variations on a theme. For example, many times the development team might say: “Well, providing X is expensive and would take 6 months. However, we could do Y — which seems like it would achieve nearly the same result — for a much smaller cost, and have it done in one month.”

Talk is (usually) cheap(er) than one-way (non)conversations.

That is, a non-agile “Company A” might simply spit out a new feature set idea in an email. Then, the dogmatic development team spits back a single answer (it will cost X). Business chooses not to go forward. Meanwhile, competitor B implements Y and drives Company A to lose business and go bankrupt.

Or, non-agile Company A accepts excessive cost X. Company B does Y, gets it done sooner and eclipses Company A’s much later release of an only slightly better feature X. Company B makes more money, Company A never recoups the cost of feature X.

Talk is cheap — and that’s a good thing when it comes to working as a team for a common goal. Company A did not have a discussion, and it cost them dearly.

a quip from the agile usability forum…

“But I still think that, in the early stages of UI design, in a project where the UI is critical, getting a usable paper prototype, as verified by user testing, is significant progress.”

as an agilist, i would agree.

i tend to run parallel tracks during initial development based on the project specifics. once i have gathered enough requirement details to have a good overview of where we need to go, i might begin some specialized “research” tracks, a.k.a. “spikes”, even as i may be gathering more requirements and building more of the object model. the overlapping activities may be any of these:

• requirements workshop
• a spike to work out technical architecture
• a spike to work out User Experience issues
• doing anything else in parallel that helps to reduce risk
• risk of missing important requirement details
• risk of producing an unusable app
• risk of producing a non-performant app

The challenge is knowing when to do these sorts of things, and not allowing any single “prong” of the attack to get too far or too deep compared to the others. The purpose being:

• you often get diminishing returns, you just need to investigate enough to get the 80% mark (for example)
• you don’t want to waste effort on something that turns out to be obviated by something you discover in another track

It may help you to understand I have a few very closely-held tenets about software development:

• The key to development is separation of concerns
• the core is the problem domain built to support the requirements.
• get this wrong, nothing else in the app matters. nothing.
• not the UI/UX.
• not the 5th normal form DB.
• not the worlds most articulate UML models.
• not the worlds best cruise-controlled, TDD, 100% test coverage,
• not the best joshua bloch-/steve mcconnel-blessed code.
• this core generally transcends UI, database, and even the language chosen to code the app. In other words, the “problem domain” reflects the relatively stable “business” world. I know it sounds trite, but despite all our wonderful software advances from green screen to now, the world of mortgage/insurance/banking has changed little, fundamentally, or relatively.
• the app is all about the “business” needs
• the User Experience/UI is a separate thing
• The persistence is a separate thing
• Carefully orchestrating the various tasks in parallel using agile approaches that hold dear doing the “best thing possible” given the business & development circumstances, constantly adjusting in a smart way.

it is about understanding risks, managing them, and using the elusive stratagem known as “good judgment.”

part of the struggle with conversing on a topic as broad as UX in or outside the ASD loop is one of “size.”

for reasonably “straightforward” features that require UX design, a couple of iterations is usually sufficient to get to a good place. my steps are typically:

• understanding the basic requirement (e.g., we need to use a special service to look up critical special info from a ZIP code as part of a custom address UI),
• the domain details (often down to methods/sequence diagrams),
• some dynamic behavior of how the UI might interact with the domain model/server (after zip is entered, make a server call, get the linked lists of the related objects), and a
• rough sketch.

When to spawn a separate UX project

if the team senses that:

• UX is a major and critical aspect of the final product (as something like the iPhone probably was),
• the design is very complex,
• “getting it right” will impact greatly on the success or failure of the product,
• there is a need to explore a handful of design ideas before committing…

well, sounds like you need to have a project to do this effort unto itself.

The UI is Independent of Domain

In general and virtually “always,” while the “UX Big Design” project is underway, the rest of the team can carry on with much of the other part of the system development. The UI — regardless of the complexity or simplicity of the UX design — is rather independent of the server or domain side of the world. So, even tho my project may have a parallel cool UX design component going on with its own features/iterations, i have all of the features still visible in the iterations through what I termed the “Rough UI.”

Whether the feature is surfaced in an ugly, simple UI control world, or a slick Flex/RIA world matters little. The core “back-end” API still needs to function. As the fancy UI components get finalized, they can be connected to the real API one by one.

Soon the ugly duckling UI turns into a beautiful swan.