Prioritizing vs. Sequencing the Product Backlog

A primary tenet of agile software development is doing the highest business-value work earlier. The idea is that you achieve a minimal marketable feature set as early as possible so that a) you can issue releases earlier and b) if the money runs out, you have something more valuable than if you didn't sequence your work in that manner.

Another, less frequently cited agile tenet is to do the riskiest work earlier. The idea here is that you avoid late surprises when risky work turns out to be expensive. Better to discover this expense earlier.

When most folks talk about the backlog order, they refer exclusively to business priority.

I think ordering or sequencing the backlog must take more than just business priority into account. Yes, business priority is important, but so are a whole host of other factors, such as early exposure of risk. Balancing these factors is part of the art of project management.

Factors to incorporate into sequencing decisions:

• Business Priority
  
  
• Dependency Order: Despite our best efforts to decompose the backlog into independent stories, the fact is, the tension between the INVEST priorities sometimes cause us to define stories that are dependent on other stories.
  
  
• Mixture: The Rock/Pebble/Sand metaphor is helpful here. Consider a bucket at the beach. If you fill it only with rocks, you have a great deal of wasted space in the bucket, due to the space between the rocks. Though it may be unable to accommodate another rock, you may be able to slip in a handful of pebbles, to fill the spaces. Following that, you may be able to slip in some sand, to fill the spaces that the pebbles were unable to occupy. So it goes with an iteration. You don't want to fill your iteration bucket with only large stories, because you're losing the opportunity to slip in smaller stories. For example - if a developer finishes a story at 3pm on a Friday afternoon, you'd probably rather have him knock off a small story in the next couple of hours rather than start a large story.
  
  
• Crowding: Many advise that agile development teams define iteration themes. This is a good concept in theory, as it allows the team to focus on accomplishing a larger goal in the iteration. The risk here is that you have your whole development team working in the same parts of the code base. This can merge issues as the team commits code to the code repository. Consider the source-code crowding problem when sequencing the work.
  
  
• Risk: As mentioned above, the earlier you schedule the risky elements of the project, the more insight you have into your completion date. One element of risk is embedded in non-functional requirements. For example - if you have performance or scalability requirements that are risky, it's better to implement the stories that are sensitive to those requirements earlier.
  
  
• User Feedback: If you have elements of the software for which user feedback is critical to making the right decisions, schedule this work earlier. If you delay these features towards the end, the need to change the system in response to the feedback becomes a schedule surprise. Worse, if you decide not to incorporate the feedback in order to make your date, your users are not just unhappy; they'll feel that their input has been ignored.
  
  
• Exercise the architecture: Scheduling the highest business value work first may avoid elements of the architecture into later in the development cycle. For example, perhaps the "happy path" of execution is deemed the higher business value. This might delay consideration of elements of exception handling to the end of the release. First pass implementations within an architecture are always riskier, and could introduce schedule surprise. It is wise to exercise all elements of the architecture as early as possible.
  

As I mentioned, these factors are often competing. The context of your project defines which of these dimensions are more or less important. Yes, do the highest business value work earlier, but don't forget to consider these other factors as well.

The case against iteration based re-estimation

Many agile practitioners recommend re-estimating stories at the beginning of each iteration. I disagree with this practice.

For one thing, I believe it's a waste of time. Any value that you might get (which I doubt - see below) from the practice is lost on the time spent.

It's worse than that though. By re-estimating the iteration's stories, you are almost always estimating with a greater level of detail than what you had originally. With this increased level of detail, in my experience, estimates tend to grow.

Why is this a big deal?

Let's try an example.

I come in to my iteration planning meeting with 30 points worth of stories from the backlog. The team commits to those stories, but in re-estimating, the 30 points inflates to 40. In fact, this always seems to happen, as the team gets a little nervous about hitting their historical velocity and they know management is paying attention. Let's assume the team gets them all done. This increases the observed velocity by a third (40 points is a third more than 30). Now, let's say I have 120 more points left in the product backlog to get to the minimal marketable feature set for release. How many more iterations are left?

