Monthly Archives: December 2011

The Perfect Agile/Scrum Stand-up

When people first arrive in Agile/Scrum, one of the first things they ask is “Doesn’t Agile mean we don’t need requirements?” followed by a close second of “Scrum is too rigid. We definitely don’t want something so restricting”

It seems like you’re either a cowboy or a Nazi. There are no in-betweens.

It’s like this: Agile is all about dynamic process tailoring. That means, yes, that teams control the degree of paperwork and process they need to accomplish. But it’s also like this: there are some “recipes” that the community has found over and over again that work. You’d be a complete fool to ignore them.

What happens with high-performing teams is that they have very few things they do that are defined and reproducible. But for those very few things, they are very disciplined. Being Agile, strangely enough, means being extremely disciplined about a very few things and leaving the rest of the details to make up as you go along.

The crux of all this ambivalence is, in my opinion, the stand-up. Since nothing proves a point like actually seeing it, in the video that follows, note the following things:

  • It happens quickly. Stand-ups are high-energy. People are standing-up, moving around. Nobody is sitting in their chair with their head in their notebook or cellphone.
  • Nobody is reporting to anybody. This isn’t a status report. There are no questions and answers.
  • We point at the things we are doing. It’s all about Visual Process Control. That means the things you are doing are publicly visible, they represent status at any time, and they are manipulable.
  • Decisions are made after the stand-up. The stand-up is a game of identifying tokens: what has happened, what is going to happen, what obstacles individuals are facing. After the tokens are all identified, the “real” work begins: the tokens are resolved. Technical discussions and ad-hoc discussions begin.
  • There is no Project Manager. If you can look at a stand-up and find a project manager, it’s a bad stand-up. Stand-ups are about team commitments, risks, and issues. Not roles.
  • Everybody is in the same room. Body language and other non-verbal communication channels count. A lot. Everybody isn’t standing around talking into a PolyCom.
  • It’s scalable. If done correctly, team stand-ups scale very easily. A manager could attend several stand-ups each day, get a close-up view of how the entre program is going, and still have most of the day free for coordination and planning activities.
  • The team is small. You can’t have an Agile team with 30 people on it. Do not do this. It does not work.
  • The story board is not that complicated. This is about the limit of complexity for a story board that I am comfortable with. Past this is drudgery. If your storyboard has the colors of a Christmas tree and a sufficient number of post-its to draw a 40-foot picture of Godzilla, you’re over-complicating things. Stop that.
  • It’s a problem-solving exercise. Immediately after the stand-up is over, the Product Owner talks to anybody with questions or problems and works them out.
  • We work out problems visually. Notice how they pull the story/task over to the flip-pad and work through the problem? See how the options and structures are all presented visually? Here’s a tip: doodling or drawing structures and flow on paper has about a hundred times more effectiveness that trying to write it down or vocally discuss it. Model things.
  • Big Picture is not present. Nobody is looking at long-range issues. Nobody is talking about things happening 4 months from now. Nobody is tapping their foot and asking “are you through yet?” The entire thing works on local optimization. That means that inside of sprints teams locally optimize to finish their commitments. It’s only at the boundary of sprints — demos, retros, and IPAs — that the big picture is important.

Finally, notice it doesn’t match the video. The perfect Agile/Scrum stand-up demonstration does not exist. Teams are different. Everybody has to adapt. As I said in the beginning, Agile is all about adapting. The point is to try things the “best” way — as the community has determined them — and then adapt for your particular situation. That way you don’t miss out on anything, and you also have good reasons for the way you’ve adapted.

Want to rock out your Agile team? Here are the e-books for you.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Programming Team Challenge: Would a Dolphin eat a Dog?

Teams that program have a tendency to talk about things that have nothing to do with programming.

This post has nothing to do with programming. If you want programming, go somewhere else.

Yesterday I was on IM talking about some programming problems, and this question came up: “Would a dolphin eat a dog?”

Pro: Yes. Dolphins are carnivores. Carnivores eat meat. If a dolphin was hungry enough, it would eat a dog.

