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. We can all benefit from this. Software is eating the world so let’s be damn sure that the software is good. But is it?
Be honest. After the development of the first couple of versions. After adding new features for a while. What is the state of the product? Are the same assumptions holding up? Are your goals still the same? Did the world change? Or is it enough that you can deliver your software in a matter of seconds?
Often we think we are building software like this:
But we are doing this:
Let’s say we are still building the same crap but at least now we can deliver it faster and with fancier new tools.
Agile, continuous delivery and devops can make our processes and delivery easier. And we can do that in the cloud, with big data and microservices written in Elixir. But that is still only a part of creating software products. We have to look at software development as a whole again. Because that’s the only thing that really counts: making good products. And that does not only mean bug free or easy to deliver.
Why continuous delivery isn’t finished
The prerequisites didn’t change at all. With bad input and lack of validation the results are mediocre at best. It made my colleague Hylke Stapersma (@hylke1982 ) and me think about why continuous delivery isn’t finished and what we are missing. So we started experimenting with this. In the following blogs we will describe more of the technical journey. For now it’s about the concept.
Step 1: Stories that don’t suck:
Good story describes the goal a certain user wants to achieve with a piece of functionality (the why). It should be pretty functional. It works very well to add acceptance criteria (BDD/ATDD scenarios) in an early stage to fine-tune and make sure a functional validation is in place. Let’s say that’s all in order.
We now want to introduce another dimension to make sure we achieve our goals. We add something we called an experiment, which includes some assumptions, to an user story. These assumptions can be measured and will be automatically validated.
– And for me it is not about being SMART all the time. I’m definitely more of a DUMB guy. It is more about validating assumptions than the measurement in this case anyway.
Here is an example of a story we are using in our demo setup which contains both the BDD feature and an experiment:
Step 2 – 8: Do the magic: build and deliver the best software ever seen.
For a more indepth explanation of this model please check this blog.
Step 9: monitor assumptions.
If the results of the validation are under expectation, these result should have impact on the backlog. In theory the result of the validation is more valuable than any new feature you were dying to implement. To be honest, the story in which the assumption was made was highly prioritized.
So one of the first things we saw is that in contrast to unit or acceptance tests we now have the time dimension. Our behaviour tests run a couple of time in the continuous delivery pipeline but never when the software is in production. There’s no need either because there are no changes there. In the case of the experiment we have a starting point, our baseline, and from there we will schedule a periodic validation of the assumptions we made. We can validate as often as we want. Why ever turn them off?
Removing features is not a bad thing people.
If you find out that something is rarely used please do not be afraid to remove it. That will make your product leaner and your codebase cleaner (there is a song in there). Here validating assumptions can also be very handy. Because we can measure over periods of time we just set a limit and everything below that we have to evaluate. I would like to know if something isn’t as valuable as expected. Often by adding a new feature an older one becomes unnecessary. No problem. Just remove it and try again.
If you take a look at impact mapping you see that assumptions are a big part of it. Those are the things we often can make measurable. In our case add them to an experiment and validate. Impact mapping is a great way for us to gain insight in the many assumptions we make. If you don’t know impact mapping I can recommend the book by Gojko Adzic.
A story has to describe something that has value. But sometimes that value is easier to define than the functionality or the user. And what to do with some non-functional stories? I think we all have had experience with user stories that feel artificial. Like we can’t even describe a proper user for it. We just want to decrease the costs of operations with a piece of functionality for instance. Should we describe “ the members of the board” as users? It just feels artificial sometimes. I think in those cases an experiment/assumption could replace the story.
In the future we want to be able to also use information of tools like AppDynamics or Google Analytics. Those have so much information that will help the business in making good products. Performance and usage are definitely things that are key in that process.
So, in conclusion, contrary of an earlier blogpost of mine, in this case assumptions are not the mother of all f-ups. Assumptions are a step in completing the whole flow of software development.
We are currently implementing this idea and will share our findings and solutions in one or more follow-up blogs. Stay tuned!
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
Continuous Validation: Meet Gareth. He is seriously unpleasant.
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...
15.9.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
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.