This will be the first in a series of articles focused on Agile Coaching.
“If you hear hoofbeats think horses not zebra.” Occam’s razor is the principle that, if there are multiple explanations that account for all the facts, the simpler one is more likely to be correct.
This seems intuitive, but for many of us it is not. The more we study agile and practice agility the more susceptible we are to assuming that agile is the answer to every problem. To put it in context if your team is having a problem you may first consider taking an agile response. This is natural especially if you are an Agile Coach or Scrum Master but it is very common for anyone working on an agile team or as part of an agile organization to first consider an agile response to solve problems.
Why wouldn't an agile response be the first choice?
Agile isn’t the answer to everything. Agile is simply a way of thinking about delivering value to customers. More often than not problems at the team level or higher often stem from system issues rather than from agile practices. So, like horses, system problems are far more common than agile problems. This means Agile Coaches must truly take a systems approach to solving problems within agile organizations. In fact very few of the problems teams bring to their coaches are related to Agile especially if that team has a seasoned Scrum Master.
Agile Pro Tips respects your privacy. Read our privacy policy on how we handle your personal information.
What is Systems Thinking?
Systems thinking refers to an understanding that all the various components, processes, and individuals within a system affect that system in complex, unique, and unexpected ways. As an Agile Coach you must familiarize yourself with the systems the teams you support operate within. This means doing research, asking lots of questions, and connecting the dots as they emerge. Keeping a systems document in an application like OneNote or Evernote would be a good practice. Updating it as you learn more, plus listing problems and solutions related to these systems will help you streamline your systems approach to problem solving going forward.
Can you share an example of a systems problem?
Consider a common scenario where a Scrum Team routinely overcommits during Sprint Planning. When you discuss this with the Scrum Master they let you know that it doesn’t happen every Sprint but it does happen pretty often and it is almost always one or two developers on the team that end up not taking up User Stories they committed to completing.
From a purely Agile perspective this seems like a misunderstanding about the importance of proper capacity estimation and Sprint Commitment. However, it is actually more likely that there is a systemic cause outside of the team itself. “Shoulder Tapping” is a term often used to describe when leadership reaches out directly to team members with special work assignments. This can happen at any time and in the case of a Scrum Team often occurs without the knowledge of the Product Owner, Scrum Master or other team members. This work tends to be seen as a priority since it has been delivered by a manager or other leader and often results in the symptoms described above: overcommitting during Sprint Planning, Stories not being completed, and inconsistent team metrics.
The Agile Coach has to take a wider systemic view and consider those factors that may impact Agile Teams even if the sources are outside the Agile framework. In this case the coach needs to address the shoulder tapping by presenting the metrics and team impacts to leadership sharing the negative consequences of this practice and help facilitate an intake process for these types of efforts so they can be added to the backlog of the team.
Cheers,
Joe
2 thoughts on “Agile is not Always the Answer”
Good article. Seems like good risk identification, risk management and organizational awareness are just good practice. Does it matter if its an Agile Coach, Risk Manager or Portfolio Manager who facilitates a resolution to an internal system problem that is constricting team performance? I am new to Agile but have always been an agile project manager for the last 25 years.
Paul,
Thanks for the comment! The goal is to take appropriate steps to facilitate the team’s ability to deliver. So, it does not matter who solves the problem as long as it gets solved. Your background makes you an ideal advocate for agile teams. One of my hopes in writing this series of articles was to raise awareness that Agile Coaches and Scrum Masters have allies and support within the Project Management world and beyond. You make an excellent point that as a successful PM you have had to be agile in many ways and can provide a tremendous depth of knowledge regarding the systems the team will be navigating.
Cheers,
Joe