Where does development process improvement fall into the product development lifecycle?

Question

For most of my career as a software developer, I have been a part of Agile teams, using methodologies like Scrum, Lean Startup, or Kanban.

The Product team usually has goals for keeping the product running, improving the products and moving towards the long term vision of the organization.

However, in order to improve the feedback loop that takes you from Idea to Prototype to a working Product is the Development process, but we hardly see this as a part of the KPI's for the product goals.

The product goals can be achieved & kept up with through a continually improving development process.

Why does seem that the product management usually doesn't explicitly include the development process (Ex. Team Work, Collaboration, Addressing technical debt) as a part of the product KPI's?

Disclaimer: This is a pattern that I have observed on reflection and is not specific to a particular organization and there are cases opposite to what I discuss here as well.

Answer 1

There seems to be a few questions baked in here:

• What phase or activity in the product development life cycle includes process improvement?
• Is process improvement necessary to achieve and maintain the product goals?
• Why don't we see KPIs related to process improvement?

Where process improvement is included in a life cycle depends on the life cycle model. Process improvement is an ongoing activity, so it may not be explicitly included in some phase-based models. You would have to plan (in the schedule and budget) for and manage any ongoing activities, including process improvement, but the explicit process improvement activities touch all of the activities in the life cycle.

Process improvement probably isn't necessary to achieve a set of product goals. However, it is necessary for an organization to maintain an advantage over competitors. If an organization does not consider new ways of working, it's likely that a competitor who does will overtake them. The risk of this does depend on many factors in the context.

I'm not sure why there aren't usually KPIs related to process improvement. There are a number of metrics that reflect the process - lead time, cycle time, throughput, defect removal effectiveness are a few examples. Any of these can be used as part of KPIs. However, even if an organization sees improvement as an important aspect of product development, it may not rise to a KPI.

Answer 2

Allow me to explore a radical view, which I admit may not help you in your organizational environment. First, your excellent question points to another reason many agile thinkers consider the SDLC an outdated model. All projects have some reliance on previous work, and those which succeed never truly "close": There's just a new major version. Furthermore, classic waterfall schedules and budgets are irrelevant in a truly agile organization. Thus any KPIs reflecting waterfall thinking are also irrelevant.

Agile teams are supposed to be self-organizing, made up of self-motivated workers trusted to satisfy the customer. (In the case you are describing, where the team does not interact directly with external customers, I would treat the Product Manager or similar role as the "Customer"--not as the Product Owner.) In my approach, I recommend teams hold back at least 10% of their capacity each sprint to work on the stuff they know is important to please the Customer, even if the Customer doesn't recognize it: refactoring, legacy bug fixing, process or tool improvement, etc. They do this by creating user stories to do that work, so it is transparent. KPIs can be built for some of these if needed, like "legacy bug count" or "labor time per bug-fix ticket."

In short, you are correct that there can be KPIs reflecting those important activities. The problem is managers who claim to be agile but are still stuck in inefficient ways of managing software programs.

Answer 3

You're asking different questions on the same statement, so I'll assume your underlying question boils down to

"Why is my Product Owner not prioritising (or making it visible) development team's efforts, either technical or organisational?"

There could be different reasons for that. One of the most common reasons (specially if you have a not very seasoned PO) is because he thinks that's not his work (and some may argue it's not, indeed). It's up to the team to speak up and make it visible.

Why does seem that the product teams usually miss out on explicitly including the development process as a part of the product KPI's ?

Who defines the KPIs? If any team measurement is being defined in isolation, without any conversation with the team, we're back (again) to the speak up culture the team needs. The agile manifesto reminds us that Working software is the primary measure of progress. KPIs are a means (and oftentimes, misused) to a goal. The goal here is outcomes. Focus on delivering working software and improving the processes around delivering software. That's the best way to demonstrate that team's improvements worth the investment.

Answer 4

I think you make a good point: Improvement work should be a part of the product's KPIs.

By having the definition of the product include the delivery capability you will hopefully ensure that as the product improves, so to does the capability to deliver future improvements.

I suspect the reason that this rarely (in my experience) happens is that the engineering function in organisations is typically viewed as discrete from the product function. This is a shame, as it would be better to view the entire delivery of value process as a whole ("the product team").

A common approach used today is to make improvement work part of the development team's KPIs. This has the disadvantage that it can potentially create a misalignment: A competition for the team's time between improvement work and product development.