I had a great conversation with a key client yesterday. We realized that
we had been talking about a product release strategy for almost three
months, without being aligned. Yet for three months we agreed with each

When we realized that we did not understand the same things from our
discussion, we had a better release strategy discussion. Each of us heard
the other more clearly – once we stopped talking “at angles”.

It is truly important in our conversation to “square off”. To make sure
that all are thinking the same way. We both realized that we had missed
signals, and overlooked things in e-mail, presentation decks, and documents
that were obvious. Each of our own viewpoints allowed us to overlook facts
that clearly showed that we did not understand the same thing.

Unfortunately this happens frequently because of the imprecise nature of
human communication.

Fortunately, this time we revealed it before any real negative impact was
realized – either to the project or our relationship, which is now stronger
because we solve another issue together!


Today I realized that the entrepreneur in me is stymied by enterprise level
bureaucracy I work in. I send 5 ninjas to assassinate Putin and he sends
the red army to lay siege to my town.

I step on the gas pedal, accepting the risks, while the entire management
hierarchy stands on the brakes, so none of them get hurt.

I get in the car to go to the grocery store, and they insist on paying for
a tune up and oil change each trip – I better really load up the car!

I think I am a good corporate citizen, a wise steward of corporate
resources, but am I really just interested in getting stuff done, and less
interested in getting to done safely. Safely cost extra, and takes longer,
believe you me.

Is it simply impatience that encourages me to accept risk? I don’t think
so. It is more that I have learned to manage risk with transparency and
trust, and history of accomplishment. I also have learned to expect
permission and forgiveness because delivering value is king! But our
increasingly intense regulatory environment is causing others to fear and
spend more on safety.

I’m just saying!

a new computer

I am actively in the market for a new computer.  The notebook that I have been using for the last five and a half years is slowly capitulating to the inevitable.  The HP Pavilion ZV5000Z was a screamer back in the day, and the 1600 x 1050 15.6 inch wide screen was truly a revelation in hi rez.  Software bloat, however has rendered the beast almost useless.  The latest was the 3.0 version of Thunderbird (Mozilla e-mail client).  The 2.x version that I was on was mostly sufficient, but the 3.0 version, just seems to take 10 or 20 seconds for every click. 

Frankly, I think that part of the problem is my windows xp os.  I have not re-installed windows xp for at least three years, and so most of my performance problems probably relate to registry bloat.  This machine is not capable of virtualization, as it cannot hold more than 1GB of ram. 

I like the HP Pavillion series for two primary reasons. 

1) I can buy exactly the configuration that I want (from  While I end up spending more up front, I spend less than if I bought a “store model” and upgraded. 
2) They have the best consumer grade docking solutions on the planet.  For about $135 (149 retail) – you can get a docking station, with its own power supply, so you don’t need your portable power adapter, a wireless keyboard and mouse, and an adjustable stand so that you can elevate the notebook screen to eye level.  The dock has better speakers, and ports for ethernet, extra monitor, usb, and a media bay for a large HD.

The generic usb docking solutions do not provide power, so one either needs to invest in a second power supply, for home use so that one can simply dock and connect two cables to get connected.  And none of them come with a stand, so at a cost of 60 for the dock, 70 for the power supply, and another 40 for the stand, and 50 for the wireless keyboard and mouse totalling $210 HP has an awesome deal, and true convenience.

I would probably pay the extra money for a macbook pro if they had a real docking solution, solving both connectivity and power so that a single connection could really engage the entire machine.

Sony has one, but the stand is inferior, and the overall cost is at least three hundred dollars north of where I want to be.

So congrats to HP who appears to have earned my business again by maintaining an innovative consumer grade notebook option that suits the way I work.

I am looking at a dv4i with an i5- 430 2.53 ghz dual core cpu, 6gb ram, a 500GB hd, and the beloved docking station, with a 1TB personal media drive for under $1200. 

I’ll be sure to let you all know when I decide to pull the trigger.

a new PIM

I am trying chandler – the open source PIM (personal information manager).  I have my stuff for the week in, and will let you know my opinions as I go forward.

I have my to do’s in, but don’t have my who’s figured out yet.  that is an interesting arrangement – because I am responsible for all of these, but I would like to see the (other involved persons) on each task.

I will trial the product for about a week and give a quick daily update.


an interesting model

I was surfing my way through some pages about personal information management software, and I found my self on Mitch Kapor's blog.  Mitch Kapor is the founder of Lotus Corp, and the original author of Lotus 1-2-3 – the spreadsheet that virtually everyone used before Microsoft completely dominated the desktop office software in the late '90s.  I was a big fan of the Agenda product, and have tried the Chandler product a couple times, but it was NRFPT (not ready for prime time).  I am contemplating giving it another go.

