Agile: Reflective Practice and Application

As an Agile coach, it’s very easy to get wrapped up in theory rather than practice, as some topics can be so simple for us to understand, yet sometimes difficult to execute. 

We see so many Agile transformations fail and so many poor implementations of Kanban or Scrum that at times we can feel really good about success while other times we feel disappointed. The concepts are neither complex nor new, it’s just that they are very difficult to implement effectively in a lasting manner.

Successful Agile software development is based on the following three similar, but intertwining thought processes, and if anyone of them is absent, the strength of the whole is significantly diminished.

• Systems Thinking
• Community Context
• Reflective Practice and Application

Sometimes we get focused too heavily on the principles and the values, but the “Manifesto for Agile Software Development” begins with what I think is a statement more important than the rest: “We are uncovering better ways of developing software by doing it and helping others do it.”

At the very heart of the manifesto is the notion about getting better at delivering software: “We are uncovering better ways.” It is a journey of discovery; we do not have all the answers. And “by doing it and helping others do it.” It is not just theory, and we share our successes with others so they can benefit from our past successes and failures.

Systems Thinking

It sounds great and perhaps we would be better served coming up with a less grandiose title, but essentially the issue here is that YOU are not the center of the universe. “You” could mean you personally, or your team.

The goal is effectively solving a problem for a user, usually with software.  Our system is the whole process from identifying a need, through to the delivery of a solution, and that solution being used to satisfy a need, and a need that has been identified as the next most important need.

Our system is not coding; it is not moving a card from one column to the next.

Having great code on a branch that will not get to the user for months or years (or perhaps never) is not satisfying customers, however proud you are of it. The same is true for designs or perfect architecture for features not needed.

I recently worked with a team that developed a solution that could reduce the duration of a regular activity by 15 minutes, this activity was so frequently done that the saving amounted to millions of dollars in time saving. The plan was to lump it with other features and deliver in around 6 months. When pointed out that this was millions sat on a branch they seemed puzzled and surprised, not in a bad way just that they generally didn’t think beyond a story being done in their system. Once the implications became clear the team was motivated to reduce the time to deployment.  

Transformation Failures

In my experience, I would attribute a significant majority of unsuccessful transformations (and many business failures) as a result of a failure by members of the team to grasp that they are contributors to a larger system. It sounds insensitive, but team members are a link in a bigger chain, a cog in the machine. Focusing too much on one small part does not help the organization or the system as a whole. 

And yet we expend a lot of effort on improving local efficiency, and at the same time failing to grasp that your efficiency is irrelevant without context.  By focusing on your own local efficiency, which can lead to focusing on what is not needed, can mean at best doing nothing for the larger system and at worst making the larger system less efficient. The obsession with coding efficiency in particular kills a great many software products. I see teams actually proud of a growing pile of stories in need of testing, or a team dedicated to front-end UI, proud of having endless features complete against mocks and how the back-end teams can’t keep up. Sadly, these teams seem oblivious to the fact that they are not adding value to the system.

Let me give an example that a friend of mine shared recently:  My friend was baking some cakes for an event and needed to bake 10 cakes, but only had one oven. Her husband offered to help out and so she asked him to measure out the ingredients for the cakes in advance so that it would be quicker to get the next cake in the oven.

When she came to get the ingredients for the cake, they were not ready, her husband had optimised for himself and not for the goal.  He concluded it would be much more efficient for him to measure out 10 batches of flour then 10 of… etc.  after all he knew they would be needed later and it was quicker and far more efficient for him to do that than to do small batches and keep switching.

The result was that whilst he was being efficient for himself, the system grinds to a halt and must wait, his efficiency came at the cost of massive losses to value delivery (cakes baked).

Perhaps if he had understood the full picture, and how his contribution impacted the value stream he would have planned his work differently? He would have prepared one cake at a time even though it was less efficient for him. Together they would have reached the true goal more quickly.

Community Context

Systems thinking refers to the context and the domain but within that is a team – often many teams. The teams are a collection of individuals – all distinct and all different - and your ability to work together (or not) can determine how well you are able to produce software. Teams that bond and grow together achieve amazing things, while teams that fail to establish trust can and do churn without making much progress. 

