This is a guest post by Yanto Hesseling (@YantoHesseling).
Yanto Hesseling is an agile quality consultant and coach for agile teams. He is the founder of AgileHubNoord, an agile community based in the north of the Netherlands, with the goal of changing this region for the better. Yanto is very interested in methods and practices inside and outside software development that make people happy. And like many Dutch, he says things as they are.
There are common practices I use every day. As part of my toolkit I spend a lot of time and effort on ‘Trying new ways of doing things’ and ‘Asking questions when I do not understand something’.
These practices provide me insight into what works and what doesn’t. Answers become conversations about what is essential and meaningful for the team and the company, and those conversations transform into action.
As a disciplined agilist, I realize how important it is to inspect and adapt. There are many practices and strategies available. I try to choose the best for my context. Based on feedback I will be able to make adjustments and increase the likelihood of creating success or happiness and therefore value.
Value determination can be tricky. I often used the agile manifesto to decide if we carry out the work on the right or at the left side of the agile manifesto. Working on the items stated on the left side should be more valuable.
However, in order to achieve quality goals I find the agile manifesto and the principles limited. I think the agile manifesto only covers a part on delivering more benefits to society and value to individuals while eliminating waste. I think making something useful is more important than getting something done.
In my journey of trying to find new knowledge about how to create better value throughout software development I came across the agile testing manifesto. To understand the mindset and background of the agile testing manifesto principles ‘I started asking questions’. Sam and Karen the creators were happy to help me!
After several questions I started to understand that two principles from the five principles focusing more on creating value. These two principles are ‘Building the best system OVER breaking the system’ and ‘Team responsibility for quality OVER tester responsibility’.
When applying both principles, the real focus is on value. The customer demands the best system and the team should develop this. Each person in the team plays an integral role during development and contributes towards building a product of value to the end user. The team needs to understand what the customer is looking for, but also what the customer values.
Value maximization
These two principles I have discussed within agile software development teams. The feedback gives me an indication of the team’s ability to create software that customers value. Is the team aware of what customers want?
According to the Scrum Guide the Product Owner – who is part of the Scrum Team – is responsible for maximizing the business value that a Development Team delivers during the sprints. I’ve seen many flavors of Product Owners and none of them really worked as they should have.
Product management
A Product Manager can be the Product Owner without any issues because they are almost synonymous. An excellent Product Owner is an entrepreneur, a mini CEO, an innovator, a systems thinker and knows business models. Most Product Owners I have met don’t meet one of the stated requirements.
When the Product Owner doesn’t have the characteristics or skills listed above, teams struggle to understand what the customer is looking for or what problem the team should solve. Occasionally because there is a solution without a problem. The approach I often see is stop asking and start building. From a value perspective this is quite strange.
Customer participation
Sometimes, in a situation with full customer participation, it’s also difficult to create customer value. What questions shall be asked? What value do we intend to achieve for the customer? When is the customer really satisfied? Unfortunately I don’t hear these questions in most organizations and teams. I think that’s very interesting, there is difference between participation and collaboration.
There is something else important to realize here. From a quality perspective the ultimate test is to take a look at value creation. The customers’ demands are validated. This is an alternative approach to value, and could help some software development teams! We are going to make this product, and we know that’ll put a smile on customers’ faces. After all, the team should make things better for some people.
I think creating usable software is more important than creating working software. But you are also able to create valuable products by bringing awesomeness into your own project with these safe experiments. Make sure that there is an atmosphere where people feel safe, and can be open on things.
Try ‘eliminating projects’
Imagine the project you are working is stopped immediately. What will happen with business value? Will it harm your organization? Will valuable processes or services stop? Will customers be disappointed or angry?
There are a lot of different people involved in a project. For instance you may discuss this within your team, with your stakeholders or with your customers. Sometimes less than 100% of the finished product is enough to create value like 27% or 42%.
Avoid ‘speeding’
Every single company wants to build software faster. Time is considered the most expensive and valuable resource. You can’t waste it on re-work, refactoring, meetings, and, fast shipment is key. Right? It depends…
It is quite obvious that better skills improve development speed. More skilled developers solve problems faster and create less complex solutions.
I have seen teams that made a common mistake – they focus on the problems of the system and the development speed instead of the problems of the customer.
Conversations are technical and actions turn into technical solutions and actions. This approach will decrease the customer-centric approach.
Try ‘customer-centric approach’
A customer-centric approach is more than offering working software, it means offering a great experience through the system life cycle. It’s based on putting your customer first, and at the core of your business.
When you put your customer at the core of your system life cycle, you collect a valuable feedback, giving you a full view of the customer, which you can then use to enhance the customer experience.
Always put yourself in the shoes of the customer and minimize customer effort and maximize customer value. This centers the discussion on customer clarification and reduces misalignment by focusing on what customers want to do.
Thinking like this helps me to create a useful product. Teams gain more empathy with the customers, and this approach makes it possible to collaborate among teams to deliver that valuable product.
Avoid ‘explaining how it works’
As an engineer you may be interested how a system or products work. When it comes to creating solutions, customers require a product that fulfill their needs. Customers like to be informed but please let them experience what the product does instead of explaining how a system works. Let customers decide if the system solves their problem?
Try ‘start with why’
According to Simon Sinek, the fundamental difference between the “Apples” of the world and everyone else is that they start with “why.”
Sinek found is that most companies do their marketing backwards. They start with their “what” and then move to “how” they do it. Most of these companies neglect to even mention why they do what they do. Many of them don’t even know why they do what they do!
According Sinek you engage people if you can answer the why and when faith in it corresponds to the belief of people. “Why” it’s all about your purpose. Why are you doing this? Why does your organization exist? Why does your customer choose your product? Only when it is clear why a person or an organization does something, people can believe in it.
Sometimes, we think in systems, releases, or projects. Unfortunately, many software development projects I have experienced are technology driven only. When a new project is started, it is all about what to develop instead of why it should be developed.
Creating a window without the building, a light without the room, or a motor without the machine sounds funny. What if you create a product without knowing why the customer requires this product?
Most projects are IT driven. That said, a lot of IT craftsmen I have seen don’t care about the purpose of the end user or customer. Discussing the “why” will slow down the pace of creating software sounds valid. However, in order to create usable software understanding the customer is required. Therefore…
Avoid ‘demo’s’
In the 2013 edition of the scrum guide the sprint demo is replaced by the sprint review. The sprint review is an opportunity for everyone to collaborate about the product.
The idea behind the demo is to make progress visible. When stakeholders see progress in terms of working software they are more likely to have increased confidence in product development. At the same time, if something could not be completed within the sprint, the demo makes it visible.
A lot of teams think scrum is about taking a piece of the backlog, and building it. Then take another piece, and build it. And so on, until all the items of backlog are done. We never think about letting end users try the product and getting feedback and changing the backlog.
The purpose of a lot of demo’s I experienced is to show progress instead of to get feedback. Once the stakeholders are happy with progress, we go back to developing the next item on the backlog.
Valuable feedback appears when the user uses the software in accomplishing real life goals. That takes time and can be hard. But it’s something that cannot be done in a demo.
Try to put your increment of software out into production where real end users can use it. You may also pair with the end user and observe your customer when inspecting the product.
Try ‘user experience testing during system development’
The sprint review represents a scheduled opportunity to inspect and adapt the product. This moment is at the end of the sprint.
During a sprint multiple pieces of the backlog will be completed. In order to receive feedback early and often I try to show every created piece of the product as soon as possible to the customer. More specifically, when new working software is available, I let users experience the software immediately.
Users may volunteer inspecting the product during the system development process. The development team grant access to customers in a production like environment. Also members of the development team should be able to assist users.
Having continuous experience testing within your software development process can lead to valuable software based on rapid feedback. It helps in delivering value as often as possible.
What’s your experiment?
In the end, it’s all about creating a solution for a real problem. When the described experiments are applied, the possibility of creating a value-driven environment increases.
I would love to know how you create customer happiness.