Squirrel Agile

A client shared this term a few weeks ago that I really liked: Squirrel Agile. Thanks Steve.

I'm sure you've seen a squirrel trying to cross a street. The squirrel starts off on one side of the street, looks, darts out, then sees something scary and retreats. Sometimes he retreats all the way... sometimes he just stops in his tracks. When he starts again, he may continue trying to cross, or may high-tail it back to the original side of the street.

In agile adoption, we sometimes see fits and starts... and retreats - just like the squirrel.

One aspect of agile adoption - self directed teams - seem to me to suffer a great deal from this behavior. Management agrees to self-directed teams in principle, but as soon as the manager fears loss of control, or loses confidence in the team's ability to deliver, the agile squirrel darts back towards the original side of the street. The command-and-control tendencies return.

Other fits and starts occur when you start taking shortcuts in your approach. "We don't need to do a showcase this iteration; we don't have much to show". Or "We're 98% complete with this story - let's take credit for the story in our burn-up, since we'll finish it quickly at the beginning of the next sprint." I'm sure you can come up with other examples.

These behaviors mirror the squirrel's fear. These short-cuts and adaptations are typically not to improve effectiveness or efficiency, but reactions to fear of judgment. My suggestion: rather than darting back and forth as you cross the road, take a deliberate approach with courage.

agileshout

I just recently discovered this StackOverflow implementation focused on Agile issues: http://agileshout.com. Seems to be low traffic at the moment, but perhaps my agile friends can find some value there.

I'm not quite sure why it's necessary to have a separate site from StackOverflow, since the tagging mechanism in StackOverflow permits differentiation of topics (e.g. "agile") and cross tagging of topics (e.g. "agile" and "BI") that might not otherwise find a specific home on a specific site.

Task breakdown - To do or not to do

I've had this conversation with agile folks over the years. It's about task breakdown. This is not entirely fair, but I'll say it anyway: I consider it one of the "thou shalt" approaches of agile by the numbers... or by the tools.

Assume a master story list with estimates based on points.

The iteration planning meeting (IPM) looks like this:

Foreach Story in Candidate list:

• Product owner: Describe the story
• Team: break the story down into tasks
• Team: estimate the effort for each task in hours
• Iteration Manager: Increment the task hours counter by the amount of the task hours for this new story
• Iteration Manager: Measure the task hours against the team's ideal capacity and report how full
• Team: If iteration is full (based on ideal/actual capacity) leave foreach

As the iteration progresses, we see this:

Foreach Day in iteration:

• Team member: update the remaining task hours for each of his/her tasks
• Iteration manager: udpate/publish burn-down
• Iteration manager: interrogate team members whose tasks are moving "slowly"

There are some benefits to breaking work down into tasks:

