I was visiting the Agile By Example conference in Warsaw last Tuesday and had some interesting insights thanks to that. This post is for those who have some familiarity with Agile and Scrum.
I met Paweł and Pjotr from Reef Technologies, a software house which is applying both Agile and Lean. My conversation with them was about how they get more requests from startups, which ought to do something to validate their customers needs before putting Reef to work on the actual product.
We also discussed the quality of code as I made a bold statement that definition of bad code is mostly determined by use. If code is used, it will be improved as customers will suffer from its bugs. Bad code is code that goes without use. This code is wasteful and can even slow a team down as the dead use case might have to be tested or even worse, is a detractor for a customer as the feature destroys value instead.
It made me realize that an Agile way of working makes it far easier to implement Lean Startup principles. On the contrary, doing Lean Startup without Agile as a fundament will probably not be getting anywhere, so if a company is not working iteratively, they will have a hard time implementing the Build-Measure-Learn feedback loop.
It struck me as so obvious that it also makes it simpler to implement Lean
Startup. Most Agile teams will put tested code into production and call it done. However, by expanding the Agile process to force the teams to validate use, the development process starts to become Lean. The simplest idea is to just add ‘validate’ as a column to the Kanban board. If software is not being used, the feature will have to be deleted.
Once you do that you’ll force the team to implement code which measures the use and that would yield to the question of how much usage will be enough to
validate it to stay in the product.
However, this simple form will cause new problems. Sometimes it might take a
while before customers will find the new feature, which will cause the tickets
to stay in the Validate column for too long and now your sprint velocity will go down.
Alternatively, you could add Validation ticket types to a sprint to make sure
stuff will be checked in the next sprint and code will be deleted once it turns out that the customers don’t use the new feature. However, here again you might just have a false negative, so be careful to do some user research to the potential need before writing the user story.
This could work great for adding new features, but it might not be enough if a
team has to find a new business model * and * product as their innovating on
both ends. That would require an overarching plan and measure of progress.
Our product, Dispatch, allows you to log the riskiest assumptions and set up
experiments to validate those. It was designed for the Lean Startup method, but also allows you to link the actual work done by your Agile team and the
ticketing system you might use for that. Here’s an example for that:
So if you’re working Agile, but either your customer or your business colleagues are not sure about the actual value of the feature or user story, perhaps Dispatch can be of use to you.
Check it out:
https://firmhouse.com/products/dispatch