Con: No. Dolphins are sea animals and have no instinct to eat land animals. Furthermore, they have no teeth and only eat small fish.

There was much discussion, and we learned that a) dolphins actually DO have teeth, and b) it seems the size of the dog might important. A hungry dolphin in a pool and you throw in one of those little miniature dobermans? It ain’t going to be pretty.

I’m on the “dolphins eat dogs” side, and I have a sneaking suspicion that the other side has a slanted view of dolphins from all the great press they get. Take a look at squirrels — just rats with bushy tails and good press. A dolphin would definitely eat a squirrel.

But there was no conclusive argument on either side, so I’m throwing this one out to the internet. Would a dolphin eat a dog?

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Vendor Soup

Many years ago I was working in San Francisco for a large company setting up a PMO. As part of that, we were trying to figure out what necessary pieces the organization was missing in order to establish a portfolio. After looking around, we noticed we were missing a good business process model. Nothing fancy, but enough detail to get our work done.

We kept looking but never could find what we needed. Nobody else had any answers, either. So a few weeks passed and we presented our report to the executive committee.

“Oh that,” one EVP said, “We’re already doing that.”

News to us, and to everybody we spoke to. Where were these folks? In another building in the same city. Who were they reporting to? Some other business unit that wanted the information for some kind of audit to be done next year. Have they spoken to the people who are the most involved with the business process — the thing they were supposed to be modeling? What kind of crazy question is that? They are working for a different project.

You need something, somebody else has it but it’s not configured correctly. You need something else, there are three providers that can solve your problem — but they all do it in different ways. You ask for a solution, you get four people who tell you that, given enough time, the thing they are working on will provide one. You find something for free — and are told that the organization must pay for everything it uses. You generate one piece of business information — and have to enter it into three different systems.

Lots of various questions, lots of people supplying answers to those questions, and none of it coordinated.

Welcome to vendor soup.

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

ScrumMaster Interview Questions and Job Description

Met a great coach today, Peter Saddington. Peter shared with me a couple of high-volume blog articles he’s written on being a Scrum Master. Peter runs an Agile blog over on Thought you guys might like them.

ScrumMaster Interview Questions.

The Perfect ScrumMaster Job Description.


If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Life Fills Up

Every so often, the discussion in the startup community turns to ageism. Why is it that the startup community seems to be so in love with younger people and so critical of older people as startup founders?

My standard reply is that it’s all risk: if you’re 20-ish, you can take on a lot more risk than if you are 40. Venture Capitalists can hire on a hundred startup founders for pennies, they work like dogs, and at the end of the day you get a few winners which makes the numbers work. The 20-somethings get great experience in startups and you get a few winners. As they say in the movies, it’s a win-win.

There’s also the standard answer that people have more commitments as they get older. A spouse, a mortgage, children, student loans — life quickly throws you all kinds of things that you don’t have the option of escaping. When you’re 22 you might live on 500 bucks a month. When you’re 32 your bare minimum salary could easily be five times that.

I’m in my 40s and I’ve spent quite a bit of time on startups, and I’ve found another big obstacle that rarely gets mentioned: life fills up.

After many startup attempts over several years, I’m overweight, out-of-shape and have very little social life. Why? Because I refused to fill my life up with other stuff. Everybody else I know is not like this: they all have civic groups, games, clubs, or other things they spend their time in. I, on the other hand, have always been very miserly with how I used to spend my time. I spend a lot of time reading books, for instance. Makes for a great consulting career. Gives you a shot at forming a startup. Not so good for a lot of other things.

So aside from the usual answer of risk and commitments, there’s another important consideration. Normal people fill their lives up with normal stuff. Softball games, kids’ recitals, technology groups, family events — after a while you find you have no time for anything else. I used to wonder how somebody could work at the factory for ten years, get laid off, and then not have any other skills. How could this happen? To me this was all about not having enough drive. Now I know one of the other answers: people fill their life up with all sorts of things. It’s a real-world example of Parkinson’s Law, which states that work expands to fill up the available time. Life also expands to fill up the available time.

