geoffgr

The Real Issue 

When you think about Agile, you probably think about backlogs and sprints and requirements and acceptance criteria and so on. Let’s start this discussion by outlining the fundamental item that is usually missing: Accountability. I will let you debate why this is missing , but you can read my thoughts about it in this article.  

Accountability and Agile… Do They Play Well Together? 

I have been a part of many talks about accountability with various customers and managers, and I have consistently heard the same concern from just about everyone. “This is Agile. It is based on self-organization and collaboration.” In other words, it is not their place to tell the team how to do their job. So management is often left with no “requirements” to use for holding the team accountable. So how does management deal with accountability in an Agile environment? 

The truth is that Agile does NOT preclude accountability. In fact, it provides all the methodologies needed to deal with it. For instance, the purpose of a sprint retrospective is to self-evaluate what went wrong and fix it. Likewise, agile supports working agreements where the teams define how they will work. Here are a few articles talking about Agile and accountability. They are well worth reading. 

References: 

• Is Agile Accountability an Oxymoron? (from agilealliance.org) 
• Accountability is a Quality of Agile (from scrum.org) 
•  It’s Not Agile’s Fault (from nextgov.com) 
• Definition of Sprint Retrospective  

How do we measure accountability and how does the team improve? 

The authors of the above articles do a better job of explaining why Accountability is not only OK with Agile, but also actually required. Below are a few examples of how to “measure” the team members’ requirements (in other words, what are they accountable for). 

Single Source of Truth – When a team “agrees” to a way of doing something, they should put it in the WIKI. The accountability is defined right there.  

• Processes and Working Agreements need to go in here. They do not need to be extensive, but they need to clearly define basic expectations etc. 
• Architecture and shared resources need to be kept up to date here. 

Post-Mortems – Here we can use the findings from any outage or other production issue to add to our team’s working agreements and processes. 

Sprint Retrospectives – Have regular retrospectives, and use them to review the working agreements and where we fell short.    

Use the tools – ADO offers several tools designed to help the team.  

• story sizing and burn-down rates to see how effective developers are.  
• Task hours to make capacity planning easier. 
• Developer availability to account for non-workable hours (senior devs who must spend a lot of time approving PRs should lower their working hours to account for that time). 
• Bug reviews that allow developers to learn from their mistakes. 
• Static Code Analysis tools to create gated check-ins (You can’t check in your code if it doesn’t meet these requirements). 
• Etc. 

A Software Engineering blog that takes the human equation into account.

Editor’s Note: This series of posts will eventually be turned into a podcast, but the posts need to be published before the podcast episodes can be created,

I remember when I first got the idea for a podcast. I had just finished what was supposed to be a 30 minute meeting with my manager. It was one and a half hours long. My team had just completed a two day working session fixing a production issue for our application and I had played a big part in digging into the root cause of the issue. I wrote a long document that outlined all the issues, as well as a list of recommendations to help prevent the issues from recurring.

When my manager and I started talking about my findings, I realized that he was questioning me on things that I thought were already clear, thus the conversation was tripled in length. By the time we had finished, I felt really good because I had been able to clarify many of my thoughts, not only for my manager, but for myself as well. I had been a part of many conversations like this with him, and with other team members before. I realized that discussions like this one had been helping me during my entire career. I thought about capturing these conversations and turning them into blog posts, but I realized that I would lose the interaction of two people discussing a clearly defined topic, so I decided to try my hand at creating a podcast.

I thought hard about what I wanted to discuss. Even though I spend a lot of my time at work focused on technical issues, I also think about “Root Cause Analysis” which can often be traced back to behavior patterns of the team facing the issues. I found that I was constantly telling people to “think about the fundamentals,” and to “change patterns of behavior.” In other words, I was applying a fair amount of psychology to determining root cause. Of course this is natural since any time you have a team of different people working together, there are a number of emotional and behavioral forces at play. I also knew that I wanted a catchy name for the podcast. Something to help draw in listeners. I thought about a typical joke amongst developers that says “There are 10 types of people in the world. Those that understand binary, and those that don’t.” That’s when the name hit me. I am dealing with topics that are not in themselves binary, but with people who often think with binary mindsets. Thus, “50 Shades of Binary” was born.

Finally, I want to clarify a couple of things. First, I have never read E.L. James’ novels, nor have I watched the movies. I just thought the name was very catchy. Second, I am an engineer by degree and a technical developer, consultant and troubleshooter by trade. I do not have a degree in psychology, nor do I profess to know all of the intricacies involved in performing psychological work. I simply apply a bit of logic to trends I have seen over the span of my 30+ years in the industry and form a theory that I share with others. I leave it up to the readers and/or listeners to form their own conclusions. I also invite comments and challenges to my way of thinking. I will not always agree with them, but I will always listen and think about them.

The Next Steps

Over the next few months, I will be posting topics here and then inviting people to have discussions around the topics. Once I have enough material to provide a regular stream of podcasts, I will publish them, and (hopefully) continue adding more podcasts to the show. Stay tuned for more.