Hot Needle of Inquiry

Does that need any clarification?

From time to time in discussions, people will use a phrase like the one above. What it means, of course, is that the recipient is an idiot who doesn’t understand what’s going on. The statement means “I cannot refute your foolish and unrealistic argument but I don’t intend to change my mind.”

Still, it’s not quite as bad as “In the real world …”. You have to admit that.

“What color is the sky on your planet?” is right up there too.

If you ever catch me using any of these phrases, call me on it. I’m in the book. The Mars book.

For some reason, I’m remembering a guy in Florida who pushed his team to commit to more and more. I asked him why after the meeting. He said “People need stretch goals.”

Now a little pressure helps me get things done, I freely grant that. But it only works if I get them done: otherwise the pressure just frustrates me, makes me feel bad, makes me slower still.

For the business, the value of Agile is that you know where you are and that gives you a good idea of where you will be. If you’re working on stretch goals, you don’t know where you will be, you have some under-pressure wish-driven fantasy picture of where you will be. All you know for sure is that you won’t be that far along. You have doomed yourself to disappointment.

As managers, we need our developers to find their joy in getting things done. We will not prosper if they get off on the joy of heroic effort, or the joy of slamming in last-minute fixes that will save the project if only they are successful. 

People under pressure take shortcuts. In software development, shortcuts show up when poorly crafted code slows us down and piles bugs upon bugs. We don’t need that.

We need to know that when something is reported done, it is actually done, working, complete. We need to know that it won’t have to be revisited, taking up an unknown amount of time in the future.

Pressure makes that impossible. Pressure robs us of what we need.

To get what we need, to get things done in a predictable fashion, to get things done well, we cannot tolerate stretch goals. We need to value commitment to a result that can be attained. Stay away from stretch goals, that’s my advice.

Science and the scientific approach works well for many purposes, including possibly its ability to convince others.

When we make decisions based on any kind of “true faith” approach, (more…)

This idea came up while Chet and I were discussing politician’s answers to questions, which seem often to have nothing to do with the original question.

Q: Senator, what is your position on launching a pre-emptive attack against Georgia?

A: The protection of this great nation is my highest priority.

Q: Yes, but what about an attack on Georgia?

A: My opponent’s views on the economy are retrograde and misinformed.

Whenever we’re just going along and suddenly we see a duck, it is mandatory to say “Oh, look, a duck!”. This is well-known. Even though it derails the conversation, we just have to do it.

So if we were to carry a throw-down duck, when the going got tough, we could throw down our duck and say “Oh, look, a duck!”

I hope this idea is useful to you and I look forward to seeing a lot of ducks at the next conference.

I’m more or less beavering away on the Kate Oneal articles. The overall flow of the book will be events throughout Kate’s project, company, career. For now, articles are roughly chronological but are covering topics that she and I think are more urgent. I wish she’d do more of the work.

I’m very interested in people’s reactions to the material, and welcome ongoing comments here following this article, or via email. Remember to include [ron] as part of your subject in email to me, unless you’re sure you’re already on my whitelist.

Here’s the Index of Kate Oneal Articles.

Thanks!

Don’t these people have anything useful to do? Even if Obama had been referring to Palin as a pig, which he clearly wasn’t, if you’re grown up enough to run for VP you’re grown up enough to wave off a stupid insult.

I’ve seen third-graders run better elections than this. 

Here’s a little something I wrote to the Scrum list, to the 14,321st team who are having trouble using tasks in Scrum planning. This team was having trouble getting through the planning in under 2.5 days. (!)

Well, first of all, tasks are teh suck. Breaking the job up into tasks means you have to put it back together, which is always difficult. I’m writing a Kate chapter about that right now.

What I recommend as a planning process is this:

1. Product owner writes story on whiteboard, and explains it.
2. Briefly discuss how the story will be tested.
3. Developers briefly brainstorm and list technical steps needed.
   (Similar to tasks but we’re not going to do the work, nor track it that way.)
4. Repeat until enough stories are on the board.
5. Look at the list, draw the line where you’re confident you can accomplish everything above the line.
6. Commit
7. Do stories as a unit, not broken into tasks.
8. Burn stories, not tasks.

Q: But for this to work, everyone would have to be able to work on everything.
A: Yes, that would be ideal. And you could do pair programming — that would fill in needed skills and people would learn as well.

Q: But even so, for this to work, stories would have to be very small.
A: Yes.

Subsequent to the Technical Debt workshop, Chris Sterling posted on the IT Manager’s Dilemma, concluding that they make “rational” decisions to get where they get. Matt Heusser offers some thoughts suggesting that technical people need to make more principled decisions when they estimate and do their work.

I’m not optimistic about people making principled decisions, as a rule. We don’t seem to be wired for it. If our manager is pushing for more features, and the penalty for writing bad code is to get to write more bad code, it is a reasonable response just to go ahead and do it. Anything else will be painful, and we were built to avoid pain.

I don’t work for a living, and do not hope to any time soon. So I don’t know whether, under pressure, I’d be less inclined to write crappy code than I used to be. My guess is that I’d do better than I used to, for two reasons:

