2. Quality of the Product

Product quality has two aspects to it – quality of the product to the customer and how well the product is built. This later part will greatly affect how quickly new products and enhancements can be built. If the company has a long term relationship with their customers, especially if the product is software based or accessed, then the quality of the product is a value to the customer since updates will be expect.

Figuring out what customers want and need is considered to be notoriously difficult. But much of this is because most people pay attention to the system they are building and not the customer’s operational value stream.

A focus on the customer’s operational value stream via the customer journey is how we determine what to build. How we build it is based on the needs of the business. If the business’s ability to deliver value is not impeded by low quality code, then quality of the code is not critical. But few businesses have this true for them. Keeping code quality high and having automated tests provides the ability for organizations to respond quickly.

2.1 Have a quality architecture

2.2 Have high quality from the customer’s perspective

2.3 Get quick feedback from the customer

2.4 Consider how you will test something before building it

2.1 Objective: Have a quality Architecture

Architecture relates to how the different components of a system relate to each other. There are several types of architecture, but two are most important at the team level – business architecture and system architecture. Business architecture is typically outside the scope of the team and would be within the domain of the product owner. It’s important to understand how any changes or enhances to functionality will affect other systems. The team will likely have system architecture issues to work with. It is a misunderstanding of self-organization that teams can create their own architecture. This has to be done within the context of the organization’s system architecture.

Why this is important

The biggest expense in building products is wasted effort. While much of this is in building the wrong thing if you’re doing software development a greater amount is the waste in the software development process itself.

How to implement when using either timeboxing or flow

You should overbuild. Mostly being aware of what’s happening and attending to is what’s needed. Ensure your product owner communicates to the organization’s business architect. You don’t want to build in extra functionality, but you do need to pay attention to technical debt and try to keep it low.

Anti-patterns

Not attending to business architecture will have one team’s change affect another team’s functionality without realizing it. This will cause challenges out in the field.

2.2 Objective: Have high product quality from the customer’s perspective

Why this is important

The biggest cost/waste is building the wrong thing. That is often hard to prevent but you at least want to notice when you’ve done it as soon as you can.

How to implement when using either timeboxing or flow

This is one of the key factors in deciding whether to use timeboxing or flow. If the product being built is not well known, continuous demonstration, validation and pivoting may be necessary. If we’re creating a new product with MVPs, then it is likely flow should be used. When speed of feedback needs to be high, recognize that planning an entire timebox will likely be a waste because we will change what we want to work on as we get feedback.

However, the availability of the person who best knows what the customer needs is also a factor. If they are only available on an irregular basis, time-boxing may be needed.

Fast feedback is the best way to ensure you’re building the right thing.

If you are using timeboxing

Many teams that use timeboxing don’t do demonstrations of what they are building until the end of the iteration. So, if timeboxing is being used try to get as much feedback from customers as you can.

Focus on completing stories, features and releasable items as quickly as possible to provide feedback on the quality of what’s being built.

Get feedback after each item is accomplished.

Working on small items enhance delivery of value quicker. Working on large items is correlated with waste will slow feedback and delay the delivery of value.

Having acceptance criteria prior to working on an item will result in clarity and less rework, without this it will often results in misunderstandings and rework.

A DoR is needed when handoffs are done so each party understands their agreements with others.

High value items can be used to align work to business value. If this is not present people will not coordinate what they are working on to get value out the door quickly.

Anti-patterns

If you aren’t building from the customers’ perspectives your product be awkward, even difficult to use. It won’t garner the support your organization would like to get from its customers. You won’t get viral selling from your customers that you’d like to get.

2.3 Objective: Get quick feedback from the customer

Why this is important

Quick feedback is critical to avoid building the wrong product. In some situations, it is difficult for teams to be in contact with the product owner so it is important to set up a cadence for conversations as needed.

How to implement when using either timeboxing or flow

This is one of the key factors in deciding whether to use timeboxing or flow. If the product being built is not well know continuous demonstration, validation and pivoting may be necessary. If we’re creating a new product with MVPs, then it is likely flow should be used. When speed of feedback needs to be high, recognize that planning an entire timebox will likely be a waste because we will change what we want to work on as we get feedback.

The biggest cost/waste is building the wrong thing. That is often hard to prevent but you at least want to notice when you’ve done it as soon as you can.

Anti-patterns

If you’re not getting quick feedback from your customer you are likely going to do a combination of the following:

• build the wrong functionality
• build more functionality than you need
• miss opportunities to build create functionality

2.4 Objective: Consider how you will test something before building it

Consider this – does it make sense to build something if you aren’t sure what the requirement is? What’s the best way to find out? Build it and then see if it meets it? Or ask the person who is going to validate what you wrote what their criteria for accepting it is? This acceptance criteria is already in their head. They may just not have told you it. The idea of “test-first” is really get what the person making the requirement is going to use to see if the right thing was built before you start creating it.

Why this is important

Without this the creators of the functionality will mostly be guessing what is needed. This will waste time and create a lot of handbacks.

How to implement when using either timeboxing or flow

This is not impacted significantly with either timeboxing or flow. If you are using timeboxing you will need bigger batches of a product owners time since you’ll need to gather all of this at the start of the sprint. If that’s not available a flow model may be better.

A simple way to incorporate a test-first mentality is for people to ask “who will I know I’ve done that?” whenever they are asked to create something. This requires the requester to stop and think about it, gaining clarity on the request. It also provides the person about to create the requested functionality to an opportunity to start their process by having the end in mind. These two, when combined also help create a mutual understanding of what is required.

Anti-patterns

You are not doing this effectively if after building something the customer says it was the wrong thing.

Reference: Define Tests Up Front

Go to Amplio Development: The Path to Effective Lean Agile Teams 

.