Hello world, please meet Gareth. He can be seriously unpleasant. Trust me, we know. But he is becoming more and more indispensable.
He will tell you clearly, without emotions, when your ideas are rubbish. He will certainly not hold back and he will give you the facts when your assumptions don’t hold up. He will keep validating that your business goals are reached. If not, he’ll let you know.
Always unblock YouTube
Gareth validates the Why, the reason certain functionality was built in the first place. He makes sure that the (business) goals are reached and keeps validating these goals. We all know that implementing one feature can affect another. This also has an impact on the success of the related goals.
Gareth loves business goals. He doesn’t want to talk about functionality. He wants clear assumptions like: the performance of feature x will be 25% better after implementing this change; feature y will decrease the usage of functionality z by at least 50% over the next 3 months, and so on.
Why we really need Gareth
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 us. How can we be sure that this new functionality has the impact the business needs?
We believe user stories and backlogs are too detailed and complex as an aid to communicating with stakeholders. We think it would be better to talk with them about goals and assumptions. What are the goals and how do we want to validate them?
We know the world changes, and so must our software. That’s another reason we need Gareth. It’s vital to know that your goals are still reached after changing parts of the software. Sometimes one feature makes another unneeded. If so, Gareth will let you know.
How Gareth works
We introduce validation as an extra dimension to an user story. We call it an experiment and it consists of:
Experiment: Name of the experiment
Baseline: What is the initial state.
Assume: Which impact do we hope/wish the software is going to have?
Time: What is the interval and period of the experiment?
Action: Which action does Gareth have to take when an experiment fails/succeeds?
Let’s describe an example:
As the owner of the hotel booking site,
I want the users to see the rooms with discount first,
So that they will be booked first.
The experiment could be:
Experiment: I want to validate that by showing the discounted rooms first, there will be an increase in booked rooms.
Baseline: Get the current number of discounted rooms booked per week.
Assume: There will be an increase in bookings for discounted rooms of 25 per week in the first month.
Time: 1 month.
Success: Send email to the whole team with congratulations.
Failure: Send an email to the Product Owner.
Baseline: Get the number of discounted rooms booked in the last 6 months.
Assume: After 6 months, bookings of discounted rooms have increased by 80%.
Time: 6 months.
Success: Send reminder to buy cake for the developers.
Action: Create an investigative story on the backlog.
Gareth will run these validations as often as described in the assumptions and take the appropriate action. It is a great way for a product owner to be sure the right things are being built and kept that way. This is what we want to communicate to our stakeholders.
It is also great for teams to see that not only code, but also business goals are validated continuously.
Are you interested? Please be our guest and try Gareth. Gareth is open source (GNU General Public License v2.0) so that we all can benefit. Do you want to contribute in any way? Please let us know! We are really looking forward hearing from you.
Get Gareth: https://github.com/craftsmenlabs
Stop starting with Scrum
Don’t worry: I am not going to jump on the “agile is dead and a failure” bandwagon. I do not want you to stop working with Scrum. I just want you to stop starting with it. A lot of companies realize something’s got to change in order to survive. Especially...
18.9.2016 | 2 Minuten Lesezeit
Impact mapping and continuous validation
There is always a reason for making software. Let’s rephrase that: there should always be a reason, at least from a business perspective. How else could our products have any impact? Whether we want to make an app that that seamlessly connects riders...
- Open Source
- Agile methods
25.11.2015 | 3 Minuten Lesezeit
After continuous integration there is continuous validation
It’s a funny thing to say that delivering business value is the most important thing when developing software. It doesn’t matter that a framework like Scrum is far from efficient, because we focus on value. We deliver business value. Working software...
- Software development
23.8.2015 | 3 Minuten Lesezeit
How assumptions are not the mother of all f-ups
The thing about trends is that they will come and they will go. So after the agile trend continuous delivery and devops are in line. I think in a way it is very nice to see that development craftsmanship practices are becoming more and more accepted....
13.7.2015 | 5 Minuten Lesezeit
DevOps, building on quicksand?
The management decides they want DevOps and Continuous Delivery. It is faster, cheaper and there are less people needed for the same work. So now DevOps and CD are set as goal for the whole company to reach in the near future. So basically engineering...
24.7.2014 | 4 Minuten Lesezeit
DevOps and Product Ownership
[This article was co-written by Miel Donkers and Niels Talens.] You could see DevOps as expanding the mindset, toolset and processes which started with Agile. Where Agile focuses on creating maximum business value as soon as possible, DevOps can help...
17.7.2014 | 7 Minuten Lesezeit
It’s all about the input
Garbage in, garbage out This is a pretty basic principle. But what do you expect? What are the odds that if you give poor descriptions of your vision and needs that the results will be as expected? 50/50? Maybe less? Within the agile community there...
7.3.2013 | 6 Minuten Lesezeit
A man went to the doctor…
“Hello Doctor, I have epicondylitis lateralis and I think we can fix that with Shockwave. Shockwave is a brand new treatment that is faster, cheaper and better than all the other methods. Everyone I know does it. Don’t bother looking that up for I’...
9.11.2012 | 2 Minuten Lesezeit
Velocity is not for you
A while ago someone told me they let their product owners participate in estimations. And I don’t mean watch how the team estimates but really estimating stories. I’ve heard about non-programming scrum master, projectmanagers, salespeople and architects...
- Agile methods
- Software development
7.10.2012 | 2 Minuten Lesezeit
RST Testing Training – James vs. Michael
I was thinking to get James Bach to the Netherlands because he has an interesting view on testing. I read a couple of the books he wrote, watched a presentation from him on video . I thought he has a lot to tell. Beginning of this year a new colleague...
22.6.2012 | 4 Minuten Lesezeit
Lean specifications, what’s that?
A lot of teams are changing to Agile. Usually they start bottom up with a development focus on getting agile. The testing is often late in the change process and testers are not that keen on this new process. This is quite logical testers don’t change...
6.9.2011 | 2 Minuten Lesezeit
Lean bells ringing at the hospital
Last week I was working at my house together with my father and we removed a wall to create a bigger room for the upcoming baby. While the last stone was removed he damaged his thumb quite badly. We needed to go to the hospital. As soon as we arrived...
18.6.2011 | 4 Minuten Lesezeit
Dein Job bei codecentric?
Agile Developer & Consultant (w/d/m)
An allen Standorten
Gemeinsam bessere Projekte umsetzen.
Wir helfen Deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Do you still have questions? Just send me a message.