• Intra-story progress can be measured by the iteration manager who can address slowness ("John: you reported 2 hours left yesterday morning and today you're still not done... what's up?"
• The aggregate burn-down should show you how close you are to your target on a daily basis

My issues with this approach:

• Tasks become the center of the reporting universe within the sprint and so progress against task completion may mask poor progress against story completion (e.g. due to undiscovered tasks)
• Team "feels" progress based on completed tasks, rather than on the real objective: completed stories
• Weird reward structures get created ("John - yesterday you said you had 12 hours remaining on the task, yet you finished it. Great job!")
• Weird negative feedback is inferred ("John - yesterday you said you had 2 hours left and you're not done yet": inference - you're not working hard enough)
• Daily reporting requirements implies distrust of the team to raise issues or problem: "If I don't keep an eye on the task level reporting, I can't hold them responsible on a daily basis"
• Estimating iteration capacity based on ideal task hours may conflict with iteration capacity planning based on historical velocity. What happens if my hour capacity is reached in the IPM, yet my booked story point total is below my historical velocity? (I'll save the tendency for re-estimation for another blog entry). Reminds me of the old adage - experienced sailors never go to sea with two compasses. They go with one or with three, because if the two disagree, you have no idea which one is right.
  

I feel that task breakdown should be done only in limited circumstances and only to the degree where the benefit outweighs the admin cost:

• if the team feels that the benefit outweighs the cost
• if a developer or pair needs to break the story down into tasks in order to understand the work to be done, go for it (but don't worry about tracking all the details in a tool)
• Perhaps if your team is not mature enough to understand how to break down a story into tasks, and so you must spoon feed them with tasks (even then, I think it better to have them pair with experienced developers to learn how to become self-sufficient.)
• If the tasks to implement a story can be parallelized (different developers or pairs can be working on different tasks for the same story in parallel)
• If your team has "silo dysfunction" that requires choosing stories that don't overload a skill or domain area on the team

Example: let's say you have a project with equal parts C++, Java, and Fortran code and you have C++, Java, and Fortran programmers who can't span technologies. In order to keep from overloading one technology group, you must choose stories that balance the work across those silos. Sometimes, the only way to create this balance is to task out the work across technologies, to ensure you're not overloading one camp.
By the way - removal of this dysfunction over time is recommended.

My feeling: Using the whole team's time in the IPM doing task breakdown and estimating tasks is usually wasteful. I recommend that task breakdown be undertaken, if necessary, at the last responsible moment... when the story moves from "ready" to "in development", rather than at the IPM. The developer or pair picking up the story should do the breakdown.

Task breakdown smells (and yes, I've seen them all):

• The tasks look like this:

Design the code
Write the code
Write the unit tests
QA the code

Why is this an issue? You're probably doing mini-waterfalls, not simple, evolutionary design

• The "remaining work" for a given task is reduced by 8 hours (or perhaps 6) each day

Why is this an issue? Team members are not providing real data, they're telling the iteration manager what he/she wants to hear

• The hour-based iteration burn-down (or, as I prefer, burn-up) is practically a straight line.

Why is this an issue? In reality, many things take more or less time than imagined. Straight lines are an indicator of "cooking the books"

• The iteration manager asks people throughout the day... "How many hours do you have left on this task? When will you be done?"

Why is this an issue? It's command and control leadership and dilutes the power of the self-directed team.

• Iteration Planning Meetings (IPM's) take more than an hour and are more about numbers than about story understanding

Why is this an issue? You spend more time taking swags at hour estimates than you do actually thinking about the functionality to deliver

• The iteration manager applauds the team for accomplishing "400 hours" when their calculated capacity was only "350".

Why is this an issue? It's focused on task hour accounting and doesn't imply anything about how successful the team was at completing stories

I've worked on projects with both approaches - task breakdown with hour-based burn charts and no-breakdown with point-based burn charts. My suggestion is to avoid speculation about the superiority of doing it the only way you've ever done it and at least give each approach a fair shot.

I remember my elevated caffeine intake as a developer at interminable IPM's where I just wanted to get on with the work.

I remember debating minutia about whether a task belongs or not, and whether it's 8 hours (by Kurman) or 16 hours (by someone else). Yes - all those issues that the point-level estimating deigns to abstract by using relative estimates can rear their ugly heads in hour-based estimating. (By the way - if your solution is to assign the tasks at IPM time, you'll suffer from other problems).

I remember being the first to pick up a story as a developer and finding a better approach that implied a totally different task breakdown. Yes, I used the new approach, and yes I had to fix the accounting (XPlanner) to reflect my new approach. (Umm... on second thought - I just left the existing task list in place and fudged the actual hours into the old list. You might think this was wrong. I knew, however, in my heart of hearts, that the micro-accounting really didn't matter).

I've also worked with teams that have eliminated task breakdown/estimates and felt freed by the defenestration of the bureaucracy.

This tends to become a heated topic of conversation. In the end, the best answer, I think, is to let the team choose the approach that's right for them. Mandating task breakdown or mandating against it is almost always wrong. Drive the questioning to determine if task breakdown adds value or not, and try it both ways. If you have an agile management tool that requires tasks in order to do reporting, and you want to avoid defining tasks, just create one task per story that says "Do it". (In parallel, find a different tool that provides more flexibility).

scrum terminology decoder:
iteration = sprint
iteration planning meeting or IPM = sprint planning meeting
iteration manager = scrum master
iteration showcase = sprint review = sprint demo
master story list = product backlog (or possibly release backlog)

PMO vs. PPM

I have a visceral negative reaction to the PMO initialism; it stands for Project Management Office. I recently pounced (in an overreacting sort of way) on a colleague who was using this term. Sorry Carl.

I need to explain a bit. It's really all about the "O" - for Office.

"Project Management Office" screams bureaucracy to me. I've never seen an efficient and effective PMO. This is perhaps because most of them seem to be mired in "SDLC" - an oft-used euphemism for "waterfall" (despite it's innocuous spelled out translation: software development life cycle).

I once had to sign off on a 19-page document provided by the PMO to justify the acquisition of two load balancers for a test environment. This document had to be signed by 25 people in a 2000-person company. It was a stunning example of the need to feed the process beast. Some project manager in the PMO - who probably thought this process was necessary - filled out this template. My favorite section of the doc was "Metrics". Ostensibly this section existed to establish the metrics upon which the success of this project would be measured. The PM filling it out, indicated that 2 load balancers would be acquired - as if the number "2" satisfied whatever the template providers had in mind for metrics.

If we want to revamp the bureaucratic, inefficient, ineffective approach currently used for managing software project portfolios (the PMO), I think we need a departure from the term.

I'd love for us to agree to focus on the verb - not the noun. A brief digression:

I see many agile teams who use the iteration planning meeting - IPM - or the "sprint planning meeting" if you subscribe to that religion - as the only time in which the development team is exposed to upcoming work (other than, perhaps, estimation efforts that occurred months ago). I coach teams to treat iteration planning as a "verb": planning - rather than a noun: meeting. The "planning" should occur fluidly - some done in meetings before the IPM (e.g. estimation), some after (e.g. task breakdown).

Project portfolio management (the PPM in the title of this post) implies active engagement in assessing the health of the portfolio. The estimated release date or feature list should be adjusted after every iteration, and approaches need to be introduced to raise awareness of the new projections at least this often.

Let's please talk of project portfolio management, rather than project management offices.

97 Things Every Project Manager Should Know

The book "97 Things Every Project Manager Should Know" has just been published. I have two contributions: "Use a wiki" and "It's the People Stupid". Get 30% off by entering the code ABF09 on the oreilly.com site.

Linked-In grammar issues

John Doe "has added new links and updated their profile"

John Doe is an individual. "Their" is plural. I understand they're trying to avoid "his or her", but I'd prefer it.

Another example... when someone requests an endorsement, the message comes across as "Can you endorse me?".

The word "can" implies ability to do something, not willingness. I'd much prefer to see "Would you endorse me".

There. It's off my chest now.

Why Blog?

I recently had an extended conversation with a group of about 10 folks who lamented the poor understanding of the value their particular functional role brings to a software development team.

One question I posed: how many of you blog on the topic of your profession? The answer was zero.

Why don't they blog? Here is my interpretation of the reasons for not blogging:

• Not enough time - working 40 to 50 hours per week leaves little extra time to spend composing and presenting ideas in a professional manner, much less having a reasonable social life.
  
• Lack of original ideas - there's not much I can think of to write about that hasn't already been addressed somewhere - whether in another blog, in a book, or in conference presentations.
  
• Confidentiality - many of the examples from my work are proprietary; obfuscating the details takes time and can cause loss of message fidelity.
  
• Low readership - the effort to reach a small number of readers, given the size of the blogosphere, has a low RROI (readership return on investment?)
  

My blogging is sporadic. I understand the effort required to wrap ideas in a digestable format. I also edit articles for an online IT journal (alphaITJournal.com). Editing is hard work. Blogging doesn't require the depth of perfection that articles do.

Sometimes you're better off taking a stab at it and clarifying the concept through further blog entries than simply waiting to start.

Who reads my blog? According to Google Analytics - about 15 - 30 people. That's the volume of hits I generally get with a new post. It's not much, but size isn't everything. Every once in a while a link to your post will get posted to an aggregate someplace (digg, reddit, Developer Zone, etc.) and will generate more traffic and conversation.

The benefits to blogging:

• Personal brand promotion. As your blog is read by others, your personal brand improves.
  
• Clarifying thoughts. Organizing and writing about a topic forces you to develop clarity on your topic.
  
• An idea portfolio. When you apply for new jobs or try to sell to new clients, your blog serves as a portfolio of your ideas and promotes your depth of thinking on your profession. It also serves to show off your communication skills.
  
• Writing skills. Most of us need to communicate through the written word in our lives. Blogging is great practice.
  

Here's a technique I use to generate blog entries. Whenever I get an insight or a flash, I start a blog entry in a text file. Sometimes it's just a thought (one file - pragmatism.txt - has the following: "Pragmatism vs. agile").

When I have down time (waiting in the airport, sitting on a plane), I take a look at my partials and figure out what I'm in the mood to explore. I happen to be on a plane as I type this.

Your topics will rarely be entirely original. What will be original, however, is how you shape your message with your unique perspective and background. Combining this uniqueness with the topic at hand is what renders insight.

Low readership is not an issue. The benefits of clarifying your thoughts, having an idea portfolio, and improving writing skills are all independent of the size of readership.

So go ahead and start. Create a blog and type "Hello World". You may be surprised at how the ideas start flowing. Start recording things you want to explore ... and start blogging !

Uncle Sam Industrial Average

With GM and Citigroup being removed from the Dow Jones Industrial Average stock index, it occurs to me that we need a new index to track the health of government owned/quasi-owned companies. We should be able to come up with 30 by now, no?

I propose the Uncle Sam Industrial Average (USIA).