1. I’m just better at it. I’m more sensitive to bad things arising, and know more and easier ways to make things clean. So I’m guessing I’d do better just because I’m a bit less messy by habit.
2. I’m more clear in my mind about where my joy comes from: from doing the work as well as I can. So I’m guessing I’d be a little less sensitive to the temptations of the situation.

But I really don’t know. Still, I think that the notions above are just about our only hope when it comes to keeping tech debt down. We need to become better at seeing debt and removing it, and we need to care more about our craft.

We can get help with the first of those. As for caring … I don’t know how to help you with that.

As my old friend Charles Bair used to say, that’s a two-part question. “How?” and “should user stories be written?” The answer to the second question is “No, not really.”

This notion comes up owing to preparation for a panel at Agile 2008, in which I have decided not to participate for personal reasons. But I’d like to share my concerns and thoughts.

What is a User Story?

A User Story is a piece of system functionality, understood by the Customer / Product Owner, representing an increment of business value, to be implemented by the team.

A User Story is not a requirements document. It is not a written communication between requirements giver and requirements implementor. A User Story is just “a thing to do.”

How is a User Story Devised?

Well, in principle a user story can be devised in any old way. The requirements giver “thinks them up”. However, there are valuable principles to consider.

The “As a … I want … so that …” notion reminds us that we need to consider all the users of our product, that we need to consider what they want to accomplish, and that we need to turn that into a feature that they want. These are all good things for a requirements creator to think about … and they are all valuable to communicate to the developers, to aid their understanding.

The “INVEST” notion reminds us that stories should ideally be Independent, Negotiable, Valuable, Estimatable, Small, and Testable. All good notions that should be considered when deciding what to ask for.

So these ideas are very important during the time when we are trying to think of stories. At least some aspects of them are well worth communicating across the whole team.

How is a user story communicated?

I’ve written on this before, in my article on Card, Conversation, Confirmation. The fundamental notion for our purpose here is that a story is communicated to the team by conversation. The communication is not a written document supported by Q&A. It is an explicit conversation between product owner and developers.

The conversation ideally ends with a clear statement of the acceptance criteria for the story, answering the question “How will you know that we have done what you’re asking?” The answer comes, again ideally, in the form of one or more executable tests which, when they work, show that the story is done.

How is a story tracked?

A story goes through a number of state transitions in its lifetime. It starts as a gleam in the eye of the product owner. It becomes something the product owner really wants. It becomes something that the product owner decides to schedule. It gets scheduled into an iteration. It is coded. It is tested. It is finally deemed to be done. Through all these states, we want not to lose the story, and usually we want to know what state it is in, especially as it goes through those final ones. How might this tracking be accomplished?

One really great way is to create a card representing the story, and post it on a wall chart showing the story’s current state. In one of his excellent articles, Jim Shore provides this picture of story cards on a wall:

Story cards on a wall are simple, public, easy to maintain, highly participative, and communicate very clearly. Highly recommended. What should the cards say on them? Anything at all that reminds everyone of what the story means. The card could say “Overtime Pay”, even if the original thinking was “As a manager of hourly-paid employees, I want them to be paid overtime in accord with the law and our policies, so that they will be properly compensated and we will be rightly seen as a just and friendly company.” We discussed all that stuff in the Conversation. We only need to quote enough of that to remind ourselves what we were talking about.

And remember: the card is backed up by an executable test that is quite probably under version control in the software repository.

That said, some teams, rightly or wrongly, want to do more. Perhaps they want to have some kind of database of story definitions, or to communicate stories across time and space. Personally, I’d push back against those notions fairly hard, but there certainly are cases where that’s what you should do.

When you do, however, you have just committed yourself to a different, heavier form of user story. The card is just a token for the story, used to mark its progression through the process. This heavier thing now begins to serve as a permanent archival document, part of some formal representation of the project. It is certainly OK to do this, even if by some standards it is wasteful.

A formally written story is an option!

By Agile standards, turning the story into a document is an option, not a standard and necessary part of doing user stories.If we are going to do it, we should strive to write the minimum amount that will serve the need in hand, which may be nothing more than to tell some remote team members what is going on. For some teams — few teams, I believe — we have additional needs for archival properties, or distance-communication properties, that require us to do more. We should do that … albeit only reluctantly.

Bottom Line

The story is a user-understood bit of requirements that the team is going to implement.

The best way to communicate to the team what is needed is to talk with them. The best way to be sure we have a mutual understanding is to define a test. Some kind of document might be provided as backup or detail on the conversation. That document should not be carrying most of the weight of the story: it is the job of the conversation, and the confirmation, to do that.

The “As a … I want … so that” and “INVEST” notions are quite important during consideration of what stories we need, and may be important during the communication of the story to the team. That doesn’t mean anything should be written down in this format … nor does it mean we can’t write things down that way if we want to. We’re allowed to do that. It’s not required.

Thus we see that a user story is a thing that needs doing, that must be effectively communicated and tested. We see that a user story card or a user story tool entry might be a written sort of thing. But the writing is not the most important part. Quite likely it is the least important part, far behind the thinking, the communicating, and the testing.