Let's add some value (part2)
In the first part of my postings I talked about the disadvantages of breaking epics down into technical stories and why it is preferable to create real user stories which enable us to deliver real value in each iteration. In this part I´ll present objections that I have come across while talking with developers and product owners (POs) about ‘creating value in each iteration’.
#1 “We waste time and money by developing things which we do not need anymore once we finish the envisioned feature.” Sometimes we have an ideal scenario where we want to develop a big feature which can be broken down into smaller features that each both generate real value and also naturally brings us closer towards our goal. But sometimes the only way to generate value early is by choosing sort of an alternative path which does not directly work towards our envisioned goal. Imagine a typical project where our goal is to make data which is currently managed via Excel available for customers in an online tool. But since the data is very complex it is not that simple to implement a good solution for the data administration. So the team offers the idea to implement a CSV import as a fast possibility to get the data into the system. The PO however rejects the idea, reasoning that the import functionality will not be needed anymore once the data administration is fully implemented. As you may guess I did not make this scenario up. The PO I talked to in this situation just saw the extra work which did not bring the project significantly closer to his original goal. My main point was that there was a chance, that we would not even need the data administration once we had the CSV import since the users could go on managing their data with their accustomed tools. But as it became clear that this was not an option I argued that the advantage of having a usable product very early would outweigh the extra cost of building the import feature. The end of the story: Up till today the data admistration still does not cover all relevant cases and many parts of the data are therefore still managed both in the new online tool and in the old Excel sheets. This might of course be a sign, that the import feature would also never have covered all the special cases but it would have been usable much earlier. The users waited over half a year for a usable feature because building the data administration took that long. The lessons we should learn: - Having a usable product early is worth some extra effort. - An interim solution may prove to become a viable long-term solution.
#2 “By starting with a small and simple implementation to solve problems early we can not get to a sophisticated final solution.”
Of course it is challenging for a team to build software which scales from a small solution to a large complex system which is still consistent. Therefore the big vision presented by the PO and future requirements which are already known should always be considered when making technical decisions. But if we are always worried about developing the perfect system we must be careful not to produce an overengineered solution which does more than we really need. Features which do not generate value are waste (see lean manufacturing) and while high code quality generates value by ensuring expandability and maintainability, no one needs artificially bloated solutions. Also adding new requirements for a ‘complete’ product which was specifically designed to solve one epic story, can lead to more problems than adding requirements for a software which was developed step by step from the start. I think the fundamental misconception behind this objection is the notion of software beeing eventually finished. Because if we have a “final solution” in mind we automatically think that we can define all its requirements and based on that a perfect plan. If such a perfect plan is possible for your complex problem: do not use an iterative approach!
#3 “Only the complete feature will be adapted because partial solutions do not add enough value compared to existing solutions”
This may of course be a valid argument from the PO, especially from a marketing perspective. Often enough I saw projects where a technical approach was chosen for a feature because “we can not deliver parts of it anyway”. If our product can not go live after an iteration we can only generate virtual value. For example by providing a usable version for a small group of test users (beta version). Early feedback from real users should be valued highly! Despite everything we should always be able to potentially go live because the situation may change or we may even find a partial solution which would add value for some users at least. But this is only possible if we provide real features after each iteration instead of technical parts which only function as prerequisites for real features in the future.
#4 “My problem can not be broken down because it is just too complex”
This is the last objection I want to talk about. It is the one I hear the most and therefore it is also the one which inspired me to write this whole thing. I admit it… sometimes it may just not be possible to build something that can be used by someone to solve a real problem after one iteration. But my point is that we come to this conclusion much too fast most of the time because it is easy. By telling ourselves that the thing we are building is just too complex, we make it easier for us to fail. We do not have to commit to deliver anything because we already convinced our stakeholders that it is not possible. If the whole project takes longer than expected: “Well, we already told you that the task is very complex”. Agile was invented to tackle complex problems! Great people all around the world use agile methods to solve things which are likely much more complex than the problem we are working on right now. But if we are not able to deliver value, we are not agile.
If we want to prove that agile frameworks really do offer a great benefit for our business we should always strive for the maximum satisfaction of our stakeholders. Let us surprise our customers by delivering working software instead of explaining why they have to wait some more time for it.
Finding ways to generate real value early may be hard but it is worth the effort.