Skin in the Game

You have seen it before. After months of defining and redefining the requirements, the business signs off. Development and testing occurs. The software is delivered and the response is often, “That is not what I asked for!” Each side “lawyers-up” and the battle rages on.

This is not a rare occurrence. Anyone who has done development has at least one similar story to share. Why does this happen?

This is frequently the results of “contract development”. Developers are tired of being blamed. They demand detailed requirements. They demand from the business all the details before beginning the development. By having all the requirements defined, signed off and locked down, they reason, they can deliver what was asked for and not end up in hot water.

The problem is developers have painted the business into a corner. While the business may know in a broad sense what they want, they are not sure of what is possible let alone all the details. The business is fearful of signing the requirements document. Given the hoops that one much jump through to make a change, is it any wonder they have nightmares of what they might have missed. Consequently, the requirements become a catch all of everything under the sun. The gathering takes longer than necessary. Even after much time the requirements are vague, confusing and cumbersome. It is only when the project manager says the project is behind schedule and over budget that the requirements are signed.

This is all about avoiding blame instead of delivering value. Not a good place to be. What are the chances of delivering business value with such a start?

Many of the agile practices are put in place to prevent the failure brought about by “contract development”. It is collaboration and tight feedback loops that enable the developers and business to quickly and iteratively discover what is needed.

What is needed is for the business to have “skin in the game”. The business has to be as responsible for deliver as the developers. How do you accomplish business accountability? This is primarily possible via the role of the product owner. The product owner owns

• determining what is in the product backlog
• setting priorities for the items in the backlog
• changing the items in the backlog or adjusting the priorities each iteration
• determining when an item in the backlog is done

Talk about “skin in the game”. The business, via the product owner, plays a critical role in the success of the team. They are continually involved in making key decisions and trade-offs. The product owner is aware the budget is fixed and the need to deliver ASAP. After all, the ultimate business need is that “it takes no time and cost no money”.

The product owner helps the team to focus on delivering as many backlog items as possible for the dollars and time budgeted. The product owner soon comes to realize when he or she makes changes it often comes at the expense of completing other items on the backlog.  Thus, the product owner weighs changes carefully and deliberately, yet the business makes changes when justified by business value.

The wall that existed between development and the business soon disappears. It is no longer two groups with arched backs and defensive postures. Instead, the two organizations are working in close tandem attempting to complete as much as possible under the current constraints. Little time is wasted arguing about requirements or what is a defect. Everyone is focused on the solution and maximizing what can be delivered. It is soon recognized by everyone that during development, issues are uncovered and trade-offs must be made. Given the team wants the best solution possible, there is little time spent covering ones backside or arguing about the original spec., project schedules or budget. Everyone is focused on what is the best solution. Talk about eliminating waste.

All on the team are accountable for the time and dollars spent and the value delivered. It is the team taking accountability and credit for the results. It is the recognition by the developers that not all requirements are knowable to begin with. It is the recognition by the business that they will change their minds and priorities as they see the solution unfold and that the scope needs to be adjusted with the new reality. It is only when both sides recognize that everyone on the team is accountable that the two sides become a single team and high performing.

By the way, a funny thing happens to the project manager. When the project manager sees the business involved with the team and proud of what the team has accomplished, the project managers become less ridged about the plan and begins to understand the difference between being “plan driven” and “value driven”. They watch as everyone becomes more focused and excited about the solution and less concerned about a plan that was built when the least was known about what was possible.

It is all about shared focus and accountability, about breaking down the walls built by self-preservation. The product owner is the catalyst that brings the business and the developers together. The product owner responsibilities ensure the business has as much “skin in the game” as the development organization. The product owner brings two sides to the same side. Contracts disappear and value emerges.

Bottom line is to never skip on the product owner. Do with one less pair of developers or tester or business analyst. However, never ever go without a product owner. Without a product owner, the business has no “skin in the game”.