Feedback loops are one of those things we all know something about, from the annual review process, to the speedometer on the car we are driving, we are receiving feedback from the world around us that we can act on it. After looking at a typical Scrum based project, I will show how feedback is a critical part of agile by mapping it to the principles. Built into the principles there are feedback loops used to…
- find out as fast as possible if the project outcome will result in the expected benefits
- improve the project outcome
- ensure the software works properly as early as possible
- ensure minimal effort is expended on re-work throughout the project
- ensure that the software is built as efficiently as possible
- ensure that collaboration and learning is as efficient as possible
- improve the way the team works together
Feedback in a Scrum Based Project
Here’s a simple example of a Scrum based project set up. Within the sprint each story is worked on, then demonstrated in a show and tell at the end of the sprint. Finally there is a monthly product show and tell that gives a few key stakeholders the big picture view. Note: this picture purposefully shows the delivery stages being completed one after another to simplify the example described below:
Consider the increasing cost of receiving feedback from a product owner or user as we get further through the stages. If these people were to tell you that the process you have designed was completely wrong during the Story Acceptance Criteria and UI Design stage the cost of change would be minimal. If this feedback was received as late as the monthly product show & tell we would obviously see a high cost to fix (or throw away). There is an additional hidden cost of re-learning (one of the seven wastes) when we go back to the problem and re-analyse it, which can make things much worse if the feedback is slow. Building feedback in to this model to be early and often greatly improves the situation and helps us remove the poor practice of completing stages before seeking feedback. Now let’s look at the agile principles and how they have feedback built into them:
Agile Principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Projects range from high risk new ventures, typically start-ups, through to those with a definite need such as operating system upgrades. In business we typically release products into the marketplace with some degree of risk. A really dangerous situation occurs when we find ourselves assessing the risk incorrectly, we are so bought into our project or feature idea that we actually think it’s certain to succeed, until it doesn’t. We can get feedback from those people who are not customers to positively re-inforce the likelihood of success leading to more delusion. Ultimately we look to improve on uncertainty with factors like previous experience to lower the risk, however it is better to get real feedback. Agile has this principle of delivering to customers early in it to lower the risk of failure by getting feedback as soon as possible.
As a product owner you should always look to cut scope where there is risk in the market, looking for the real minimal marketable feature set. You can build on your success if it works and minimise loses if it doesn’t.
This feedback loop is used to find out as fast as possible if the project outcome will result in the expected benefits.
Agile Principle: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Within a project people are learning as they go, trying to lay out every requirement up front in great detail is very difficult due to the amount of complexity in most projects. Rather than assuming that we just need to try harder to nail everything down Agile shifts to allowing changing requirements. Further to this there may be feedback from the marketplace as a competitor adjusts their strategy, allowing this flexibility makes us more likely to succeed.
This feedback loop is used to improve the project outcome.
Agile Principle: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
By making sure that our software is fully working on real environments with real components we get feedback about how well the solution will work. Great disasters have been known to occur at the end of projects when a full scale environment is built for the first time and we learn too late that our solution isn’t performant. By delivering the working software frequently we can get feedback that it will work when released.
This feedback loop is used to ensure the software works properly as early as possible.
Agile Principle: Business people and developers must work together daily throughout the project.
In the past infrequent contact with business people would lead to the wrong product being built, then expensive and time consuming re-work occurs based on change control. By bringing the business and developers together we greatly shorten the feedback loops. The creation of the product owner in Scrum is a direct response to this problem.
This feedback loop is used to ensure minimal effort is expended on re-work throughout the project.
Agile Principle: Working software is the primary measure of progress.
Within waterfall projects we often see success in terms of the analysis and design stages being signed off on time, only to see disaster at the testing stage. Defects are found, users aren’t happy and the project spirals out of control. This is down to documentation being a poor substitute for feedback from working software. If you don’t have working software you are receiving poor feedback. This is an inefficient way of working.
Even using agile methods it can be very tempting to build up lots of screens that look like they are working without any real end-to-end scenarios truly being ready, this is adding great risk to a project even though it makes it look like progress is good. Using mock objects and having a lack of real data are typical culprits in this area.
This feedback loop is used to ensure that the software is built as efficiently as possible.
Agile Principle: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Here we see a feedback loop from people talking with each other. It is very difficult to get complex and large amounts of information across to people. In these situations our assumption that we have transferred 100% of our knowledge will be incorrect. From this post you will likely get 10% as you are reading, discussion rises to 50%, so we can see face to face communication is far more effective than documentation. When working through problems together this rises to 75%.
This feedback loop is used to ensure that collaboration and learning is as efficient as possible.
Agile Principle: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
Here we see a feedback loop from within the team, focussed on how they are working. This helps improve efficiency and promotes a feedback culture. This is done at “regular intervals” to highlight the importance of re-assessing efficiency regularly and not just once at the end of a project.
This feedback loop is used to improve the way the team works together.