One of the issues I see with successful agile teams is the lack of strategic thinking on why and how they solve prioritized business needs. Features get prioritized without sufficient dialog on the value, drivers, and debate on the balance between a minimal versus ideal implementation. The implementation and architecture can also suffer if the team under or over invests engineering time, implementation of standards, or testing discipline in the wrong areas.This, in some way, is a byproduct of self-organization. Left on its own, product owners and development teams just may make debatable and sometimes questionable decisions on priorities or implementation strategy. In hindsight, this looks like features that might have received too much (or too little) investment, development approaches that require more significant (or less) architecture consideration, or enhancements that require additional investment in testing.

One of my solutions to this issue is to give teams some driving principles.

1) Business value versus technical complexity

Consider the axes shown. The y-axis is a measure of business importance, with the top showing an ideal state of “high” business value that can be easily measured. The bottom of this axis is not “low” value – if we knew something had low value, then chances are we would choose not to invest in it. Instead, the bottom of the axis depicts when the value is unknown or difficult to measure.

The x-axis depicts technical complexity, risk, and cost which are all related. The right side of this axis shows the ideal state when something is technically “simple” and can be implemented with low investment, and minimal risk or complexity. The other extreme on the left side of this axis is when the implementation is hard, unknown, complex or risky.

2) The agile “happy place”

Agile teams sprint when the value is known, implementation is low risk

Agile teams – both business and technical members like being in the upper right quadrant where the business value of a product, feature, or enhancement is high, measured and can be implemented easily. We know what to do with these enhancements – prioritize, estimate, sprint, release, and measure the business outcome.

I call this the “happy place” because there are the low business and technical risk, but it doesn’t imply “easy”. If there are many enhancements in this category, the business and technical team must still prioritize. There is still technical debt that must be worked into the development backlog. There still needs to be discipline around releases. Teams in this quadrant will often feel pressure to deliver more features sooner.

3) Reality – it’s hard to know value upfront.

Select innovation features, but measure their outcome!

What happens when the business value is unknown or hard to measure without some form of investment? Does that mean we don’t implement these needs?

I call this scenario “Innovate and Measure”. It means the team should select the most promising ideas, implement them “lightly” (low investment, beta, some acceptable tech debt, etc.), decide on success metrics, measure, and then decide if additional investment is warranted.

Teams can go astray if there is an imbalanced investment in these enhancements (too many or too few), if there is too much investment in them (either because the product owner drives the team to an ideal feature set, or if the team implements too much of the ideal architecture), or if metrics aren’t built into the investment (success criteria, measurement technique, follow up). If the innovation is successful, then the metrics should help drive the enhancement into the top/right “agile happy place” quadrant. But I would also recommend teams discuss “exit strategies” for these features if the outcomes don’t meet the success criteria, especially if there is significant tech debt associated with developing them.

4) Reality – Some things are “hard”

Use prototyping to lower technical risks and costs

Technically “hard” is a term relative to the skills, process, and platforms of the development team. If an implementation can’t easily be estimated by a development team, if there is a unique technical challenge that needs discovery, if there is a new technology involved, or if a technology is being used in a new way then I place them in the “architecture and prototyping” quadrant. Development teams working with these unknowns will often introduce “spikes” into the product backlog to complete discovery work and remove risks. This is healthy, but teams need to recognize the true objective is risk removal and ideally to move this enhancement to the “agile happy place”.

Product owners and technical managers also need to interpret this scenario properly. If there is significant R&D effort, then the enhancement probably falls out of scope for simple architecture enhancements or prototyping. New skills, technologies, platforms or partnerships might be needed to fulfill this objective which would make it difficult for the team to fulfill in optimal ways.

5) And sometimes, more significant investment is needed

 

Too many unknowns? R&D, planning, or investment may be needed

Once something is hard and out of scope for prototyping, it falls into one of two categories

• If the business value is unknown, then it should be left to the business team to develop a stronger business case. The product owner already knows that the implementation is hard/expensive, and I recommend that any further estimation or R&D should only come with a more quantifiable articulation of business value.
• If the business value is known, measured and high, and the implementation is in the expensive/risky category then technical leadership needs to regroup on a strategy. The existing practice can’t easily meet requirements and there may be an underlying investment in capability such as platforms, people, or process to help solution. Technology leadership need to consider build/buy/partner options. I label this as a business or technical risk because if left unaddressed, it could open the door to new competitors or leave customers with unaddressable needs.