5 things you have to remember to really “inspect and adapt”

One of the fundamentals of Agile methodologies is the “inspect and adapt” approach.

What does it mean to inspect and adapt? It means that instead of planning (guessing) everything up-front waterfall style, you regularly reflect on your current situation and change your behavior accordingly.

To make such an approach work well, you must keep in mind a few rules:

1. Be deliberate about inspection

Pause regularly to reflect on your state of affairs. You won’t be able to inspect effectively when you are constantly in a rush. Schedule such pauses to happen at predefined intervals (e.g. daily) or to be triggered by clearly defined events (e.g. immediately after a user story is completed).

Also, don’t do it in an ad-hoc manner. Add a little bit of a (very lightweight) ceremony to your process. Don’t just chitchat about the way you work – organize formal retrospective meetings; don’t just look at each other’s code – carry out a strict code review process. This way you’ll prevent watering down and eventually abandoning your inspection.

2. Make feedback immediate

Your brain works in such a way that you adapt best when feedback is immediate. In sports you’ll learn the proper posture fastest if your coach corrects you when you’re still standing in this posture. This is true for all kinds of feedback, also for events with longer intervals – e.g. you should do a project post mortem on the day the project is completed, not the week after or at the beginning of the next big project.

For some kinds of feedback it is impractical (that’s why Scrum advocates daily meetings instead of doing the whole team meeting several times a day after each commit to a version control system), but the rule of thumb is to keep the feedback as close to the source as practically possible.

3. Seek feedback on 3 levels: product, process and code

The most common feedback point associated with Scrum is a sprint retrospective meeting, which is mostly about the process – the way a development team works. However, there are two other important kinds of feedback:

First one is feedback about the product. The example of a feedback point of this type is a sprint review meeting (if done correctly).

The other kind of a feedback, often forgotten, is a low level feedback about the code – e.g. the formal code review process.

All of these three kinds of feedback offer different and equally valuable point of view and you shouldn’t neglect any of them.

4. Find as many feedback loops as possible

Scrum defines three primary feedback loops: sprint review (a.k.a. demo), sprint retrospective and daily meeting. First two are done once per sprint, the last one once a day. This is commonly visualized by the so-called “snowman” diagram, with a bigger loop representing a sprint cycle and a smaller loop representing a daily cycle:

Snowman Diagram

However, these are only a few of the wide array of feedback loops you can find – and it would be a pity not to reap the benefits of the other.

Let’s try to quickly brainstorm a few more potential feedback loops (in random order):

  • project post-mortem meeting
  • code review
  • frequent production releases
  • frequent pre-production releases
  • A/B tests
  • defects root cause analysis
  • in-house usability tests
  • TDD
  • static code analysis
  • pair programming
  • Continuous Integration
  • automated system monitoring

Not all teams must necessarily use all of the above feedback loops and you can surely invent some more – the point of this list is to show that there are many more potential points for inspection and adaptation than the common guidelines present. (Also, I leave it as an exercise for the reader to think what kinds of feedback – process, product and code – you can get from the each of the mentioned loops).

5. Don’t forget to act!

Throughout this article I’ve been focusing on various points of inspection, but don’t forget that the agile approach is called “inspect and adapt“.

Complaining on the retrospective or periodically looking at the system metrics is not enough. You must decide what actions can be taken to improve the situation and have enough persistence to really put them into life.

Don’t treat your feedback loops as an empty ceremony. Taking a little pause for reflection can really take you to the next level – but only if you act upon your conclusions.

What feedback loops do you use? What are your tricks to get the most out of the inspect and adapt approach? Please share in the comments below!


What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s