Evolve Agility

Giving and receiving feedback is crucial for growth. And how you frame your feedback matters.

Imagine someone from your team asking, “How are we doing?” or “Do you have feedback?” How will you respond?
One of the ways you can communicate is by using the “Gifts and Greats” technique.

a Great is something specific that the team is doing well.

For example, you can share a particular instance where you observed how the team worked through their disagreements constructively by discussing options and arrived at a win-win solution. Or you may share that the team has improved in their Daily Scrum because people come prepared to synchronize with their teammates.

Don’t hold back. Share as many Greats as you see fit. Be specific.

When people know what is great about their work, then they can reflect on how best to do more or improve on what they already know how to do. Growing talent is about amplifying strengths.

a Gift is free from obligations. The receiver can choose to reflect on your idea and implement it or ignore it.

For example, you could share that sometimes team meetings get sidetracked, and using the parking lot will help the team stay focused on the topic. Or you may share that team members start many more items than they can finish, and minimizing work-in-progress would help improve throughput.

These Gifts are neutral offerings, with no obligation for the team to act on your feedback. Permitting people to choose ensures they have agency in their practices.

A critical aspect of giving and receiving feedback is to accept the team’s autonomy over its processes.

It’s easy to look at organization systems as fumbling and inefficient -- but they’re performing exactly as they are designed.

Smart agile leaders know they can’t bend these systems to their will, so instead they pay close attention, actively participate, and respond to feedback. They dance with them!

What’s your best example of “dancing with the system”?

Wishing you all a jargon and acronym free week :)

Expectations are managed by setting goals and then tracking progress via measures. For example, You may have a goal to “walk 10,000 steps/day” or your team may have a velocity/sprint target.

When you focus on goals and measures, you are watching the scoreboard not the game.

The game is the systems (or processes), and when you focus on the system, the results take care of itself. The results are never the problem, they are the symptom. You will keep chasing the same outcomes, if you do not change the system behind it.

Under honest circumstances, when you lag behind your goal you will summon up your will power and work harder to achieve your goal. Your team may work overtime to meet velocity expectations, or you may walk just to “get my steps in”.

Is there a better way? - Yes, work smarter not harder.

In one of my past agile teams, we had regular walk-and-talk sessions that came to replace boring meetings. As a team we would walk through the woods behind our office building and discuss life, products, technologies, practices, etc. We got our steps in, improved our team interactions and developed products that our customers loved.

In what ways does your team work smarter?

Should we do this or should we do that? What if we do this and then that happens?

Leadership is not about making the right or wrong decision. You do not control the future, so every decision you make will involve trade-offs.

In one agile team we were endlessly debating a technical architectural choice. I suspect we would still be continuing the debate had we not agreed to settle the issue by trying experiments.

With help of the architect, who was a full time team member, both camps in the team planned to implement a spike with their choice of technology. And then we tested both implementations against performance benchmarks to select a way forward and settle the debate.

It had puzzled me that the architect had not expressed a preference during the debate. Later, in private, I asked him why. And he said that in production environment both technical choices would have performed well, but he wanted the team to own the decision so he encouraged experimentation.

The architect perceived both options as right, whereas the team members were viewing each option as right vs. wrong. So by trying an experiment the architect helped the whole team to make a decision in a manner that ensured buy-in from the whole team.

How have you turned right-wrong into right-right options?

Customers have a hard enough time overcoming their challenges. They don’t have the time to review your product manuals, or reinvent the way they do their business functions to use your product. Fact of the matter is that they simply won’t.

If you have been in the software industry long enough, then you have encountered following dynamic:

The users are using much older version of the product, and refuse to upgrade to the latest & greatest version of the product. As a result, many years of development effort is waiting in the pre-production environment.

Meanwhile the product development team continually releases patches & bug fixes on the older version to the users. This is very frustrating for the product development team, because only if the users upgraded to the latest version all known issues would be fixed and the users would also get cool new features.

But the users simply refuse to upgrade. As a result, years of development efforts build up in the pre-production environment.

How did it come to be this way? - The hard truth is that somewhere along the way, the product team lost their connection with the customer problems and got distracted by combinations of organization politics, hubris, and indifference.

How have you overcome this challenge?