Loading…
This event has ended. Visit the official site or create your own event on Sched.
View analytic
Tuesday, May 23 • 15:15 - 16:15
Building the Right Things Right? We Can Do Both With Continuous Business Goal Validation.

Sign up or log in to save this to your schedule and see who's attending!

Feedback form is now closed.

There is a lot of focus on software craftsmanship and automation. We can build and deploy software very quickly with current technologies. However, it’s the post-deployment stage that worries me. How can we be sure that this new functionality has the impact the business needs? In other words: are we building the things right or are we building the right things? We think you can do both with continuous business goal validation.

When making software products we made a lot of assumptions about how functionality will help us in reaching business goals. But we rarely see those assumptions being validated afterwards. We mainly run back to the backlog and start on the next feature.

We found out that there is much overlay with impact mapping. In a sense continuous business goal validation is the automation of impact mapping. Where impact mapping is a great way to define products, business goal makes sure your assumptions are being validated. Not once, but as long as the functionality is alive.

By measuring those assumptions, not only once after going live but automated and over time, when the software is being used we can really learn a lot. Do users really use this functionality as expected? Did this new feature affect the usage of an older one? In short: did we make the right assumptions? This way you can keep your product as small as possible but most effective. Remove or change functionality and keep waste to a minimum. 
This is what we call continuous business goal validation…or is it validated learning?

How to:
While setting up projects or define features in ongoing customer relations setting up impact maps and/or business canvas models are a great way to have a concise view on what the expectations of the software are. This should be the start of any phase and should be done in a cooperation between business and IT or customer and supplier depending on the situation. Afterwards it is clear which problems we are going to solve for who and not the least: what are the goals we want to reach?

Business goal validation then makes it possible for a product owner to clearly communicate with stakeholders about the business goals and the results of the validation. “Yes we assumed together that the effect of this was X but we found out that this assumption was wrong. Let’s find out why and get it right”. It clearly helps the stakeholders and the product owner to define the right functionality and validate these continuously instead of detailed discussions about functionality.

We will explain how to go from inception, objectives (input-output) and outcomes and validate if goals are reached. Which choices are there to be made if a measurement fails or passes? We will show that this is an ongoing process where customers and suppliers continuously validate if they are really building the right things right.


Speakers
avatar for Hylke Stapersma

Hylke Stapersma

Software craftsman, codecentric Netherlands
Hylke is a software craftsman who is working as a consultant for codecentric and he is a contributor and maintainer of a small number of open-source projects. He is passionate about sharing ideas and knowledge on everything related to software development and delivery.
avatar for Niels Talens

Niels Talens

Agile Consultant, codecentric AG
In the end there is only one thing that really matters in software development: delivering useful high quality software. Things that certainly can help in this matter are agile, Scrum, automated testing, continuous delivery, devops and so on. | | The bigger picture. That’s what... Read More →


Tuesday May 23, 2017 15:15 - 16:15
Ballroom D 1st Floor

Attendees (35)