If you said 3 more iterations (i.e. 40 points per iteration gets you to 120), you are ignoring your team's tendency to inflate estimates. Assuming your estimate inflation rate is consistent (a third), you really don't have 120 points remaining, you have 160 points, or 4 more iterations remaining. Or, calculated another way, if you consider only the initial estimates to calculate your velocity (30), then you can determine that you have 4 iterations of 30 remaining. In both cases, you end up correctly predicting 4 more iterations. Then again - if you use the initial estimates, what value did your re-estimation from 30 to 40 provide you ? I say none.

If you regularly re-estimate at iteration planning meetings, make a note of the original vs. the updated estimates. See if they grow. Consider what impact this is having on the accuracy of your release planning.

OK, I can hear you now. "My team's estimates don't inflate ... some go up; some go down". I haven't seen this, but let's say you do. Let's revisit the example from above with this assumption. You go into the iteration planning meeting with 30 points and walk out with 29. Your velocity is not materially impacted. You are still on track with 3 remaining iterations (roughly). So the question is this: what value did that re-estimation provide? I say none.

When *do* you re-estimate then?

I believe in updating estimates when information arises from experience that pertains to some shared aspect of a subset of stories. For example, let's say that your retrospectives have shown that every time you have a story that hits a certain database, it ends up being much more effort than expected. In a case like this, it makes sense to revist those database stories to ensure that this knowledge is incorporated into those estimates. I call this aspect-oriented re-estimation (adapted from the term "aspect-oriented programming").

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)

Iteration Length

What's the right iteration length?

In Scrum, the recommendation is to start with thirty calendar days. From the Schwaber/Beetle book: section 3.6.3 Sprint Mechanics:

"Sprints last for 30 calendar days" and "thirty days is an excellent compromise between competing pressures". Though "Adustments can be made to the duration after everyone has more experience with Scrum".

My first reaction to the number 30 is that this is a nonstarter. What happens when your sprint boundary occurs on a weekend? How do you schedule sprint transition meetings? I know of no calendaring program that schedules meetings "every 30 days". Monthly? Yes. Every n weeks? Yes. But not every 30 days. The organizations I know that have implemented scrum by the book have scheduled n-week sprints, in order to maintain a consistency of scheduling (e.g. Wednesday afternoons are for sprint reviews).

Many novice scrum practioners resort to quoting "the book" when arguing for 30-day, by which they mean quad-weekly (which I will hereafter refer to as monthly for terseness) sprints. Suggestions to shorten sprints (e.g. to 2-weeks) yield objections along the lines of "with twice the meetings, we'll have less time to get work done. We already spend two days in our sprint transition meetings"

First of all, if the team is spending two days on monthly sprint transition activities, something is very seriously wrong. Really.

Sprint reviews (or showcases in the more generally accepted agile lingo) are about showing working software. They should not be about burn-ups and burn-downs and justifying the team's existence. You should never find yourself in a showcase/sprint review talking about the percentage completion of a story. Show the working stuff or sit down.

If you follow this pattern, the showcase/sprint review length should be proportional to the length of the iteration. If your iteration length is cut in half, your showcase should take half the time. After all, you're only showcasing half the functionality! (OK... maybe it's not exactly half. I would argue that two week sprints are more productive than monthly.)

Iteration planning should be a no-brainer. Preparation for the sprint planning meeting is on the business analysts, product owner, scrum master, project manager... everything should be pretty well layed out in advance. It should take no longer than an hour to do an IPM (iteration planning meeting). Unless, of course, you feel that task breakdown is necessary during the IPM (another Scrum approach with which I generally disagree). In any case, the IPM length should be proportional to the length of the iteration.

-begin sarcasm- How 'bout a 3-week iteration? Wouldn't that be a reasonable compromise? -end sarcasm-

Sprintly Retrospectives are another issue. Can you halve the time spent in retrospectives if you halve the iteration length? Probably not. But this, I feel, is not the right question. Are you getting value out of your retrospectives? If not, figure out how to get value. You don't necessarily need all the typical pomp and circumstance of a full-blown retrospective to impart the "adapt" portion of the "Inspect and Adapt" mantra. Too many teams, in my experience, adhere to the scheduling and process of retrospectives without digging deeply into different ways of adapting the team's approach to being effective and efficient.

