Gaining Feedback, Building Trust


A powerful means of building trust and collaboration within a team is to gather around a table and tell each other face to face ‘this is how your actions made me feel’, both the good and the bad.

The importance of feedback

Effective software development requires a robust feedback loop.  Test-driven development gives immediate feedback on ‘does this code do what I expect?’ Continuous Integration gives early feedback on ‘does this code work with the rest of the system?’  And early incremental delivery gives quick feedback on ‘is this code useful to the customer?’

All this feedback is about our code, but as Gerald Weinburg famously said, No matter how it looks at first, it’s always a people problem” – so it seems wise to put at least as much effort into getting feedback about how well we are collaborating with our team-mates.  Compared to the immediate and precise feedback of a good test,  the standard annual performance review is too far distant from the behaviour in question to be much use in guiding iteration and continuous improvement.  We need something better.

How it works

We decided to adopt a variation on Jurgen Appelo’s 360 degree meetings.  The key point is to bring the whole team together, face to face around a table, to give direct feedback.  First, each person writes down items of feedback.  Each item:

  • should be addressed to one team-mate,
  • can be ‘went well’, ‘puzzle’, or ‘could improve’,
  • should refer to a specific incident, meeting or piece of work, and
  • ideally should be framed in terms of how that behaviour made you feel at the time.

We then go around the group, and each person in turn delivers one item of feedback, until they have all been covered.  After each item, the feedback recipient may respond briefly to ask for clarification; however the focus should be on asking ‘what can I improve?’ from the feedback, not on ‘defending myself’ from criticism.

As an example, recently a team-mate raised a ‘puzzle’ that I often seem to make arbitrary business decisions while coding, rather than raising the question with our business representatives.  Talking things through, we surfaced many underlying reasons why I tend to do this, including a degree of intellectual arrogance and a lack of trust.  We agreed that in future, we will at least share our decisions on slack, where business owners can see them.

How it helped us

The team agreed to experiment with holding this feedback meeting weekly for a month, after which we asked ourselves ‘should we continue?’. There was unanimous consent that we wanted to; what was interesting was that each person spotted different benefits from the process:

  • Lots of ‘went well’ feedback reinforced positive behaviours, which people might otherwise stop doing as they might not know they were valued
  • Positive feedback also builds confidence and satisfaction working on the team
  • ‘Could Improve’ feedback relating to a specific incident feels easier to accept, as it is about behaviour on a single occasion, rather than a general criticism of you as a person.
  • Rapid, small pieces of feedback lead to iterative improvements
  • When one person gives me feedback privately, then I’m inclined to think ‘that person has a problem’, and not look to change my own behaviour.  By giving it in front of the whole team, then unless anyone disagrees with the feedback as given, I’m more likely to accept that I should try and change myself.
  • Subsequent performance reviews are fairer, easier to write, and less surprising
  • By being prepared to accept critical feedback in front of the team, each of us makes ourselves vulnerable to our team-mates.  Doing this builds up a powerful sense of trust and interdependence between team-mates, which helps the team gel and thus collaborate effectively.

As team members switched onto other teams, they spread the practice of weekly feedback sessions across the TIM Group development organisation.  Having seen the benefits, I highly recommend this practice to any team working together closely.

Doing this yourself

Just as with retros, it can be helpful first to jog memories about what the team has worked on over the last week or fortnight.  Gathering in front of a task board, or collectively making a list of what has just been done, often helps people remember events they have feedback to give on.

We discovered that the vast majority of feedback (90%), was positive, and quite often a meeting concluded with no negative feedback given.  I think this is helpful too, and helps build up the trust and confidence which makes it possible for constructive criticisms to be made.  

We started out with all team members physically present in the room, however as our teams become more and more distributed, we soon adapted to use a hangout for some or all participants, which works fine.

