Send to Kindle

Feedback loops for successful self-organizing teams

Acknowledgements: A special thanks goes to Mr. Thomas Goetz (the author of "Harnessing the Power of Feedback Loops", Wired's executive editor & TED speaker) for mentioning this blog post Also thank Ms. Debra Dishberger for proof-reading, and encouraging me to add some more paragraphs to share the concrete examples of how our team has implemented the activities and indicators that give feedback.

Thank you Wired Magazine for mentioning my name on the USA print edition (19.9): (Next page is here)

A feedback loop is a continuous cycle of self-improvements that loops through collection of data, evaluation of the data with respect to the project’s objective, modification of the behavior of the system, then starting over with collection of new data. Wired magazine had a recent article titled, “Harnessing the Power of Feedback Loops” (Wired 19.07, July 2011). The article presents a number of successful examples of applying the feedback loop principle to change the behavior of people – for example, getting people to observe the speed limits inside school zones. Central control and policing are costly and often turn out to be ineffective. Successful feedback loops let people control themselves just by providing the compelling information on how they are doing.

While I was reading the article, I soon realized that establishing effective feedback loops is crucial for agile software development practices such as Scrum. Software development is a creative process. The product being designed is so complex, and the attempts of one person – the project manager – to control the details of team development activities often result in unsuccessful project outcomes. Instead of having the project manager look after the behaviors and the activities of the team, Scrum and many other agile software development practices urge the team members to be self-organizing and self-improving. The team should move itself towards project’s goals that are set by the voice of the customers, typically coming through the product owner.

In a sense, today’s business environment is filled with constant feedback owing to information technology. Emails from customers flow in throughout the day, and some even are broadcast to the whole world through Facebook and Twitter. Competitors acquire information on what others are doing and come up with better solutions. Business landscapes are changing rapidly and fresh business plans may not look so promising just a few months later.

Instead of following a rigid one-year blueprint, software projects need to be evaluated more often and adapt to changing wish lists and priorities from the customers. Agile software practices divide the development cycle into much shorter iterations (typically 2 to 3 weeks) than conventional processes, and focus on the delivery of the customer-centric, end-to-end solution of one to few features per iteration. The result of an iteration must be a product having sufficient quality such that it can be potentially shipped to the market next day.

Agility is a challenge to the team to be self-aware and self-improving instead of being supervised by “the boss”. The team is responsible for working efficiently, reducing the risk, and ensuring the quality. The status evaluation should be real-time and improvement should be immediate. With our products becoming more complex, it is not realistic to rely on one full time supervisor to take control of everything.

On the other hand, there is a danger that the team just disintegrates once it loses a supervisor. Some developers tend to focus only on small tasks that they volunteered to complete. How the small task fits into the big picture is often ignored, creating a risk that the product will be ineffective from the customer’s point of view. Some developers fail to pay attention to the work of other team members or neglect to share their work with others, creating the risk of halting the project when one of the team members become unavailable.

It is not easy or even a good idea to try to change the personalities of the team members. Instead, the challenge of changing behavior should be on how to provide a compelling feedback without asking the team members to do extra work to write “status reports”. Scrum implements the feedback mechanism through the framework of team activities (i.e. face-to-face discussions) and automated data collection.

The activities that give the team feedback:

  • Daily meetings: 15 min daily meeting for each team members to tell others about 1. what they have been done since the last meeting, 2. what they are going to do until the next meeting, and 3. what are the roadblocks. The team members get feedback from their peers.
  • Iteration reviews: At the end of the iteration, the team gives a software demonstration to the product owner. The product owner gives feedback on the quality of the work, and sets priorities for the next iteration.
  • Retrospective meetings: At the end of the iteration, team members reflect on the iteration. What went well, what needs to be improved and what puzzled them are discussed. Action items to improve the development process are defined.
The indicators that give the team feedback:
  • Sprint backlog: At the beginning of the iteration, called a “sprint” in Scrum, the team decides on the tasks they commit to complete during the iteration. The items are typically listed on a whiteboard using sticky notes. The tasks are grouped into categories: 1. Not done, 2. In Progress, and 3. Done. The visual representation of the Sprint backlog gives the team feedback on how much work is committed to for the iteration, how much work is already complete, and how many tasks are on table at any given moment. It is important that the team has agreed criteria to mark the task done to ensure the quality of the work. It should be noted that Sprint backlog is vital in capturing the state of the team; however it works only if team members update the backlog items promptly.
  • Automated testing suite: Every time the developers submit software modification, the predefined tests are run automatically. Failure of tests is immediately communicated to the team members, and the team is committed to fix the failure before resuming any new developments. The report may include the run time for completing the test giving feedback on the performance of the software.
Every software project is different and so are the problems we encounter in implementing the feedback mechanism into a real development process. The team I work as one of the developers has about 30 members (including developers, portfolio owners, commercialization, and management) distributed among France, Norway, and USA. The majority of the team members joined after the merger. The original team was driven by Scrum for a few years, but the new team members had more background using Extreme Programming.

Our team is fortunate to have a passionate product owner and a product analyst who know exactly what the clients want. The developers owe them so much in getting straight feedback on the quality of the features implemented. They also bring the story from business conferences and client meetings back to the team. The feedback energizes the team and offers clear direction for future development.

The time zone differences and the large number of team members make the collaborative activities challenging. Project meetings need to find that thin window of shared business hours between Europe and USA. It is not effective to have daily meetings among over 20 developers. Therefore, the team is divided into several “feature teams” that is composed of multi-disciplinary members in order to develop end-to-end solutions from the user’s viewpoint. With some exception due to resources, each asset team is collocated for efficient collaboration. Scrum daily meetings typically are held within each asset team. I observe that the daily meeting is often followed by collaborative activities among fewer developers to solve actual problems. That is a good indication that the feedback at the daily meeting has ignited collaboration between team members.

We are no way near the perfection in our practice of Scrum. Scrum encourages us to always seek a better way, adapting to the business objective, and to the organizational and resource constraints that are unique to each organization. Instead of being trapped by the formality written in the textbooks, we try to transform the principles into activities tailored for own purposes, measure our progress, and improve again and again. Feedback loops are one of the most important principles to understand so that a self-organizing team may find its way to a business breakthrough.

Dr. Daigo Tanaka, Certified Scrum Professional & Certified Scrum Master

Original post: June 24, 2011 | Last updated: June 24, 2011

Previous: Bookmarklet to translate selected texts
Next: Coffee shop hangout with remote friends
Read more

comments powered by Disqus