Listen to Individuals and Interactions

Arguments about process and
 tools make us look like these guys

When you are coaching agile, you spend plenty of time in a place Lewis Caroll calls “the shadow.”  The ideal of agile is in tension with the realities of working in a contemporary business.  It is challenging work that forces you to confront your shortcomings.  A coach is faced with doubt daily.  It is also a life filled with insecurity because coaches get fired when things go poorly.  I have spent over twenty years in technology, and eleven of them in the agile world participating in the agile reformation.  Today, I want to look at the agile manifesto and discuss something.

When we discuss the history of the agile manifesto, it has this glamourous sheen.  A bunch of smart people got together to brainstorm, ski, and have a few drinks.  When it was over, we had a guiding document that promised to change the business world.  It was optimistic and promised a better way.  Since that snowy and booze-soaked retreat, the agile community has splintered into several factions around taking agile principles and scaling them up to fortune 500 organizations.  

In addition to scaling frameworks, the agile world has plenty of different software tools to take agility, including Azure Dev Ops, Jira, and Rally.  A manager forbade me from coaching a team because I did not have the proper experience with the correct software.  These fractures in the agile community feel similar to the fractures in the development community, where people bicker like the character tweedle dee and tweedle dum.  

It is natural for people to have biases and strong opinions about their careers.  Passion is necessary if you want to be good at anything.  Unfortunately, these passions create prejudices that act as a toxin in the agile community.  People with Jira experience should not look down on those with Azure Dev Ops experience and so on.  When I am involved in these situations, I go back to the agile manifesto and gather some inspiration.  

Lately, the value of “Individuals and Interactions over processes and tools” has been significant.  Agile did not begin with any software in mind, and vendors attempted to automate the process.  A good coach or scrum master can manage a project with post-it notes, a few whiteboards, and an active email account.  Everything else is extra smoke and mirrors. 

Coaches should ask questions about why work is done and how it is generating value to the firm.  If we get involved in an unproductive discussion about processes and software, we are going to fail.  Each coach, regardless of their background and training, should have some basic skills.  A coach should know how source control works because when a developer talks about branching and merging, they can have an intelligent discussion.  Coaches should understand how to write user stories and show others how to write stories.  A coach needs to listen to others and know what they say and what they mean when they say it.  Finally, a coach needs to be a servant leader pulling their team toward success.  All the other skills are sprinkles on top of a tasty ice-cream sundae.  

As a member of the Agile reformation, we need to listen to “Individuals” and pay attention to “interactions.”  Otherwise, all of our passion for processes and tools will undermine the excellent work we have done for the last twenty years. 

Until next time.