Of course, you can always continue to argue that this is not an optimum situation. Is a life full of watching sports events and chit-chatting in you social club something you want? Or do you want more than that? Whatever your personal answer, it’s obvious to me that people who can commit huge chunks of their lives on one single-minded endeavor are very weird and strange compared to the rest of humanity. They are perhaps not as weird compared to other people in their 20s, the time of life most of use allocate for developing our skills for our careers, but the definitely stand out in the 30 and 40-something crowd.

I used to think the inability to focus narrow-mindedly on one thing just was a matter of self-discipline, no matter what your age. Now I’m thinking not so much. At some point in your life, for normal people, life just fills up.

If you’ve read this far, you should follow me on Twitter!

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Management by Statistics

Almost as soon as you start aggregating numbers, you start making cognitive mistakes. For instance, look at these two scenarios.

1. Women are roughly 50% of the population, yet they are only 10% of your workforce. Is some sort of management intervention necessary?

2. Your manufacturing plant has a robotic process which has been stable and measured for many years. Last week it deviated outside the 3 sigma range. Is some sort of management intervention necessary?

In the manufacturing example, we have a defined set of inputs, a stable, limited-variable process, and a defined way to measure output. Yes, something is going on. As managers, let’s take action based on the math.

In the first example, we are asked to reason by correlation and simile. Because something occurs at one rate in one place, we are asked whether or not a similar thing should occur somewhere else. No, the math does not say with certainty one way or another. Sure you might have strong moral feelings one way or another, and you should definitely act on them, but from a measurement standpoint there’s really just nothing there to show you one way or another. As managers, if we take action we must be clear that we are taking it based on something besides math. Perhaps intuition, or our best judgment of how a workforce should look statistically. (These are very good reasons to take action)

Yet we persist in treating both of these scenarios exactly the same way. Somebody presents us with numbers, and asks us to decide. After all, they’re both just statistics, right?

In the Monty Hall problem, making a choice actually changes the odds, something that is totally counter-intuitive to most people. The history of statistics is full of stories like this. When the Monty Hall Problem was first asked in Parade magazine, over 10,000 people — of which over 1,000 were PhDs — wrote in to the magazine insisting that the mathematically correct answer was in fact incorrect.

People do very badly with statistics. This has not gotten any better over time. And it impacts a hell of a lot more than just math problems in Sunday magazines.

I spent four hours with the Monty Hall problem the first time I saw it. I finally realized you should always switch, but I was still uncomfortable with the answer. Others seem to find the answer quite easily. Likewise, there are mistakes people make with statistics that I seem fairly good at pointing out, while others struggle. I have a high aptitude for math, so my inclination is to believe that different types of problems engage different emotional centers of the brain in different people. Not sure. It would be interesting to see a psychological study of some of these problems framed in various ways for different audiences. I probably shouldn’t hold my breath, though. About 20% of psychology studies that have been examined by mathematicians show serious errors in, you guessed it, statistics.


One of the reasons why I led this piece with a political-type example is that this type of reasoning is common there and we’re all familiar with hearing political-type statistics. Lots of folks play fast and loose with statistics to make political points. If I told you the United States has lost most of its manufacturing jobs, is that a problem? What if I told you the United States manufactures the most in the world, but manages to do so with the fewest number of people? (Much like how the U.S. produces the most agricultural goods, but uses very few people to do so) Would you still think that is a problem? You could argue this either way, of course, but the point is that the same observable reality can be presented in various ways, thereby slanting the story. As the guy said, there are truly lies, damned lies, and statistics.

Yet we are stuck with them. In business, any time we have to make decisions inside a large organization, we are going to be presented with statistics. 91% of people who visit our website come back. Is that a great number? Sure! Is there anything we can do with that? Not really — watch it as we continue to change things. That’s about it. The number itself gives you zero information about causation, which is really what matters when you’re running a business. It just shows a great aggregate metric. Most businesses would assume that the combination of things they are doing creates the metric, but the reality is that it’s the things the business does, plus the unique situation of all the users. There’s a lot in that number that we don’t know. In fact, the hard number “91″ actually gives us a sense of security that is not warranted at all (without being given more information, of course)