Anyway, Mitch has his current blog on and the interfaces is via e-mail…  I thought it was an interesting model, as I can e-mail from anywhere and I can save e-mails easily when offline if I have a longer post.  Having to be on-line to post is a pain.  having to save text or html files to post later is equally a pain.

This is a trial post, so there may be more later, or this could die quickly…

Early Delivery Part 2 (from my old blog)

Early delivery has been considered the first commandment of agile.  In the principles behind the Afile Manifesto, the first paragraphs says:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Early and Continuous delivery of valuable software…  I take this to mean that we are going to structure a project (or delivery stream), such that usable software “features” are completed as frequently as possible.  The shortens the feedback loop and allows the customer to decide when sufficient value has been delivered to justify a deployment or distribution event.

Different software development situations, call for different decisions regarding deployment:

1) For a company whose primary presence is via software and/or the web, especially where the revenue is driven by the software (think yahoo or google), the frequent delivery of new or enhanced features is a way to drive customer satisfaction.  The product manager responsible for these decisions, strike a balance between new ideas, and enhancements or fixes to existing.  
2) For a more enterprise software application, used by employees of a company, the cost of deploying and retraining staff on new software features, and the criticality of correctness.  The business process change management around delivery of new software features may drive a very different roll-out cycle.
3) A software vendor, selling software to business units within an enterprise, or small businesses, may have yet another model for making decisions about deployment.  They may be driven by demands from new customers, and prospects, as well as a backlog of requests from existing customers.  
4) Software that is to be “embedded” in a physical device may have a completely different decisions cycle, and a much more rigid schedule.  The delivery of the rest of the device into which the software is to be embedded, and the revenue derived from the sales of the devices, completely determine the schedule.  In this model, partial delivery has little or minimal value.
5) Software that is deployed in industries that are heavily regulated (blood bank) or that have critical quality requirements (military/aerospace) may have much more rigid schedules that are driven by decisions made well before the development starts.  In this model, the ultra-high cost of quality assuranceand regulatory certification reduces the value of partial delivery to near zero.

It is easy to see why the value of agile principles is readily apparent to some, and a complete mystery to others.  It is the decision model that works in between need and deployment that determines the value of early or frequent delivery.  From a whole project perspective, this is clear.  But let’s look from a intraproject perspective.

Early Delivery (from my old blog)

Glen Alleman of the Herding Cats Blog in his post “Make Speed Not Haste” has once again taken an agile concept out of context.  In this case, it is about “early delivery”.  

“Instead if seeking to be early how about seeking to On Time. The planned need time. The date that the plan shows we need this item? Just having that date is not sufficient of course. The date needs to have cost and schedule margin. How much, that needs to thought through as well.
    Having worked on large complex projects with software, firmware, hardware and humans all interacting a critical question is always asked:

If we show up early can all the other elements of the project to the right of this date, be shifted to the left?

If not, it’s a waste of effort to show up early. And there is likely a downside to doing so.”

In Glen’s post, he sounds like he equates early delivery as equating to “ahead of schedule”.  This is not, in fact, what the agile community means or intends.  Agilists who talk about early delivery are describing the process of scheduling incremental delivery to expedite the most valuable, risky, or juicy features of a software product so that they can be deployed, tested, or sold, as early as possible.  The notion is that a – the shorter the timeline between business need and delivery, the less likelihood that the business will have changed out from under the requirements.  The faster we can deliver product, the faster we get paid.  The faster we get something working, the faster we can validate our design assumptions and incorporate feedback into the remaining features.

Most of all early delivery is about arranging the sequence in the schedule, not working out of sequence, or ahead of shedule. 

Not too long ago, I saw an e-book “Rocks into Gold” by Clark Ching that ties this notion of early delivery to creative solutions for the economic crisis.  

The perceived evils that the concept of early delivery is trying to address occur in projects with long timeframes between the identification if business need and the delivery of value.  The evils that can be pervasive in this context are:

1) Your product is obsolete before it is delivered – this occurs when the business need changes but your deliverable does not.  Risks around too little, too late.  

2) Your project is canceled before it is complete – market or economic conditions call for reduced spending, and the project’s doesn’t show return on investment meaningful ROI until the company is projected to be bankrupt.

3) Your product is delivered, and is not well received in the market or user community, you are then required to make many modifications that delay the delivery of additional value, and reduce the return on investment.  (Think windows vista).


In his excellent management skills blog, Tom Foster posts a brief series on Procrastination. Brad, a middle manager, procrastinates and brings the organization to a state where they are months behind on a major project. Tom spends a lot of time talking about time-span, as a predictor of management qualification. I appreciate this, as it has made me more aware of my limitations.