More advanced teams can consider whether iteration ceremony is even necessary. A more lean approach would be to consider the flow of the work and to simply feed work into the development "machine" at a rate at which it consumes the work. "Inspect and adapt" would be continuous; retrospectives would focus on specific issues or areas of concern (rather than specific time periods across which many different kinds of issues may require attention). Classic iteration planning would yield to on-demand prioritization and estimation exercises - delayed to the last responsible moment. Reviews of completed functionality would be scheduled on demand for individual stories and perhaps with more ceremony when a critical mass of functionality has been completed.

What's the right iteration length for you? My recommendation is 12 days, 6 hours, and 24 minutes. (Oops... forgot the sarcasm tag)

Non functional requirements - a tale of two cities

I've been thinking about non-functional requirements lately. Ilities, some might say. It occurred to me that there are two classes of non-functional requirements: those that are visible to the user and those that are hidden.

Performance and usability are examples of non-functional attributes of the application that are visible to the user. I classify these as being "in front of the curtain"... or "part of the performance" (to use theatrical terms). Though attention to these issues is sometimes delayed to the end of the release, they occupy a high level of importance in delivery priorities.

Other non-functional requirements are backstage, and pretty much lead to efficiencies (or inefficiencies) for the development team. Examples include testability, supportability, maintainability and extensibility. These non-visible requirements bleed into visibility in some sense... for example, extensibility problems lead to delays in releases which impact follow-on release timelineness; poor testability leads to gaps in test coverage, which leads to bugs. But the impact of these issues often occurs long after the "current administration" has moved on.

I suggest that the order of priorities can be interpreted as 1) functionality, 2) speed of delivery, 3) visible non-functional requirements, and 97) non-visible non-functional requirements. Speed of delivery takes precedence.

Beware the "speed smell": sacrifices at the alter of speed, to the detriment of long term health of the system. In particular, beware these sacrifices being made by an administration that is poised to move on.

Wanted: Software Development Leader

One thing led to another and there I was contemplating the job req for what I would look for in (and what I strive to be as) a software development leader.

Experience:
- Development experience - preferably within the last decade

Aptitude:
- Can tell a crappy architecture from a sound architecture
- Can tell a crappy implementation from a sound implementation
- Can tell the difference between someone who is busy and someone who is productive
- Can discern the difference between a good candidate for a position "on paper" and a good candidate for real
- Demonstrates a deep understanding of what quality means for a software product (including non-functional requirements like performance, supportability, and extensibility)
- Can tell when an architect, developer, QA, BA, or business partner is blowing smoke up his hind quarters
- Can speak the dialect of business - ROI, NPV, customer acquisition cost
- Can relate to business stakeholders and build collaborative relationships
- Can connect to team members on a personal level
- Has a good sense of humor
- Understands the difference between a prototype and a production application