Facebook made money because their team was able to generalize huge pieces of the way most users’ brains worked and combine them in such a way to make a sticky app. Aside from the delays caused by switching costs, if any piece of this generalized model proves fragile another model will replace it. People say that Facebook is a great app because the site’s stickiness is good, but that’s wrong. It’s the other way around: the site’s stickiness is good because it’s a great app. “Stickiness” is an aggregate number, it represents the result of the quality of the app. It’s a result. It’s not a cause. The statistic shows you some kind of vague, generalized, mashed-up result. It never gives you causes.

So when people start throwing statistics around, be very careful about what kinds of assumptions and leaps of faith you are being required to make. Statistics are terrible at providing insight, although they might be terrific in terms of feedback. “Sales is up 10%” is good feedback that things in general are better than before, but it tells you absolutely nothing about what has changed in the world to cause the increase. And of course, that’s the most important information to know!

Website designers have had this problem for years. You put up a site, instrument it up, wait a while and promote it for a while, and then what? Tons of statistics, that’s what. Anybody that has used Google Analytics or one of the other packages has seen the pages and pages of reports, graphs, and statistics those packages can generate. Page A has more people spending time on it than Page B, but Page B has greater click-through. Is that a good thing for page A? Or page B?

Some website owners are lucky — they have landing pages and the only thing they care about is getting people to click-though (down the “sales funnel”) to an order. In this case, they’ll make two entry pages, page A and page B, and compare how each performs. Each page is instrumented, and they carefully look at how changes in the funnel change the behavior of visitors. This is called A/B testing.

Most website owners, however, are not so lucky. They are content creators, and their goal is to provide engaging and sticky content. There are lots of ways to measure that — we don’t have easy things like funnels to help us out. There is no one universal metric that makes sense. Maybe a ten million people visit regularly, but only once a year. That’s a great site, but those statistics tell you absolutely nothing about why or how to make it better.

Whether you have a funnel or not, statistics get in the way much more than they help. The critical skill of a good businessperson is selectively looking at certain statistics and making guesses about the market that they then quickly test. Bad business people make no guesses, or they make all the wrong guesses, or the guesses they make take too long to prove out. Out of all the startup skills I’ve studied, this one — effectively inferring intent from reams of numbers — is probably the most difficult. That’s why they tell founders to directly and physically interact with customers as much as possible. It’s as hard as hell to get anything out of a statistical report.

But still, I wonder if A/B testing might be useful in a lot more places than just sales pages, from regular content sites to industrial statistical process control to politics and economics. It’s a tool, once again, that we technologists have had to mature out of necessity. It should find wider use and acceptance. Because we ask ourselves this same question over and over again in business and life without realizing it. Can we identify which one thing, if changed, has the impact we want — what is a cause of change? If we’re serious about diagnostics in the rest of our world, we probably should be doing a lot more A/B testing in all kinds of places.

If you’ve read along this far you should follow me on Twitter!

Yes, I know about multi-variate testing. This article is meant just as an introduction to some of the general startup issues around statistics

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Friday’s Here! Time to Analyze Some Mother Goose

We all know the rhyme, but what does it mean?

Monday’s child is fair of face

Tuesday’s child is full of grace,

Wednesday’s child is full of woe,

Thursday’s child has far to go,

Friday’s child is loving and giving,

Saturday’s child works hard for a living,

But the child who is born on the Sabbath Day

Is bonny and blithe and good and gay

Remembering this verse, I did a little poking around the web this morning to learn more about it. Originally thought to be a Mother Goose nursery rhyme from the 1700s, as it turns out this little ditty can tell us a lot about our ancestors. It goes quite a bit farther back.

It was common for wives and older women to predict the fortunes of a child based on the day of the week they were born on. Most did this by rhyme, and there were dozens of such rhymes, of which only a few have come down to us intact. Because these go so far back, you can hear the old gods in the verse if you listen closely.

Monday – the second day of the week, day of moon goddess, Selene, Luna

and Mani. “Derived from Lunae Dies, day of the moon, the name reflects

