Westerly Consulting

Homehome.html
Due DiligenceDue_Diligence.html
ProductProduct.html
Management AdvisoryManagement_Advisory.html
BlogBlog.html
AboutAbout.html
Contact UsContact_Us.html
 

Aligning the Agile Company

Governance needs to be cross functional.

Fred Engel

Westerly Consulting


The problems of getting good software delivered continuously to the market place are not just a Software Development problem. They affect the entire company and thus the entire company needs to change to help get the products decisions made.  The decisions being made about what to build next are not just about adding features to a product, unless you are a small start-up without a customer base.

Once the company has some success and acquires customers, and often more than one core product, the engineering resources serve more masters than “add a new feature”. There is considerable conflict in choosing between servicing existing customers, fixing bugs, adding features, retaining key customers, customizing for new sales, and investing in Technology Debt. Each of these items need to be considered when making the investment decisions for the next sprint, month, or quarter.

When a product has a user base, there are many constituencies that demand the attention of the development engineers.  The Product Owner is usually swamped with requests from Support, Customer Relations, Sales, Marketing, Product Management, Customers, Finance, and Technology to service their absolute need to have their priority move to the top of the Product Backlog.  The product Owner usually does not have enough context to make effective decisions and therefore needs help.

Below are some examples of decisions that are often thought of as technical decisions, they are not. The Product Owner or an Engineer often make these trade-offs as the resources available are usually insufficient to achieve all the goals simultaneously.  In the questions below, assume that only one of the choices presented can be delivered in the coming sprint.  Which one should be done next? 

  1. 1.Two customers in pain?

  2. 2.Two new customers with revenue?

  3. 3.A customer in pain and new customer?

  4. 4.Technical debt vs. a new customer?

  5. 5.Technical debt vs. bug escalations?

  6. 6.Finishing features delivered in an MVP to single customer vs. adding another customer?


Are these technical decisions or business decisions? In fact, are these decisions ones that a single person could reasonably make without a lot of input?  Can the Product Owner have enough context to make these types of trade-offs on a regular basis with the necessary speed?

The choices above are business decisions that need to be made by those with knowledge of the business situation.  Deciding between a customer in pain and work to acquire a new customer will probably take two people’s input (one from sales and one from support).  Often the decisions are not as simple as there are more than two parties vying for the limited development resources.

There are different models for how to help the Product Owner make decisions once the company is large enough to have the kinds of conflict described above. For large organizations, there is Scaled Agile Framework (SAFE), Disciplined Agile Development (DAD), Dynamic Systems Development Method (DSDM), and others.  They each have their proponents and success stories.  My own experience is limited to SAFE and I have found it to work well in large environments.

But for smaller organizations, these solutions are overkill. Smaller companies need a simpler solution that helps them make decisions faster without adding some of the other structures that will only get in the way.  For these companies, a simple two tier decision process can solve the problem.

At the lower level, each product has what is a cross functional group that works with the Product Owner to bring in the company wide knowledge to make the key decisions on a regular basis.  These Product Decision Teams are tasked with making the product successful. The people on the teams are close to the action so they implicitly know the details needed to make these decisions.  They are empowered to represent their organizations and make decisions.  The teams are composed of people from each function that matters in product decisions (usually this is every department).


The higher tier, The Product Strategy Team (PST), is made up of the top level decisions makers in the company. Often, this would be the Executive Staff that runs the company.  They are empowered to make final decisions for the company.  Their role is two-fold. They act as an escalation point for the PDT’s when they are stuck.  They provide the overall strategy to the PDT’s.  The PST must be extremely responsive to the PDT’s. A good rule of thumb is that they make decisions within 24 hours of an PDT request.  They cannot be “too busy” for that detail. It is their obligation to keep things moving and to unblock whatever needs to be unblocked.  They act as good Servant Managers, not an autocratic group that rules all.

I have found this structure to be transformational in many companies.  Once it takes hold, rationality returns to what is often an irrational decision process that makes everyone unhappy.  In a future blog I will provide more detail on this process.