The Right Position for Product Organizations

What is the purpose of a product organization? Thinking generally, it is to increase the value of a product “in the eyes” of the customers, consumers, or users of the product. It doesn’t matter whether the product is toilet paper or software.

The product manager has decision rights over what the product will become.

The product organization manages a portfolio of products, and the purpose of portfolio management is usually maximize the value of the portfolio. How they do this job depends largely on the products and the organization that sponsors them.Continue Reading

IT Staffing Strategy Terminology

I am thinking about IT staffing strategy. In order to share my thoughts, I need to define some aspects of that strategy, and perhaps explain why I think they are important. I am not an OD guy, nor do I play one on TV. I have, however, observed and participated in management and leadership in information technology for over twenty years.

Earlier posts on IT Strategy including Goal Strategy Policy and Vision, Strategy, Policy are the beginnings of where these thoughts come from.

Continue Reading

Put the Yak on the Stack

In a prior post, I introduced the concept of Yak Shaving.  In this brief post, I want to introduce a strategy for preventing Yak Shaving.

The developers on this team have become sensitized to yak shaving, and often report that they ran into a yak on the way to done.  They have to make a decision whether to shave the yak now or to ignore it.

By the way, most of our yak’s are tech debt in the form of code tangles – left behind by a herd of contract developers who meant well, but were being forced through a schedule driven effort to get stuff out the door.

The concept is this, rather than shave the yak on the way to done, decide on the way back from working.  So I capture the yak, put it on the stack (tie it to the roof of my SUV) and keep rolling down the path to working feature.  Then on the way back from working, I can decide which of the yaks I can safely shave and still stay on schedule.

Of course, sometimes there is the proverbial herd of yak’s blocking the road to working.  In that case, I have to find a different strategy.  More on that later.

 

Re-engineering: the Path to Complete

In a recent estimation exercise with a software delivery team, I cast the following assumption:

“No classes that were not directly impacted by the story being estimated would be re-engineered.”

This is an important assumption, for this team, because they tend toward boy scouting.  They always want to leave the code base (camp site) better than they found it.  Often, they add effort and risk to a story delivery because they want to re-engineer classes that are only marginally related to the story itself.Continue Reading

Proper Task Length

Glen Alleman in his post How Long Should Tasks Be gets to the heart of an important issue.  When planning, how long can you wait before you know that you are late.

In principle, it works like this – you don’t know you are late until you fail to complete a task on schedule.  How late you are depends on the remaining work in the late task.  How long can you wait to determine that a task is behind schedule?  That depends on where you are on the project timeline and how much “margin” is remaining in the plan.

In practice there are other dependencies.  Measurement frequency is important.  The more frequently you measure progress against the plan, the smaller tasks increments you will naturally prefer.  You want to see progress at every measurement cycle.Continue Reading