the ancient observance of feast days dedicated to moon goddess or


Hence, “Monday’s child is fair of face”

Tuesday – the third day of the week, the day of Mars, associated with

Ares. Graceful and swift. “Tuesday’s child is full of grace” Graceful and swift in this context mean graceful and swift in battle, and some Tuesdays definitely feel this way!

Wednesday - the fourth day of the week, Woden (Odin), chief god of

Norse mythology, who was often called the All Father. “Wednesday’s

child is full of woe.” Odin’s responsibilities were such that he was

never attributed with any cheerful disposition.

“Woe” as used in the English language today is an expression of grief,

regret, distress, etc. (Every dictionary, take your pick, uses those

words to describe the word “woe”.) In the 17th and 18th centuries, it

was more an expression of deep concern, and heavy responsibilities,

and it has been suggested that “woebegone” might be more accurate; but

“woebegone” wouldn’t rhyme, instead we get “Wednesday’s child is full

of woe” You can also think of “woe” as just meaning Odin himself. Wednesday is full of Woe-din.

Thursday - the fifth day of the week, “… derives its name from the

Middle English Thoresday, or Thursdaye, corresponding to the Roman

dies Jovis. “Thursday’s child has far to go,” much like Thor, the only

god who couldn’t cross from earth to heaven upon the rainbow.

Friday - the sixth day of the week, named after the Odin’s mother,

Frigga (Roman equivalent Venus). Frigga means loving or beloved,

hance, “Friday’s child is loving and giving”. You can draw your own conclusions about the exact nature of “loving and giving” as it is intended here.

Saturday - the seventh day of the week, “corresponding to the Roman

dies Saturni, or day of Saturn, the Roman god of agriculture. Those

who worked the earth worked hard, hence “Saturday’s child works hard

for a living”

Sunday - the first day of the week. “From prehistoric times to the

close of the fifth century of the Christian era, the worship of the

sun was dominant. Sunday celebrates the sun god, Ra, Helios, Apollo,

Ogmios, Mithrias, the sun goddess, Phoebe. “But the child born on the

Sabbath day, Is fair and wise and good and gay.” Correspondingly,

sunny, fun, and loving – bringing joy to other people.

Here’s a version that’s believed to be a bit older. Note the changes in Wednesday, the elimination of Sunday, and the addition of Christmas Day.

Monday’s child is fair of face,

Tuesday’s child is full of grace,

Wednesday’s child is sour and grum,

Thursday’s child has welcome home,

Friday’s child is free in giving,

Saturday’s child works hard for his living.

And the child that is born on Christmas Day

Is great, and good, and fair, and gay

Finally, here’s more of a chant version of the same type of thing:

Born of a Monday,

·Fair in face;

Born on a Tuesday,

·Full of God’s grace;

Born of a Wednesday,

·Merry and glad;

Born of a Thursday,

·Sour and sad;

Born of a Friday,

·Godly given;

Born of a Saturday,

·Work for your living;

Born of a Sunday.

·Never shall we want;

·So there ends the week,

·And there’s an end on’t

Who knows? Maybe in another few hundred years there will be rhymes about what kind of person you are from your IP address. I hope not — IPv6 is going to be very hard to rhyme.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Tyranny of the Tools

As an agile coach, it’s been both a privilege and a pain to watch groups of extremely smart people blow themselves up.

The sad thing is that you can explain how this is all going to happen, you can plead with them not to head down this path, yet they do it anyway. What could have been a kick-ass team instead becomes a boring slog down old project management road.

And it all begins with automation.

That may sound strange. After all, we’re technologists, damn it. Our job is to take repetitive manual jobs and make the computers do them, right?

When I train people, we use post-its and index cards. We use painter’s tape on a wall. If we have a token for work that is to be performed — a story or a task — we jot a title down and plop it on the wall. This is called visual process control. It’s the result of decades of research and experimentation.

Or to put it bluntly, when my wife wants me to mow the lawn, she can ask, she can email, or she can make a bright red note and stick it on the refrigerator where I have to look at it every time I get a snack. Guess which one gets results. Make me look at it — even when I’m doing something else — and I’ll figure out a way to make it go away.

We find that things we look at — even in a casual, off-hand manner — are the things we think about. We also find that as we see things, we work on them in our mind in the background. We make a lot more progress letting our subconscious mind work on things while we’re busy with more important stuff, like technology development.

Still, there’s nothing like the gleam in a programmer’s eye the first time he sees a story/kanban board and physical risk/issue list. Note cards! On a wall! It’s like 1960 or something in here!

Then the gears start turning. Watching, I feel a terrible sadness, as if thousands of man-hours all screamed out at once, then were suddenly silenced.

There’s a reason why there are 40-thousand software implementations of Scrum/Agile on the web. Everybody who’s ever sat in a team room looking at the wall wanted to “fix” it.

Obviously a spreadsheet could handle all these lists and totaling up of things. And it’s not too hard to make a replica of a storyboard using some HTML5 and AJAX tools. Heck, given a few days, we could make a thing of beauty out of this — and make it easier to use too! Hell, I could be adding and completing stories on my iPhone! Taking some old, cranky, ad-hoc system using bubble gum and bailing wire and replacing it with a database and a decent front-end? This is the entire point of modern life! This is what we do! Why suffer?


So then — if we’re lucky — somebody does up a spreadsheet. Then everybody has to update the spreadsheet. Notice how the focus has moved. Instead of sitting in a room doing other things while the status of our project beckons us on the wall, we’re sitting in our cubicles filling out a spreadsheet once a day. The focus is on remembering to update a tool, not thinking about the status of our project. The tool starts running the project. It becomes the central source for finding out things. Not the people.

If we’re not lucky somebody writes a check for a more “powerful” tool. “Powerful” Agile tools usually have all sorts of fields, checkboxes, and whiz-bangs. They promise all kinds of benefits for teams — track your actual time! Track code changes against tasks! Roll up dozens of projects in a single bound!

So the job becomes completing the tool. Stand up? Well, that’s a reason to verify the tool has everything updated. Sprint closing? A detailed check to make sure the tool is in sync. Retrospective? A time to talk about updates to the tool. Do we need new fields? New reports?

It’s not us working the project. It’s us working the tool. Meanwhile, we still have the project to deliver. Agile becomes just another way to micro-manage and control.

Of course, I’m no Luddite. I love tools — as a means to communicate. There’s no better way to look at a team from a distance (when you can’t actually walk into their team room) than some sort of easily accessible online tool. So the team still works like it always has, using bubble gum and bailing wire, and each day somebody takes the stuff on the board and transfers it to a tool. The tool is never used except my remote workers as a way to visit the team room.

This is all just extreme fantasy on my part, of course. I’ve never seen a company that bought a tool that didn’t end up servicing the tool instead of actually being Agile. But I continue to hope.

There are people who love tools. These are the people who build them, sell them, or have a full-time job to maintain them. To them, tools are the answer to everything. How could you not love something that organizes so much data so easily? Weird thing — these people are also not the people who are actually doing the work.

When we create Agile teams, we create teams of real, live people. That means our control and communication systems must be built around the qualities and capabilities of people, not robots. We are doing much more in a team room than simply transferring abstract pieces of metadata around about a project. We are gaining a common emotional understanding of the problems and the players, getting a deep feeling for what might go wrong and what we need to worry about, adjusting our work patterns, our communication techniques, and our problem solving skills to this particular team, this particular problem, in this particular situation. There’s a hell of a lot of things that don’t appear on the walls — but that the walls remind us of. An Agile team isn’t a team that moves stories across a wall. It’s a team that looks each other in the eye and talks about things the Product Owner wants and how they’re going to give it to them. It’s a team that munches down on hot dogs and the conversation reminds somebody of something important so they reach up to add a new task on the wall. The stories, walls, and data are all just props to facilitate ubiquitous in-person human interaction. We take the ubiquitous in-person human interaction part out of it, we’ve killed the very thing we’re trying to improve.

If you’re looking for more balance and traction in your Agile team, take a look at the book I wrote on beign a ScrumMaster.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.