Attitude:
- Will call out a crappy architecture and drive change
- Will call out a crappy implementation and drive change
- Will call out the busy-bees and the smoke-blowers
- Will demand demonstrable quality (including non-functional requirements)
- Will demand reasonable tests (unit tests, component tests, system tests)
- Does not suffer fools gladly
- Will not sit through a PowerPoint that depicts supposed progress without demanding demonstration of said progress
- Will not abide bubble gum and duct tape solutions to production (or development) defects
- Demands continuous improvement
- Demands root cause analysis (5 why's)
- Demands customer involvement in product development
- Continuously seeks to improve efficiency by asking "why" and "how can we do this more efficiently" (e.g. - PMO requirements for excessive documentation)
- Is willing to fight for the resources required by the team to deliver
- Cares deeply about the team
- Cares about the career development of team members
- Cares deeply about product quality
- Will celebrate true success with the team (no gratuitous applause please)
- Will always give credit to the team for success
- Will remove team members when necessary
- Has a coaching mentality
- Is willing to get hands dirty (writing code, writing/running/debugging tests, fetching pizza)
- Is always available to the team
- Exhibits patience, when appropriate
- Exhibits impatience, when appropriate

Integrity:
- Tells the truth - for instance about project status
- Is clear to team members on expectations and performance on a regular basis (not just at review time)
- Is willing to stand up and fight for the team

Ah... it's late. that's as far as I got. I felt like the integrity section was short, but many of the integrity issues bled into attitude. What did I miss? What do you disagree with?

Halftime

In American football, the game is divided into four 15-minute quarters. There's a short break between the first/second quarters and then between the third/fourth quarters, but the middle transition is longer. It's called halftime.

During halftime, teams return to their locker rooms for respite, but more importantly, coaches use it as an opportunity to adjust the game plan and motivate the team.

Much is made of the halftime break in football. I think the concept is equally useful in ... agile software development.

I introduced halftime on a couple of agile software development teams to step back and look at iteration (or sprint) goals at the midpoint of the iteration, to see where we stand, and adjust our approach. It has been a good opportunity to refocus, adjust sprint content, and address issues.

In a recent halftime, I pointed out that the scope for the iteration was 63, and that we had burned up 20 points. I used the analogy that our opponents had 63 points and we had 20 and that we need to figure out how to make up the difference. We adjusted our approach, removed some scope and went on.

If you're stuck in a project where the iterations are too long (e.g. four weeks), suggest introducing a short halftime (30 minutes) to refocus the team and adjust. Even if you're in 2-week sprints, doing a checkpoint/halftime at mid-iteration can be useful. It's also a good segue into shorter iterations.

The "Z" Word

Zealot: A fanatically committed person.

Hmmm... good or bad?

It suggests an unfavorable hue to me. I've seen this word used before to describe folks' commitment to a particular technology platform. He's a .NET zealot, or a Ruby zealot, or Zope zealot.

In the case of technology (most cases?) zealots prefer their approach/solution to all(?) others. For instance, how could you turn back from having written significant code in Ruby to doing plain old Java? Those who aren't writing in Ruby have simply not yet been shown "the way".

I consider myself fairly pragmatic and reasoned, but I seem to have acquired the dreaded tag at work. My zealotry is in an agile approach to software development. (English zealots - note the use of the article "an" vs. the article "the" - it's an important distinction).

I'm measuring whether I should shrug the label off, welcome it with open arms, or fight it. Actually ... that's not quite accurate. I'm pretty sure shrugging it off will not be my chosen response.

At some level, I feel it's like being called a "rationality" zealot... or a "damned common sense practitioner". I'm a "Sunrise Zealot" damn it ! I find the agile manifesto chock full of common sense. (OK, here I see... manifesto => zealotry... maybe if Kaczynski and Marx hadn't also used the term manifesto we'd be in better shape).

Some software development professionals unabashedly promote a "waterfall" approach using a document-centric "SDLC" lifecycle. Templates are created to capture every known aspect of the project. Stakeholders are forced to "sign off" on documents, which form a contract-like agreement to what will be delivered. Of course, a change request process is included, which affords the opportunity to create change documents which are then signed-off.

Agile is not binary... agile is a continuum. There are agile development techniques and agile project management approaches. You can use any of them - or not. The use of one technique does not an agile project make.

Agile, chunked up, (to me anyway) is about focusing on the delivery of quality software over and above delivering service to a process. The customer is not a color-copier and a list of signatories to a spec. The customer is the user of the software; the organization that benefits from working, functional, valuable software. No organization prefers reams of documents over working software. And those that argue voluminous documentation better leads to working, functional, valuable software should start measuring the extent to which those documents are implemented as stated. After all, not many approaches refine their processes to eliminate waste (ala Lean).

One should question the value of accepted process (using the Five Whys, for example) in order to assess the usefulness of documents and other artifacts to ensure they stand the test of reason.

OK, my writing therapy is done. I hereby embrace the label "Agile Zealot". I also accept the following additional labels: "Fatherhood Fanatic", "Beer Lover", and "Education Enthusiast".

I do like the alliteration angle though... may I please be an "Agile Aficionado" instead? Ah, but perhaps that doesn't quite capture the intensity of my rapture.

Dope a rope

So you're on a team using all of the agile techniques (please don't say methodology). You're pairing, using TDD, daily standups, etc. You have the maturity to understand (or you've been on the other end too many times) that micromanaging doesn't work, but you want to keep a close eye on one of your team members; the code she writes often ends up being less than healthy. In fact, it sometimes is beyond refactoring and needs to be rewritten. You'd rather she not spend a great deal of time going down ratholes. What do you do?

Rotate pairs often. This is a stealthy/healthy way to keep fresh eyes on the problem. It's the classic agile way of spreading the perspective around.