An understanding that software development is about people first and foremost, may sound like an odd statement and one that can be presented as a lonely and socially awkward enterprise. But all aspects are about interactions, within the team, with users, with stakeholders, with other teams, the list goes on, but effective communication drives software development.

Those that master the understanding that product creation is a people-centered activity, and overwhelmingly a team activity, will thrive. Those who recognize that we build cross-functional teams in the belief that self-organization and motivated groups produce great software, significantly improve their chance for success.

It can be tough adjusting from thinking about you as an individual to you as a member of a larger community, but when we can act in a way that best serves our community rather than ourselves, we start to become a high-performing team. Furthermore, it is worth noting that you do not create a high-performing team by simply grouping a number of high-performing individuals together. That, is often a disaster.  High-performing teams arise when we learn that we are more than the sum of our parts.

The second part of this is being in a community is sharing knowledge and offering support. The manifesto calls out that part of being agile, and not just doing it but helping others do it.  We find ways to grow as individuals and together.

Reflective Practice and Application

Finally, and this is the pillar that binds it together and makes it so strong, is that we must take time to reflect often, so much so that we become skilled in self-reflection and in giving feedback to others to aid their self-reflection.

I believe every team – not just technical teams -- should take a break and reflect regularly. Regardless of what you do, you can improve, but you need an environment conducive for that thought process. If you can learn to reflect effectively, an hour away from your normal environment may end up being the most productive hour of your week.

When we are busy in our day-to-day work our head is down we are focused on what is in front of us, by pausing an looking at the big picture we remind ourselves of the true priorities, our impact on the rest of the team and our organization. Often we are oblivious until we stop and look around in the misguided belief that we are too busy to improve. Small changes can have a big impact and the time together is a good opportunity for the team to bond in another setting. 

Facilitating Retrospectives

Facilitating retrospectives is a difficult skill. Sometimes people are afraid of disagreement so shy away from difficult topics, understanding that healthy conflict is generally necessary if we want to improve is a key learning point for a facilitator - differences of opinion are where the real change happens. Getting past the noise to get at the real issues can be difficult and takes skill and practice, but both the facilitator and teams, get better at this over time, especially if they reflect on how to improve this skill. There are any number of techniques for facilitating, for the very simple what went well/what went badly conversation to metrics reviews, to one of my favourites the five-focusing steps.  Variety is important but having honest open dialog is the key.

As a group and individual, we should take time to identify learning opportunities. We should continually observe ourselves and our teams to look for ways to improve. We learn to give and receive feedback in a way that helps us grow – not to diminish us. Giving feedback is a skill, as is receiving feedback with good grace. As with all skills practice is essential, give feedback regularly both good and bad, if you see a behavior to like comment on it, likewise if you see something you disagree with comment on it, but in both cases be open minded and be prepared to listen, there may be a good reason and you may learn something too.

We challenge our thinking, we question our beliefs and we look for ways to improve. We learn how to experiment in structured ways by trying new things and observing, and we learn the value of metrics and measurements, both in our team and our products.

But the learning and reflection is for nothing if we do not apply what we learn, the application becomes yet another skill we can develop, and many of us can become analytical and observant, but continue to do the same things despite what we see. Taking action items and holding each other accountable is essential, review daily and follow through conversation without action will get you nowhere.

There’s a well-known adage that is quite fitting to this discussion: “If you always do what you’ve always done, you’ll always get what you always got.”

Learning to apply our observations and reflections in a structured and effective way is another challenge, and bringing this back full circle to systems thinking is essential. We should focus on the area that is holding us back the most, and deal with that alone, and then repeat the process.

Trying to fix too many issues or focusing too much at once on a single topic, can lead to confusion, particularly if you’re measuring impact of changes. If you change more than one thing it can be very difficult to know which one had an impact.

All three of these thought processes overlap, intertwine and often depend on each other, but when bound together they are extremely strong, and we can and will get better at delivering software and helping others to do the same.

About the Author

John Yorke is an Agile Coach for WWT Asynchrony Labs,he leads the Product Owner Chapter within Asynchrony and runs a Product Ownership Meetup in St Louis. John has over 20 years working in software delivery, as a developer, designer, project manager and department head. Now, as a coach, he supports clients with Agile Transformations as well as coaching the delivery teams in house. He is also a writer and speaker on agile topics.