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.

Summary

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”)
The Significance of Product Backlog Refinement in Scrum Success

The Significance of Product Backlog Refinement in Scrum Success

Product backlog refinement, or PBR, is an integral component of successful Scrums. This process of continuously reviewing product backlog items, to ensure that teams know exactly what to work on in the sprints, cannot be done without. It keeps the teams and the product owner on track. To understand why PBR is critical, it is necessary to first understand the details of what PBR is, what we expect from it, and the strategic value it provides.

What is PBR?

Product backlog refinement is the process in which the product owner, ScrumMaster, and the development teams review the product backlog items and define the stories that they will need to work on during the immediate sprint. Epics or unclear stories are split apart into smaller stories and are detailed in this process, while unnecessary backlog items are removed. In so doing, the backlog items are analyzed in terms of how much time and work each one will require, and the requirements for each item are clarified. After the PBR session is complete, each story should be valuable and testable.

PBR is conducted in each sprint planning meeting to address the tasks for the immediate sprint. Thus, for each project, PBR is conducted at least as many times as the number of sprints. New Scrum teams, or those with sprints of more than two weeks, may find it useful to conduct more PBR meetings than the number of sprints in their project; additional meetings would be conducted outside of the sprint planning meetings, and these could compose up to ten percent of the teams’ time. The frequency with which PBR should be conducted is due to the volatile nature of Scrum product management. The completion of each sprint reveals more details regarding the product, which results in the need to alter stories — by adding or deleting certain aspects of the stories — and update.

Expectations from PBR

The process of PBR is conducted with the intention of thoroughly prepping development team members about the sprint’s tasks, such that the teams know precisely what to work on and achieve by the end of the sprint. It also is conducted to assist the PO in getting the top-priority backlog items ready for the sprint planning meeting. Essentially, product backlog refinement occurs with the purpose of clarifying each sprint’s tasks and ensuring that they are in sizable chunks that can be accomplished.

Each PBR session is intended to provide team members and the PO with opportunities to update their sprint tasks accordingly, while additional PBR sessions outside of sprint planning meetings enable them to work on detailing and refining a larger number of backlog items.

Vision and strategic value of PBR

Product backlog refinement assists in ensuring progress toward the project’s objectives. The process succeeds in keeping the PO and development teams on track toward the project’s main objectives, as it is a way for the PO, ScrumMaster, and development teams to maintain a clear vision of the sprint tasks, especially in light of product feedback, the emergence of new ideas, and changes in project needs — aspects that can occur throughout each sprint. Scrum product management involves constant shaping of the product, which necessitates redefining the backlog tasks in each sprint. PBR optimizes such redefining of backlog tasks, thereby preventing the PO and teams from losing sight of the work to be completed in each sprint. In so doing, PBR keeps the PO and teams on track during the project.

Not only does PBR keep the PO and development teams on track but it also provides strategic value in that conducting PBR prevents a number of issues from arising later on in the sprint. A main issue that PBR can help the PO and teams to avoid is delivery of stories that do not meet the recipient’s full needs. Without PBR, teams work on stories whose details are not clarified, leading the teams to complete the stories unaware of certain requirements. This results in a loss of time and effort. Another related issue that PBR can make avoidable is a volatile team velocity that results from running ambiguous sprints. If a PO and the development teams choose to forgo PBR, they also risk completing sprints where the stories they worked on were not the most valuable stories. Had a PBR meeting been conducted, the more valuable stories could have been noted and addressed accordingly.

Summary

The value and benefits associated with product backlog refinement are large, as are the consequences of forgoing the process. On top of the value it holds, PBR can be easily integrated into each sprint. Therefore, there is little reason to pass over this process that is critical to Scrum success.

[This article was originally published on ScrumAlliance.org]

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 }

Pin It on Pinterest