We were lucky to start from a position where the team members knew one another, and had a reasonable level of trust and a fairly flat hierarchy.  It worked for us even though I was officially line manager of two of the others in the team; the reciprocal nature of this tended to reduce the effect of hierarchy, since my reports could equally raise feedback for me, which would go to my own line manager afterwards for my performance review.  

Everyone in the meeting should be ‘part of the team’ and committed to common goals, and everyone present should be open to receiving feedback – it’s fine to have a team lead or manager in the meeting, as long as they are also receiving feedback.

So if your team works closely together, I really recommend trying weekly feedback meetings.  They are very simple to run, and need only take as long as necessary based on the amount of feedback people have; the benefits in increased trust and collaboration are noticeable.

Software Craftsmanship ‘Round Table’ Meetings

Have you done something cool at work recently?  Or are you faced with a difficult technical problem or a team that just won’t gel?  Have you heard of a new technology buzzword and want to understand the implications?

Wouldn’t it be great to discuss it with a group of other software developers who care about what they do, from other industries and companies, who could bring different experience and fresh perspectives to bear?  Well, the London Software Craftsmanship Community is just such a group of developers, and the monthly round-table discussions (hosted at TIM Group) are that opportunity.

This Tuesday’s topics included ‘Is continuous deployment worth it?’, ‘How to test code with many collaborators’, and ‘Dealing with anti-ORM sentiment’.

When considering Continuous Deployment to production, it was surprising how quickly the group came up with so many different organisational impacts.  We need to understand who our customers are and what the true impact of any bugs would be on them.  The traditional QA role barely makes sense if the code goes through to production without any manual checks.  Partially-built features may need to be behind feature switches so the customers don’t see them until they are ready.  If the worst comes to the worst, we need to be able to roll back to a known good version very promptly, which means database schemas must be compatible between versions.

As the discussion progressed, it became very apparent that continuous deployment isn’t just a new deployment technique, but a whole new way of working, with implications for the entire company.  This may go some way to explaining why it is both so popular, yet so rarely implemented.

The diversity and strength of experience (and opinions!) that you will hear at the round table meetups are what makes them so interesting, frequently surprising and always worthwhile.

If you would like to join in, just join the London Software Craftsmanship group on , and you will be emailed when each new event is scheduled (normally a couple of weeks in advance).

The Seven Pillars of Agile – Self-Improvement

One in a series on the Seven Pillars of Agile retrospective.


To what extent do you agree that each statement below is true of your team ?

  • Continuous Improvement

    • We improve ourselves as a team over time

    • Our team supports individual self-improvement

    • We are always open to any new technology or idea that may help us achieve our goals

  • Intentional Practice

    • We read books that inform our work

    • We discuss how we work and consider opportunities for improvement

    • We participate in code katas / code dojos to improve our skills

    • We attend conferences and events where we can learn from experts in our field

    • We contribute to Open Source projects

  • Introspection

    • After any problem, we consider how we could do better next time

    • We hold regular Team Retrospectives, and use them to improve how the team works

  • Balance

    • I maintain motivation in my work

    • I have a sustainable Work/Life balance

    • We have regular slack time, rather than sustaining 100% effort continuously


The Seven Pillars of Agile – Technical Excellence

One in a series on the Seven Pillars of Agile retrospective.

Technical Excellence

To what extent do you agree that each statement below is true of your team ?

  • Considered Design

    • We consider multiple possible ways to satisfy each business need, and make informed choices to achieve the best functionality, usability, and long-term sustainability

    • Our designs allow us to move forwards at a steady pace, without unpleasant surprises or panics

    • We keep technical debt manageable, and keep our design under control without requiring excessive quantities of rework

    • We consider our users performance requirements for each feature, and strive to meet or exceed them.

  • High Quality Implementation

    • Our code is clear and simple – “Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away”

    • Don’t Repeat Yourself – we refactor when we spot repetition. Are your ‘C’ and ‘V’ keys showing more wear than the rest ?

    • Cohesive, Single Responsibility classes – we don’t have big, bad classes; and if we encounter such beasts, we trim them rather than allowing ourselves to add to them.

    • We don’t abuse inheritance – our subclasses are genuinely substitutable

    • Our collaborators Tell each other what to do, rather than Asking for information

    • Our tests are fit for purpose – expressive to read, flexible to change, and reliable to run



