A Response to the Myth Busters

In this post Glen Alleman retorts the commonly lauded platitude that:

“There is no way to prove that the requirements we have are complete and correct until we have working code.”

And as Glen is a very smart guy, from the perspective of the domains within which Glen most frequently works and thinks, his perspective that this is wrong, is essentially on target.

In those domains, requirements are imposed by the overall design of the program (not the software) with tremendous specificity:

The emergency shutdown system shall stop the turbine driving the compressor in 1.3 seconds or less to prevent overspeed of the RB-211

But in the domain of service business operations (investment management), a requirement for the program might look much less specific:

The investment platform shall allow portfolio managers to rebalance open architecture portfolios without requiring any non-trade transaction instructions implemented outside the investment platform.  This operation shall take no more than 2 minutes from initiation to completion for portfolios with up to 500 positions.

These requirements sound similarly specific.  The thing is they are not.  What is missing in the service business case is how many steps in the process require human interaction.  When the human interaction is taken into account, human variance and experience is important.Continue Reading

IT Staffing Strategy Considerations

What are the elements of a staffing strategy? What are the the things to consider when developing a staffing strategy? These are the questions I want to address in this post.

Division of work: What is that taxonomy into which you divide the work into that helps you decide how to staff?

Often IT organizations divide along lines of administration and delivery. Sometimes delivery is divided between support and development. For product organizations that don’t support installed customer platform, administration includes platform or infrastructure. For enterprise IT delivery includes platform or infrastructure. For product companies that also host their product on shared infrastructure, platform may be divided between administration and delivery.

Occasionally, IT organizations will have a sales or relationship function, separate from administration and delivery. Sometimes an R&D function will included, separate from administration and delivery. Sometimes both of these are included in the delivery organization.Continue Reading

Staff Forecasting for Software Delivery

One thing that IT managers – and many managers whose work consists of projects struggle with is staff forecasting. Project work can often require elastic staff scalability. I have more projects, or bigger projects, or tighter deadlines therefore I need to increase staff (elasticity) to a larger size to complete them on schedule. As a leader, I need to have practices in place that work equally well with larger organizations as with smaller organizations (scalability).

In observing how the construction industry scales to do projects there are lessons IT can learn, but they don’t apply directly.Continue Reading

Six Things I Have Learned About Staffing Software Development Teams

This is a collection of observations about things that managers and leaders of software teams encounter or trip over.  This post comes out of a series I am doing about IT Staffing Strategy, but these are localized to the software team, not the larger strategy picture.  These are very similar to Johanna Rothman’s excellent Management Myths series.  If you are any kind of a leader in a software team, some of these will resonate with you:Continue Reading

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