Get certified - Transform your world of work today


Agile Feedback

The problem is feedback

7 April 2016

Essentia Essien
Attoway Incorporated

The vision for Agile feedback is to rejuvenate communication within the Agile Community of Practice (CoP) specifically, and the organizations with whom they serve in general. Feedback problems may be counterproductive work behaviors directly related to deficient leadership qualities in engaging organizations.

The problem with Agile feedback

Feedback is fact validation to the Agilist, as functional test is fact validation to the coder. In everyday conversation, some communicators habitually ask, "You know what I'm saying?" This question is usually a de facto plea for feedback in the middle or at the end of a conversation. Yet adept listeners continue listening; at best, they nod because their central nervous system is not wired for high-probability detection. Call it a physiological bug, but some humans are incapable of exceeding the absolute threshold where signals are transmitted to the central nervous system in order to decide whether to respond. As a result, persons in this category spend longer periods struggling with the decision to respond or not to respond.

In the traditional mindset, we spend time in the sandbox (aka in-the-box-thinking space), writing hundreds of lines of code without the iterative functional validation of the code. We build queues even for integration tests, thus creating the potential for a high-impact system risk when we decide at the eleventh hour to conduct regression testing. We put a burden on code refactoring and peer code reviews. Both should no doubt provide feedback; however, we need synchronous feedback. Good projects have failed at the 90 percent-to-complete marker due to inadequately synchronized feedback loops.

Code refactoring is tedious, but it is more tedious to double the refactoring efforts. It is also frustrating to write unverifiable code, perhaps due to servers that are down. In comparison to the Agile feedback predicament, a hardware bug and a developer's uncertainty are probably containable. There's some level of expectancy that the test will be validated when the server is debugged, and it's up and running. This is more manageable than an open-ended communication loop skewed by persistent listeners. Listening is not only a nice-to-have skill, it is a relevant skill. But after listening, people should make certain to comment on what was heard, especially when erroneous views are communicated, to help the source improve upon notable errors. In other words, analyze the reason for the views by focusing on the what, the why, and the when of the main point of the conversation. Follow the Kaizen principle.
  • What: What really is the main idea of the conversation? It could be time driven or business-value driven — customer, channel partner, shareholder, or employee's need.
  • Why: Why is the idea, not the conversation, relevant? If the conversation is relevant, we need relevance of the issue.
  • When: When will the idea deliver the most value? Finding dependencies could guide decisions to maximize value and curtail waste.

Using the presidential metaphor

In some ways, leadership-facing Scrum coaches are to software development what the president is to nation building. Not one president had presidential experience prior to taking office in the first term, yet most address the nation as they take office. I view this as routine feedback to the electorates embedded in the presidency. Relatively few Scrum coaches have deep experience with managing human behavior, because many evolve as developers. Even if they had human behavioral experience, as they move from one situation to another, chances are high that unique unconceivable situations await. The start-up routine requires that they provide a road map, observe, ask questions, get feedback, and kick off improvements soon.

System transformation should happen fast given that Scrum takes teams out of their comfort zone; it is a disturber of the status quo in order to elicit desired behaviors that prevent change agent complacency. Change agents should push for constant feedback to determine their location as well as system location on the change scale, such as the Capability Maturity Model Integration. From competing interests, to balancing organizational confidentiality with information sharing with consultants, to low probability detection, the Agile-Scrum coach may be caught between the crossfire of isolation and unpredictability.

Getting back to the president scenario, presidents may be trained to speak, walk, and respond to comments in a presidential manner, but they should also fit into Fiedler's contingency model. Fiedler suggests that leader effectiveness derives from a person's natural style of leadership. Fiedler's model corroborates the creed that leaders are naturally endowed. They are born not modified with hemostasis aiding the stability of acid value versus alkalinity (pH value) to produce the balance between internal and external response to stimulus. Individual traits, inherited character, or distinguished quality influence behavior, and behavior defines ways by which a person or animal acts due to the pH value in the brain. Great presidents emerged naturally. By the time they acquired hands-on experience, they were constitutionally bound to leave. Scrum coaches could do better without system failure on feedback.

Nurture nature

A nurturing environment is critical for all. Agile leaders should explore their natural tendency for high probability detection. They should nurture consistent pH value in themselves as well as others. It's the physiological balance to respond adequately to stimulus, communicate, and provide feedback. Leaders succeed with consistent feedback, whereby a complete cycle of communication and coding and decoding is long lived and adopted consistently. That is, speaking to be spoken to rather than speaking into a vacuum in which an echo is impossible. For example, sprint review meetings are conducted in today's "Agile" environments without understanding the why of the sprint review. Sprint review is designed to elicit feedback to determine whether the product behavior achieves customers' acceptance criteria as understood by stakeholders, including product owners, product managers, and the customer or the customer's team. Our greatest wish in the software development life cycle is that the customers know what they want.

Another critical feedback loop is the Daily Scrum meeting. The industry attraction to techno-babble is driving the use of the phrase "high bandwidth" to mean team capacity or velocity. Although bandwidth expresses a person's energetic capacity or mental resilience to handle situations, in the Agile-Scrum CoP, high-bandwidth communication refers to face-to-face communication that enables immediate feedback. Face-to-face communication is the most powerful promotional tool with the highest closing rate in marketing. Daily Scrum that is well done synchronizes multiple product teams' efforts by using face-to-face communication to manage dependencies effectively, accessing tactical planning advantage, and establishing each day's pulse for hyperproductivity.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 2.7 (3 ratings)


Okokon Essiet, CSP,CSM, 4/7/2016 7:00:07 PM
Very good article great insight from author on the need for timely feedback.
Essentia Essien, CSP,CSM, 4/8/2016 10:55:43 AM
Thank you for your comment.
Kent Beck, in his view on optimism and software hazard, concludes that feedback is the cure.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up