Understanding the feedback in ‘The Feedback Loop’

Understanding the feedback in ‘The Feedback Loop’

What is Feedback?

Feedback occurs when the return of information concerning the results of a process or activity takes place (http://www.thefreedictionary.com.). This event is part of a chain of cause-and-effect that forms a loop onto itself. Feedback comes in two forms: good feedback and bad feedback. Without feedback, the Agile process of inspection and adaption could not occur. An Agile process thrives in an environment with constant change. Because of this variability, adaptation and adjustment points are made on a regular basis. If we can shorten the amount of time elapsed between these calibration points, then we can more quickly adapt to these changing realities. In short, this is the feedback loop in our process and environment.

Types of Feedback

There are, however, different forms of feedback, which are listed here for the reader’s reference and throughout:

  1. Communication feedback (e.g., onsite customer, open team workspace, ubiquitous language)
  2. Technology feedback (tools we use to give us quick feedback, like Cruise Control, mocking, BigVisibleCruise, CCtray, Resharper, TFS real time compilation/warnings, and confirming that we use the right technology)
  3. Requirement feedback (when a customer need realizes in a demo or the production environment)
  4. Market feedback (to see how the market reacts to a new story/feature/module, frequent and numerous deployments)
  5. Analysis, design and coding feedback (e.g., pair programming, whiteboard mockups, code reviews)
  6. Defect and testing feedback (the quicker we find out about bugs, the quicker we can fix them, deploying often and always, test driven development)
  7. Operational feedback (process, methodologies, practices and how to improve them)

The quicker we can get these forms of feedback from the source, the faster we can validate our progress and adapt to the information received.

A company’s ability to deal with change and adapt accordingly to changing conditions will improve its competitiveness in the marketplace. Companies that struggle with a slow feedback loop will find themselves caught up in trying to solve problems that have already changed or are not important anymore.

Effects of a fast feedback loop

Having a fast feedback loop allows dominance of a company during market changes. For example, one of our clients using our health and safety management system had a deadline for submission of reports. Approximately 800 companies assigned to each performed various tasks and submitted reports showing the work completed. There were some features and latency problems that the client wanted to be fixed, and the deadline was one week away. We were able to get quickly the high-priority features added, and latency issues resolved three days into the week using our engineering practices, automated testing, and automated deployments. We went live before the deadline to get much-needed feedback on our changes in a real production environment. If we had waited until after the deadline, we wouldn’t have obtained the actual feedback from the end users re the added features, nor the feedback from an environment production perspective, since the client wouldn’t be using the system until the next deadline, which was months away. Using this feedback from deployed features in a production environment allowed us to make more improvements so that the next period time would go even more smoothly.


Being able to perform a full cycle of development from client request to production deployment in a few days helps ensure the company can quickly adapt to changing market conditions.

(This is an excerpt from the mini book series “Agile from the Trenches: The Feedback Loop”)
Transforming Agile Nay-Sayers Into Enthusiasts

Transforming Agile Nay-Sayers Into Enthusiasts

Agile is increasingly mentioned as the go-to method for product development, and given the coverage on agile, it appears that there is a consensus that agile is at least viewed in a neutral light, if not favorably. Despite this, there are adamant nay-sayers against agile. For those who are attempting to transition their teams into embracing agile, it can be difficult if a team member is resistant towards agile. This post serves to provide insight into the criticism that some may have towards agile, in order to assist those seeking to convert agile nay-sayers into enthusiasts. For those who hold an unfavorable view of agile, this post will detail the potential of using agile with customer insights to transform products, along with the top agile practices to adopt in order to maximize a product’s reception.Main Criticism Against AgileLack of Structure

A common criticism against agile is the lack of structure, especially in comparison to traditional methods such as waterfall. Indeed, agile is more open-ended and it embraces changes. That is not to be mistaken with chaos, though. Critics may misinterpret the lack of structure to lead to team members working on any number of tasks that may be irrelevant, and that progress cannot be achieved efficiently. Agile, in its lack of linearity and openness to quick changes, induces the opposite effect. It enables more progress to be attained during development, as multiple rounds of testing enable product features’ issues to emerge quickly and to be addressed immediately, resulting in a more complete product.

Rushes Into Development

Some may view the multiple cycles involved in agile to be a “rush” and that it undermines thorough and successful product development. Agile cycles consist of the stages of more traditional methods, but less time is spent on each stage within each sprint. This “rush” into the next stage is precisely what enables agile product development to incorporate so much user feedback into the process – and this incorporation of feedback results in a better product.

“Agile Fever”

Another main criticism against agile is the apparent “agile fever” that is sweeping across businesses and industries in the attempt to benefit from this method. This criticism is not unwarranted, for as is true with anything, too much of a good thing can be detrimental. With agile, it is important not to rush into implementing it merely because everyone else appears to be doing so; it is vital to thoroughly understand agile before adopting it, and even upon adoption it, the process should be tailored to each business individually.

Using Agile With Customer Insights to Transform Products

Agile, contrary to the main criticisms that exist, is an efficient method to transform products into ones that are well-received by the targeted customers. Each sprint in agile product development provides the opportunity to glean and incorporate user feedback into the next sprint. Not only is user feedback allowed to be a major factor in the product’s development, but agile also provides ample opportunity for product issues to emerge and to be addressed on the spot, before the final product is released. Under agile, the product is completed multiple times and assessed as such, allowing for it to be enhanced a number of times more than if another method were used.

Each sprint in agile product development can be viewed as a trial run, wherein user assessment is gleaned and addressed accordingly. Had the product been developed under a method other than agile, user assessment would not be obtained until the final product was released – by which time it would be more costly to fix the issues and to incorporate what users want and need from the product; the product’s reception and success would suffer accordingly.

Top Agile Practices to Adopt

To maximize the potential held by agile product development and customer insights, it is important to emphasize the adoption of certain agile practices, namely continuous integration and design review. Continuous integration of feedback results from, and fuels, constant effort to glean feedback on and enhance the developing product. This is vital in creating a more successful final product that matches or surpasses user expectations. Design review, the other top agile practice to adopt in order to maximize integration of customer insights into the final product, enables teams to review design stories with consideration of the latest product feedback; it poses the opportunity to plan further work on the product with the feedback in mind.

There will continue to exist agile nay-sayers who will not embrace agile, despite the lack of evidence for some of the main criticisms against agile. For those who are swayed by the potential held by agile to incorporate user feedback into the creation of successful products, there exists ample information for them to begin their agile journey.

{image courtesy: flickr/JD Hancock }
How Measuring Velocity Helps in Your Agile Journey

How Measuring Velocity Helps in Your Agile Journey

Measuring velocity is a useful way of determining how long an agile project will take to complete, by providing a rough estimate of the amount of work the team can complete in a sprint.  It is necessary to keep in mind, however, that as insightful as knowing your team’s velocity is, velocity is not a true measure of your product’s development.

This post will discuss what velocity is and the reason why we measure it, and why management is interested in higher versus lower velocity.

Velocity Defined

Velocity, in terms of agile product management, is a metric that provides insight into approximately how much work a given team can complete in a sprint.  Measuring velocity uses information from a completed sprint, so if your team is approaching its first sprint, you must know how many people will be involved in the project, the maximum amount of work each person can complete, and the total number of workdays in the sprint, in order to calculate the velocity.

Calculating velocity involves units of work that can be defined as hours or story points – a metric capturing the complexity of implementing a story – for example, and tasks.  Velocity is calculated by adding up the difficulty metric of every backlog task, such as stories, completed by the team in a given sprint with the units of work for those tasks.  This provides the velocity in terms of units of work per sprint.

Why Measure Velocity?

Velocity provides an estimate of how much work your team, specifically, can complete in a given sprint.  As velocity is calculated using the work of previous sprints and if everything remains constant – such as the same people are involved and the tasks are relatively of the same nature – then velocity is consistent.  If the team had a velocity of 30 story points per sprint for previous software development projects, then it can be expected that, all else constant, the team will have a velocity of 30 story points per sprint in the next software development project.

Velocity is useful in estimating the approximate length that a project will take, as well.  If the project at hand has 120 story points’ worth of stories, and previous sprints show that the team has a velocity of 30 story points per sprint, then it can be expected that the team will complete the present project in four sprints.

Higher Velocity Versus Lower Velocity

As velocity signifies an agile team’s productivity – the velocity value indicates that either the team completed fewer high-difficulty stories, or they completed many stories of lower difficulty – it is more desirable for a team to have a higher velocity than a lower one.  A higher velocity would indicate that the team is capable of completing more stories or high-difficulty stories, which translate into more progress towards the project.

It is worth noting, though, that when teams are measuring their velocity at the start of a project, the velocity value will not be as accurate as it will be for later sprints.  An underestimation when initially measuring velocity can result in a higher velocity later on in the project.  Similarly, an overestimation in initially measuring the velocity will lead to a lower velocity later on in the project, as the velocity is adjusted with each completed sprint.  As such, the velocity value that is calculated later on in a project may not accurately reflect the team’s productivity; their productivity could have remained constant, yet the change in velocity value may be due to an under or overestimation.

Velocity Is Not a True Measure of Product Development

As useful as measuring velocity is, an agile team should not rely on their velocity to indicate the progress of their product’s development.  The velocity is measured based on each sprint, and with each new sprint, new product features’ information is accumulated and added; this changes the stories and story points associated with the next sprint, so the previous sprint’s velocity is not necessarily indicative of the team’s work in the next sprint.  Many new features may have to be added or changed in the next sprint, so the nearly completed product of the previous sprint may actually be 40% completed, given the previous sprint’s feedback.  Even though the team had a high velocity in the previous sprint, product feedback necessitated even more work before the product can be deemed complete.

{Photo courtesy: Flickr/Jan-Hendrik Palic}

Pin It on Pinterest