I can’t help but ask what is someone to do, to help an employee (or manager, supervisor, or executive) to improve their time span. There are many symptoms of a person who is expected to work beyond his time span. In my experience, most people, get used to working within a certain time span. The longer they are in a role, without specific challenges to increase that time span, the harder it will become for them to improve this capability.

Here are two tools that can be coached into a person, to help them become more effective at longer time span tasks:

1) Progressive Plan Elaboration – Start with a plan that is at a very high level, where the plan deliverables are each about the size of the person’s normal time span without worrying about smaller details. Order these deliverables in a reasonable sequence without worrying about smaller details. Agree on a schedule for starting work on each of these deliverables, and make sure that the plan includes a task to plan the smaller details of each deliverable, before the work on that deliverable is scheduled to begin. This technique works because most of us get hung up around the many details, rather than the basic work structure. We worry about things that we won’t know until we have done some of the work, and so we can’t always plan in detail in advance. For some people who think from the details up, this can be paralyzing, and the top down approach, ignoring the details until we are close up can really help.

2) Iterative Measurement – There are some times when the work cannot be broken up into discrete deliverables, other times, when there are many deliverables being worked on in parallel. Project Plans with these features can be difficult to organize, so we can break things into discrete time boxes or iterations. This specific work (list of tasks) will get done in this time frame (use a iteration time span that is within your graps). Make sure that you are planning each time box in advance, enough to make work assignments and manage schedules.

How could Brad, in Tom Foster’s post, use these two approaches to reduce the impact of procrastination? It sounds like Brad has a team of supervisors who can get the work done. He could probably work with them to set up a deliverable based plan, and have them work the schedule, and report the details of the plan for each deliverable before the work on that deliverable is stared. Alternatively, he could break the work into time boxes that he can manage (2 months) and set goals that are 2 months out and work toward those, re-establishing the goals, every months for a 2 month period. This approach could be called “rolling-wave” planning because there are overlaps between the iterations or time-boxes. If every month, I plan two months out, then I can respond to problems in the now, and adjust the plan, before a crisis becomes intense. By measuring my progress each month, I can feel myself starting to get behind, and I can adjust, rather than simply waiting for time to run out and making a mad dash to the goal.

Why “Velocity” Is Not As Bad As They Say

Glen Alleman of the Herding Cats blog is one of the most experienced project managers I have ever read.  His background is amazing.  He is bright, and has practical knowledge of projects that I will never have.  However, he is missing the point on agile and velocity.
I recently read his post “Simple Never Is” and have this response to offer.
I have been working on software projects for some 20 years, and while I am not a practitioner of any formal agile methodology either project management or software development, I have been exposed to incredibly ad hoc practices in managing software projects.  I agree with Glen when he says that agile (spokesmen) railing against traditional project management have never been exposed to good traditional software management practices.  Most project managers that I have worked with, take a couple classes, manage a couple projects, and maybe get a PMP cert and then do the same thing over and over, with varying results, because they personally suck, not because their methodology is fundamentally flawed.  I have been this project manager, and I sucked as well.  I think that most of this is because the organizations that I have worked for did not sponsor, fund, or require good project management practices.

Agile, and specifically scrum, are a reaction to the suckage.  It is the project team reacting to the fact that project managers don’t use practices that help.  What scrum and other agilish methods and practices around project management do is help the team remove two specific smells from project management:

  • plan fiction – the two most prevalent fictions I have experienced in project plans are a) plans that don’t reflect how the work is really done b) capture of partial task completion in percent based on the developers opinion.  Neither of these conditions necessitate a deliberate deception, but can be the simple result of laziness or communication issues.  
  • inconsistent plan maintenance – when at the outset of a project, there is no establishment of team values and rules around how estimates will be performed, adjusted and maintained in the plan, how the plan will be elaborated, what acceptable task effort is.  When there is no enforced measurement frequency, or commitment around reflecting the current work breakdown and task sequence in the plan, even though it changes from week to week, then the plan itself becomes useless.

The thing that Glen is missing is that velocity is not a project completion measure, but a team productivity measure.  Agile project management is more about team than project.  Thus it makes sense that the most visible measure is team productivity, not project progress.  From a project progress perspective, velocity is exactly what Glen says – predicting the future by evaluating the past.  He calls this driving by rear view mirror.  Velocity, however, is good for the team.  It tells them whether their current pace is likely to match the published/committed schedule, and when measured frequently enough (like every week), it tells them early enough, that they can decide to adjust something to stay on schedule.  