Dope a rope. This is a technique I use sometimes to be welcomed into another developer's sandbox. "Dope"... means I express ignorance (maybe too strong a word) about what he's doing and ask 3rd grader type questions. (Easy for me now - as I have no developer credentials on my current project and am acting as a project manager). I ask for explanations that lead the developer to "throw me a rope" and pull me into the code to show me.

What is the result? The developer sees that what he's doing matters (because I'm paying attention) and feels confidence (after all - he knows more than me). I get an opening to subtley convey suggestions for improvement. And I usually learn something.

Cram First

CRAM First

CRAM is an acronym that represents a model for dealing with workplace performance. I first heard it in business school – in my Managing People and Organizations class. It resonated with me at the time and has endured the test of time: 7 years beyond graduation. How much do you remember that long after school finishes?

The natural reaction to underperformance of a team member is to blame it on motivation. “He’s lazy” or “She’s just not applying herself.” While this reaction may be accurate, there may be other more substantial issues that render the motivation issue irrelevant. This model can help to “peel the onion” to find more basic issues related to performance.

To the point: C = Constraints; R = Resources; A = Aptitude; M = Motivation. Think of these as cascading (or – like Maslow’s hierarchy of needs – a pyramid).



Constraints: I have been divorced twice. The first time I got separated, I was working at IBM on mainframe operating system development. I was on an elite team doing cutting edge development – writing software that translates service-level-agreement objectives into algorithms that adjust resource allocation within the system to achieve performance objectives. It was complex work and demanded a great deal of concentration.

When my personal life took a dive, I would – literally – sit in front of the computer screen and stare at it. I felt like a zombie. Though I knew that I was falling behind, I didn’t want to – no, that’s not right – I didn’t care about raising a flag to indicate that I was in trouble. I’m sure I experienced aspects of clinical depression. I finally spoke to my manager. He moved me onto a less complex part of the project, where I flourished. I was fortunate that my prior performance provided evidence of my capability, so my manager was able to understand the impact of my personal issues.
So ask me – was I motivated? I don’t know. I didn’t care. My issues were more foundational – my motivation was irrelevant. Ask a homeless person if they are working on self-actualization.

Resources: In this day and age, why doesn’t every developer have a big flat-screen monitor on which to work? Why don’t they have 2-gig systems (or more) with dual-core multiprocessors to speed their work? Understand that the more lag time there is between tasks, the more start/stop energy that gets expended by thrashing. If my build takes 4 minutes, and I start looking at cnn.com in the meantime, I’m losing my concentration. Nobody can be expected to maintain concentration over this time.

I run meetings where I need a projector. Management decides to purchase one projector to share among 50 people – to save money. Consider that I’m costing you $150 an hour… so every 10 minutes I spend hunting down, or reserving the projector costs you $25. Moreover, I’m losing concentration on the tasks I could have been performing.

Administrative assistants provide incredible leverage for productivity. I spent an hour recently reserving rooms for a recurring daily meeting using a terrible Lotus Notes conference room scheduling implementation. You can hire great administrative assistants to do this at a much lower cost. Think of me (and other high-tech workers) as expensive pieces of machinery in your manufacturing plant. To optimize your profit, you need to keep your expensive pieces of machinery at optimum capacity. Don’t eschew paying $50 an hour for a maintenance person who keeps a $1,000 per hour piece of machinery humming.

Aptitude: I had a good friend/colleague at IBM once who was extremely bright. He had (presumably still has) a quick wit, a great attitude, and could solve some complex problems with ease. He had a master’s degree in Mathematics. Unfortunately, he was working as a programmer. He wasn’t a great programmer. He was eventually managed out of the company. To this day, it bothers me. I was his team leader, but I was young and had no leadership sense. I was timid. I wanted to get along – climb the IBM corporate ladder – become CEO someday. My friend was not a poor employee; his best skills were simply not being leveraged. He would have been an outstanding software performance analyst. To this day, when faced with seemingly incompetent people, my experience tells me to look for where the aptitude lies. That person may not be shining in his current role, but may be brilliant in other areas. Let’s find the areas where we can all be brilliant.

Motivation: Some people are lazy, unmotivated – whatever. There are reams of books on motivating people – particularly in the sales arena. I’m sure some of these tactics work. But motivation is irrelevant when deeper issues exist. Don’t be lazy in managing these individuals. Figure out if there are more foundational issues to address before giving your next motivational speech. CRAM first; motivate later.