Eric Ries is brilliantly teaching us how to deal with uncertainty in the business world. It is about time to take advantage of these Lean Startups techniques and learn how to apply them to the whole software development process, not only for Startups.
Product Backlog no more!
"You gotta start with the customer experience and works backward to the technology. You can’t start with the technology and try to figure out where you are going to sell it." (Steve Jobs, WWDC 1997)The Pareto Principle, unfortunately, has being fully applied to software development. In fact, still today 80% of the developed software is being wasted (CHAOS Report Standish Group 2002). An enourmous amount of money. We should develop software only after making sure that will be used.
It is very common in software projects not to know who the end users are. Is the Product Owner of your team a real user? Or are they only intermediaries? Only the end users can somehow clarify to the development team what they want to use and how they want to use it. Only in a very close relationship with the end users the right features can be revealed.
The "Build-Measure-Learn" cycle, defined for Lean Startups, should also be applied for the software development process since the beginning. In practice this means:
Always having the minimum amount of tasks in the Task Board, just enough to support the next conversation with the end users. (Build)
Measure closely the production environment results. How the end users are actually using the features that have been developed. (Measure)
Stay completely open to the new directions that the end users will reveal while using the software. Avoid having a Product Backlog already predetermined, preventing the natural flow of the software needs. (Learn)
Figure 1: The Build-Measure-Learn loop from the Lean Startups.
Even for very big and complex applications, it is when is more important to avoid waste. The first thing to be done is divide the big and complex application in a lot of small independent projects, which can be focused and managed in a more accurately and realistic way. After that, clearly define who the end users are and bring them as close as possible to the development team. When the software projects are simple and small, it's much easier for the users to absorb the business concepts, understand the technical needs and provide accurate feedback. As well as much faster and cheaper for the development team to produce the right results. (Further reading: Mini & Lean Applications)
"(...) And some mistakes we made by the way. Some mistakes will be made along the way. That’s good because at least some decisions are being made along the way. And we’ll find the mistakes and we’ll fix them."
(Steve Jobs, WWDC 1997) R.I.P. :_-(
A Method to Develop Uncertain Software
Figure 2: The Agile Development poster adapted for the Uncertain Software
Agile Development is undoubtedly a major step forward for humanity. But even with the Agile methodologies and tools, there is still too much waste, too much backlogging, too much repeated documentation and too much planning in software development.
The Agile Development process starts with building the Product Backlog. However, the Uncertain Method starts the development process defining the Minimum Viable Products for the application.
To identify an MVP it is necessary a lot of knowledge about the users (and customers) of the application, otherwise the software will never be viable (Read also: Defining your MVP). It is very common Product Owners having a hard time to minimize and prioritize requirements. They usually want everything to be done, and urgently. Not rarely a Product Backlog has several items with the highest priority. Even if they still think that everything can be done, the development process can be facilitated by identifying which feature they want to be the first immediately delivered, that means, just put the highest priorities in an order and select only the top one. The goal is to give a starting point to the development team. From there, the next priorities should be defined from the results of the interviews with the end users.
I totally understand that almost every feature has external dependencies. It is difficult to isolate and develop them independently. But if the development team can simulate (mock-up) the external dependencies and focus on each MVP separately, the prospects become much clearer and new possibilities of implementation easily opens up. The advantages are enormous. In fact, what usually happens is that several of this dependencies will not need to be implemented anymore because the plan normally changes when you start to dialogue with the end users.
"It is necessary to deeply understand the essence of a product in order to strip away the non-essential parts." (Jonathan Ive, Apple's chief designer)
Each development team should focus on its own MVP and start working with the first prioritized feature. A Task Board can be used, Stand up meetings, retrospectives, etc, but the most important thing is to deliver something as quickly as possible in the production environment, so the end users can personally manipulate the software and the Build, Measure, Learn loop can run the most efficient possible.
Non-systemic approaches are very helpful, like low fidelity prototypes or any other User eXperience practice. But keep in mind that an end user interview in front of the working software is priceless to a developer. The psychological atmosphere that is formed in a moment like this provides unique insights to the developer with so much valuable information that no documentation and no intermediary can possibly describe it.
Figure 3: The Agile Manifesto revised for the Uncertain Software
Once users are already satisfied with the current MVP, it is time to start the next one. The relationship with the users at this time will probably be much more fluent. It will be easier to identify what they want next. And often they don't care so much if the software is super flexible and adaptive, sometimes even if it has some minor errors. What they normally prefer is a software that has personality, something that makes them say "That's cool!".
No Rights Reserved. Please copy us!
