Over at InfoQ Vikas Hazrati initiated a discussion about “feedback,” which he rightly identifies as a key element to agile software development.  Because Scrum and other agile methods operate in short, repeatable work cadences, they are structured to facilitate frequent points of inspection and adaptation. Opportunities to exchange information and provide feedback are built into this process on a daily basis—through the daily Scrum—and at the end of each iteration, during the sprint planning, review, and retrospective meetings. Agile techniques typically shorten work cycles to ensure that feedback is exchanged frequently. When a team stops what it’s doing to evaluate its product repeatedly, it’s harder for it to get off track and waste valuable time building the wrong product.

But, in Hazrati’s article, he highlights a slightly tweaked notion of “feedback” called “feedforward,” which was coined by Marshall Goldsmith. Ferguson suggests that feedback is too preoccupied with the past and looking backward, risking a negative fixation on what has already occurred. In my mind, this is just a semantic quibble, since it’s necessary to evaluate what has come before to improve going forward. Certainly, phrasing criticism in a way that looks forward to improvement and encourages the recipient is more productive than simply lambasting an individual’s performance. Regardless of what it’s called, there is profound value in looking back to shape the future.

What strategies do you use to make sure that the feedback you provide to teammates is positive and inspiring?

Posted in Agile
4 comments on “Feedforward?
  1. Dan Rawsthorne says:

    This is a cool distinction, and one that Scrum already handles, but probably by accident. Remember that Scrum calls them “inspect and adapt” cycles, not “feedback loops”. I often use the terms interchangeably, but this post may convince me otherwise, since inspections could include both feedback and feedforward…

    Thanks, Laz, Dan 😉

    Dan Rawsthorne, PhD, CST
    Transformation Coach

  2. Great Point Dan! 🙂

    I’ve heard coaches say ‘shorter the feedback’ loop, when maybe they mean inspect and adapt to change at the end of the sprint cadence.

    Glad I got ya thinking on this one.

  3. Laszlo,

    I think Vikas’ article feels more like semantic quibbling and comes dangerously close to the kind of nonsense that has crippled many a good education system.

    In a healthy team, discussion is open and disagreements occur and decsions get made after dicussion, based on the best information at the time. Mistakes still occur. We’re all human.

    The purpose of inspection or feedback is not to make the team feel miserable, or point fingers, it’s to provide a constructive and useful mechanism that the team collectively works on to avoid the unnecessary recurrance of that mistake. It’s part of growing stronger as a team and as a person as well.

    Vikas’ point: “The past is history, today is the present and tomorrow is an adventure.”
    I say, “those who fail understand the past are doomed to repeat it.” Going of on grand adventures and wishing everything better would be nice, and everyone would ‘feel’ great. Reality is surprisingly persistent, and sometimes simply focusing on the future is insufficient.

    Feeling bad should not be equated with feedback. Neither should self-reflection and failure analysis result in recrimination, and self-flagellation and finger pointing. If that is the case there is a sign there are much more systemic issues – a weak rebranding of ‘visualize a brighter tomorrow’ will hardly solve those. Sometimes, achieving goles takes continuous feedback and a lot of determination.

    To create a positive atmosphere these are some things I try:
    1. Be confident in your team, even when things are tough. They will surprise you, and themselves.
    2. They are bright individuals, treat them that way.
    3. Trust. Trust does not mean ‘let me do my job’. Trust means ‘Ask me anything. If I don’t know, I will tell you that I don’t. Let’s find out together’.
    4. Be passionate about what you are doing.

    Developers are kind of like professional atheletes of the mind. They come up against obstacles and use their ‘mental muscles’ agillity and stamina to solve complex problems. It’s not always a slam dunk.

    Just ask any sport team coach, watching past games against similar opponents is a great strategy to beating them. But building a good team spirit is honed by playing together, keeping things moving and knowing that we’re all working to the same goal.

  4. Thanks Mustafa –

    You’ve made some great points here, I’ll be interested to see if Vikas responds…

Leave a Reply

Your email address will not be published. Required fields are marked *