The Seven Pillars of Agile – Confidence

One in a series on the Seven Pillars of Agile retrospective.


To what extent do you agree that each statement below is true of your team ?

  • Code Confidence

    • Confident that the code actually meets the user requirement

    • Before passing a card on for testing , we are confident that the feature works properly under all likely use cases – not just “done”, but “Done Done”

    • There is no ‘actually, we also need to…’ or ‘other 80% of the work’

    • Zero Bugs process – don’t just fix the bug, fix the process to eliminate the source of the bug

  • Process Confidence

    • We use version control effectively to ensure that we know what we deliver

    • Our Continuous Integration system gives us clear, timely feedback on our code

    • Our progress is transparent to all members of the team and to outside stakeholders

    • We maintain a shared team rhythm, e.g. all being present for the morning standup


The Seven Pillars of Agile – Supportive Culture

One in a series on the Seven Pillars of Agile retrospective.

Supportive Culture:

To what extent do you agree that each statement below is true of your team ?

  • Learning

    • Everything we do, we treat as an opportunity to learn

    • We embrace the face that when we a task is completed, we’ll see more clearly what we should have done – and use this to help us see what to do next.

  • Space to Learn

    • We have a ‘No Blame’ culture

    • An appropriate proportion of slack time – to stop, think and experiment

    • We celebrate failure as an opportunity to learn

    • We take appropriate risks

  • Managing Conflicts

    • We avoid allowing conflict to damage the team

      • wasted energy

      • disappointment

      • individuals feeling disengaged from the team effort

    • We extract value from a diversity of opinion

  • Respect

    • I trust my colleagues

    • I feel trusted by my colleagues

    • Our team is trusted by the rest of the business

    • Individuals and the team feel empowered to tackle challenges themselves, without waiting for senior assistance or permission

  • Commitment

    • Each team member is always nudging for improvement

    • We are willing to ask for help, and to give help when asked

    • Whole Team Attitude (we all own the whole product)

    • Permanent Team Attitude (stability, shared history, commitment to a shared future)



The Seven Pillars of Agile and the Spiderweb Retrospective

As part of our efforts to continuously improve our team’s working process, we hold Agile Retrospectives every couple of weeks. A feeling arose in the team that our existing retros were getting a bit stale, so as the facilitator, I was tasked with running the next one ‘completely differently’.

I discovered Brian Marick’s Pillar Spiderweb Retrospectives; the spiderweb is nicely visual, and by asking participants to focus on specific areas, should help bring up possible areas for improvement that might otherwise escape consideration.

Probably the most crucial part of making these discussions fruitful is the initial description to the group of what each specific ‘pillar’ means. In order to elicit a comparable set of ratings and a productive discussion, it is critical to establish a shared understanding first.

Helpfully, Brian also wrote up sets of notes for three of the seven pillars on his blog, describing and giving examples of what they mean in practice:

To support discussion of the other four pillars, I’ve assembled some notes, based closely upon the descriptions in the Agile Skills Project Wiki:

Since I only sat down to write these notes after exhaustive Googling appeared to show that no-one else had done it for me, I thought they’d be worth sharing here, in the hope that they help others try out the Agile Pillars Retrospective.

Our Pillar Spiderweb retro seemed to succeed in enabling discussion of points that hadn’t otherwise been considered, and at the end there was a strong team consensus that it had been worthwhile. The team agreed that they want to repeat this format of Retro at three-monthly intervals.

See also:

Brian Marick’s original blog post:

The Agile Skills Project Wiki:

The Mind Map of Agile Skills: