"Strategery!"

Time for an introspective look...

Being vaguely aware of the difference between strategy and tactics I decided to learn more. And in learning more, it's clear that I'm a strategist. Further more, I'm not much of a tactician, and I think it's because I attempt to apply strategy to tactics. Let me explain:

By my nature I'm an observer.

I'm always observing,

In my observations I'm looking for patterns,

Then matching observed patterns to previously discovered pattern,

And using those patterns to determine possible outcomes.

...sounds like typical strategy stuff.

However, observation is a passive activity and successful tactics require action. I keep wanting to apply strategy to tactics and it doesn't work. What's needed to apply successful tactics is execution.

The old Nike commercial says; "Just do it." By contrast my commercial would be "Just analyze it."

Here at Devlink in Nashville

So far the best session has been the informal experts panel that was held during lunch. Some gems came from the guys on the panel.

After 33 years of changing technology knowing a methodology and language are secondary. More valuable skills are are;

• the ability to solve your problems...agiley
  
• understanding business domain problems and mapping them to the code (ie: developers are no longer coding in a silo, you've got to understand the solutions's "what" and "why")
  
• (not really a skill, but I loved this...) subersively sneak Agile principles into an organization (a great story about a continuous integration server hidden under a developers desk)

Really cool stuff.

The simplest measure of value

Jack also brought back this very simple equation from PO Certification.

Business value = Business visibility

Use 'point' estimations only to a certain 'point'

My buddy Jack went to Mike Cohn's Product Owner Certification class. He returned with this great analogy providing the context for "point" estimation and "hour" estimation.

If 2 runners of varying skill are asked to estimate the task of running a fixed distance; the faster runner might say, "that looks like a 15 minute run," where as a lesser runner might say, "no, that's a 30 minute run."

In making disparate time estimates (of the same task) the runners have demonstrated the value of point estimation. Ask the runners to measure the task in terms of points (lets say 1 point equals 1 mile). Now the runners can agree "Yes, that looks like about 2 points." Using points they reach consensus and provide the PO with a sufficiently high level estimate to assist in prioritization and pre-planning.

However, when it comes to sprint planning, start moving from points to hours (this is new from Mike). Like in the case of our runners, the hour estimate is useful in helping the team plan thier work for the sprint. If one runner is faster than another this may help the team members to adopt the tasks they best suited for.

Adaptive Sampling, you're doing it and don't even know it.

Alistair's article of adaptive sampling make a good point about quality not needing to be uniform:

"... First of all requirements statements aren't requirements, they are only placeholder tokens for [need-solution] pairs. Secondly, the system doesn't have a single quality requirement, the quality characteristics vary by [need-solution] pairs. We can save time and money on the project by examing each "requirement" (or wish, or user story, or backlog item) individually, and working out what the appropriate level of effort will be needed at that one spot. We can save time and money in that endeavor by using [this] adaptive sampling idea and breaking the work into areas, those with similar quality needs..."

Stretch Tasks

In Kelly Waters' "All About Agile" blog Kelly says: "Include a bit more than you think can be achieved. It's important to prepare more items during planning in case the team finishes early. These items can be clearly identified as stretch tasks and the Product Owner should not expect them to be completed. These are the things you will only do if the Sprint goes better than you expected."

A great quote

I found this valuable quote in the Introduction to the Eclipse PPT. It's by Alfred North Whitehead, a 19th Century British mathematician, logician and philosopher.

"...by relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect, increases the mental power of the race."

Agilists at Graffiti labs

Here Bre Pettis hosts Michael from Graffiti Reasearch Labs, Vienna. Michael expands on a traditional Agile mantra saying "...release early, often and with 'rad' music..."

No more "done"

I dislike the word "done" because the defenition can be so subjective. For instance, my idea of "done" may not be your idea of "done." Instead of asking "...is it done?" I would prefer we ask "...does it perform?"