Getting it done is one thing, but getting it done on time is another thing altogether. The line between releasing something too soon or too late is quite blurry. There are many factors that determine when the product is ready to be released. This does not just apply at the first launch. This decision must be made when we launch every product milestone. Let's hold onto this thought for a moment and look at how the software development paradigm has shifted from a waterfall mindset to Agile.
We already saw in earlier chapters that one of the failures of the waterfall model is that the product gets stuck in development for too long. By the time we launch the product, any chance of responding to valuable feedback is lost or becomes too costly. The business scenarios have changed, the feedback loop is longer, and it's extremely difficult to respond quickly to feedback. With Agile, the idea of shorter releases is one of the crucial drivers. How soon can we release something to get feedback? The intent of shorter releases (and shorter Build-Measure-Learn loops) is to fail fast. While the sentiment is commendable, the implementation has some gaps.
Failing fast was meant as a way to test our riskiest propositions first and learn from them. It was not meant to hasten up our effort without thinking through the outcomes we expect from our effort. It was not about mindless speed, with an intent to fail. The problem, as with any other idea, is in how we choose to interpret and apply it.
We have translated fail fast as, "Let's put something out there real fast. If we fail, then we start over." Ideally, a short Build-Measure-Learn loop enables software teams to conserve their resources, and not waste much effort building stuff in advance. However, that works only when we know what we're validating. We need to define our riskiest propositions and our expected outcomes. When we don't define our outcomes first, we may be unable to learn anything of importance from our product. Product development cannot become about speed alone, without an understanding of outcomes. Fail fast should not trump learn fast.
This also impacts our process of working, such that we want feedback along every minor step of the way, without knowing it's value; for instance, showcasing every user story that is completed. I have been part of many Agile software development projects where stakeholder showcases were conducted religiously. A typical first iteration showcase of an Agile software services project might involve showcasing the 'Login story.' The stakeholders are often quite fired up about the first showcase. In my experience, we get a lot of feedback on the placement of the submit button in the login screen. We spend quite some time in discussion over whether to name it "Submit" or "Sign in" or "Login." Been there, done that!
We all feel super good about having done our bit in building iteratively, receiving feedback, and having involved business folks every step of the way, but is it of any use to anyone? Logging in to an application is a task. It is a pre-requisite to accomplishing anything of value inside the application. Logging in by itself adds no material user value. We have all probably written an "as a user, I want to log in, so that I can access the application" story at some point!
OK, I'm being a little unkind here. The intent of these teams has always been noble. Software teams are actively striving to get feedback at every step of the way, but the implementation of this is flawed. We need to go after valuable feedback, and not just any feedback. We cannot hope to get valuable feedback when we don't showcase anything of value. There is really nothing of value to learn from a login story. The login functionality by itself cannot be launched as a product. In fact, if anything, we probably wasted about an hour's time, in an iteration showcase meeting, discussing the merits of renaming the "Submit" button to "Login."