Velocity is a factor that is involved in the measurement of current projected duration.  Current projected duration is a simple measure – remaining work / average velocity = projected duration.  This measure has a bunch of assumptions:

  1. productivity is the primary predictor of duration – this is a big leap, but I think that this is what Glen reacts to, because there are not many large projects where this is true of the project overall.  However for many software projects during the development milestone, the team is focused on this, and are held accountable for this and this alone.
  2. there is enough parallelism in the plan that sequencing of task execution is not rigid – that is the team can reassign tasks and resequence tasks to mitigate the impact of delays on one task or deliverable.
  3. the plan is updated at least as frequently as it is measured –  As the work goes on, the plan is updated – newly discovered work is added into the plan, and work that is determined to be less, or not necessary is removed from the plan.  that is, remaining work is not only adjusted by the work complete, but by periodic adjustments to task estimates, and by addition of tasks when new work or re-work is required.

I think that Glen’s characterization of velocity as a “rear view mirror” and “yesterday’s weather” metric is largely because of his believe that past performance is not always a good indicator of future results.  While this is true, velocity and current projected duration are useful metrics that can be applied in many ways to measure productivity and schedule.  Glen says that velocity is a level of effort measure, and I disagree.  Here’s why:

Remaining work is always an estimate.  Properly calculated, velocity is the sum of the effort estimates for the completed tasks for a period, and requires that the task estimates not be adjusted during the measurement period when the tasks are completed.  Velocity is meaningless if not used to project duration, therefore velocity must be in the same units as remaining work.  

If calculated this way it is not, as Glen suggests, a LOE measure, but much closer to EV, because it approximates the budgeted effort.  The thing about velocity that many project managers struggle with is that it is not precise, and it doesn’t contemplate many aspects of the project timeline, only team productivity.  I believe this is because agile disciplines are mostly focused on the behaviors of the team, and increasing/maximizing team productivity, and as a result, the delivery of value by the team.

Here are some things that I have done with velocity (in combination with other measures):

  1. Working backward from an published end date and remaining work, assuming resource allocation is constant, we can calculate required periodic velocity – or the amount of work that must be completed per period (week?) on average to acheive completion by the end date.  I use this to ensure that we are planning (committing) to complete enough work each period (week) to stay on schedule.
  2. We can capture personal velocity metric to capture each team members average productivity, versus their own estimates.  I have measured velocity vs. committment to help team members plan more effectively, and to help the team re-allocate work to stay on target.  This is a great help to managers who want to coach developers into higher performance, on both development and estimation.  

In my experience, velocity alone is insufficient for many projects, as it doesn’t really contemplate the complexity of external dependencies, interactions between teams, etc. When these factors are in play additional measures can be devised or adopted to present conditions where the project is at risk.  When my team is largely in control of the project and there are fewer connections and dependencies, I have experienced the benefit of this simple measure (velocity) because it is easy to understand, and difficult to fake out.  These two factors allow a development of trust between project manager and team and a focus on solutions (adjusting the plan).

Metaphors in Requirements

This week I was asked to review job descriptions for analyst roles within our IT function. The roles were “Analyst, Business Systems”, and “Senior Analyst, Business Systems”.

The person who asked me was looking for my opinion because I am strongly opinionated, blunt, and have experiencing hiring and leading business analysts and requirements engineers. She wanted to understand the difference between an analyst and a senior analyst.

Other than the expression of leadership within a project or team context that I would expect of any senior contributor, my answer had to do with metaphors.

Metaphors are the solid business abstractions that software is designed around. Metaphors are the unambiguously defined concepts that ground the business process. Metaphors are the litmus test to see if requirements are cohesive and complete. If your metaphors suck, so do your requirements.

Back in the ’90s when I was learning object oriented application design (OOAD) we were taught that each application or major feature had a “central object” that was the focus of it’s existence. Microsoft word has a “document”. Every e-mail client has a post or a message. This central object is the metaphor around which the application is designed, we just didn’t call them metaphors back then.

When designing an application all of your actions are performed on metaphors, all of your business rules contemplate metaphors, and your data model expresses your knowledge of your metaphors. Your metaphors are the essence of your understanding and modeling of the REAL BUSINESS stuff that your users and customers have to deal with in the REAL WORLD as part of their job. The more your metaphors align with reality, and the more you can eliminate ambiguity among and between metaphors in your requirements, the easier it will be for software designers, architects, and developers to model and fashion a system around them.

That’s my story and I am sticking to it. The senior analyst gets this, and carefully and thoughtfully identifies, defines, and clarifies essential metaphors within business requirements, and knows the the requirements aren’t complete until all of the metaphors defined hold together with the business rules and actions required.

Metaphors work most effectively when you can get your user community to communicate (to you, and to each other) in terms of metaphors that you helped define. When you have defined useful metaphors that clarify the business process, your users will adopt your terminology because it helps them understand what is important. Then in that context your software (being true to those metaphors) will be intuitive.

An analyst can capture and document the business process. The senior analyst (one with mastery) can change the conversation casting metaphors that help the business community define its value proposition and supporting processes more effectively.