Why is no one taking responsibility?

(Ported from my old blog called Thinky)

No team is perfect. No product or solution is perfect. No company is perfect. The best we can do is to aim for perfection and hit non-failure.

This post references quotes from Kent Beck’s post on Accountability in Software Development.

Responsibility vs Accountability

Responsibility implies that you have an obligation to do something (actions or decisions). Accountability implies that you are required to justify your responsibilities. You could say that one takes responsibility for ‘xyz’ and one is held accountable for ‘xyz’.

In software development, teams need a sense of responsibility for their products. They need to action and make decisions in order to ensure timely delivery of quality production code. They shouldn’t knowingly take bad code or bugs to production. When things go wrong, they need a sense of responsibility so that they can fix it to the best of their ability without pointing fingers or playing the blame game.

Teams can be accountable in numerous ways such as pairing with other developers or doing code reviews, developing their code test first (TDD or BDD), continuous integration, visually displaying work in progress and following industry renowned best practices.

“I need support, encouragement, and accountability. I need to be a member of a community to do my best. A key to performing well is accountability: making commitments, working in ways I am proud of, and rendering account of my activities clearly and directly.” – Kent Beck

I believe that teams who take responsibility feel accountable resulting in better quality and less awkward interactions.

Coaching

I talk about coaching a lot in this post. So who should do the coaching? Anyone. If you are a manager, team lead or even a team member that is identifying issues within your team, you have the power to coach others.

I see coaching is an art of guidance. You cannot expect individuals or teams to change over night. You may need to try multiple approaches before succeeding. Perhaps get a team of like-minded individuals to help coach your team. Don’t be afraid to ask around. Change starts with you.

The problem at hand

We are all human. Each with different values. I have encountered many individuals that feel that they should not be responsible. This led me to ask why the hell not? These are the questions that I have started asking and I discuss my opinions on each based on my experience and a number of conversations I have had with my peers:

• Do they know they need to be responsible?
• Is something stopping them from taking responsibility?
• Do they have the right skills?
• Do they understand the product?
• Are they invested in the product?
• Are they in control?
• What constraints do they face each day?
• Do they have a support system?
• Do they know they need to be responsible?

It could simply be that the person is not aware that they could and should be responsible. Perhaps they perceive the Product Owner, team lead or decision makers to be responsible?

A culture needs to form within the team which instills a sense of responsibility in each individual. Team members need to have a sense of belonging and know that they have something important to contribute to the product and always do what they can to the best of their ability.

Teams need to be coached to incorporate such values. Without proper buy-in from teams, teams will rarely change. Values cannot be forced on teams. It is a journey of discovery that teams need to go through and this takes time. Teams comprise of many different personalities which makes the journey even more challenging.

Kent Beck says “accountability can be offered, asked, even demanded, but it cannot be forced.”

The team needs to come up with ways of showing that they are accountable. This can be achieved by visual work flow boards, incorporating a process that works for the team and useful collaboration between the team and product stakeholders.

Is something stopping them from taking responsibility?

• It is possible that the individual had bad experiences in the past when they accepted responsibility and now they simply choose not to.
• Their opinions are not being heard or they are intentionally ignored.
• They are being blamed for problems beyond their control.
• Maybe they are driven by fear and do not want to accept responsibility.
• They could be feeling that their team or the business is letting them down.
• No one else is accepting responsibility, so why should they?
• It could be an ego or stubborn attitude that is making them act this way.
• They don’t know how to be responsible.
• They have simply given up.

It could be as simple as changing the individual’s perspective. Don’t add negative connotations to holding someone accountable. Don’t belittle individuals for their ideas or mistakes. Don’t ignore their outlook. Don’t play the blame-game. Create a safe environment for team members to collaborate and share their ideas.

“Blame leaves everyone worried about who is out to get them. All the energy they spend hiding could be spent interacting and adding value to the project.” and “Taking responsibility for my choices and actions deflects blame.” – Kent Beck

Identify problematic personalities that do not wish to play fair. If they continue to bring down the team, try moving them to another team. If they bounce from team to team, consider if they are a cultural fit in the business.

Do they have the skills?

If you are an Agile team and a new team member has no Agile skills, invest time to up-skill them on the process as well as the team values. Encourage them to take the time to learn about Agile (or any other methodology/skill/technology that they are new to) in their spare time. Host workshops or sessions to share your understanding on the methodology/skill/technology.

Make sure that all team members including new team members know the methodologies and technologies that the team is using.

If back-end code breaks in production, it is unfair to hold a designer or UX-specialist accountable as they do not have the appropriate skill set to fix the problem.

Each member needs to know what they should be responsible for and how they should be accountable. It must be defined. It cannot be assumed.

Do they understand the product?

People probably won’t feel responsible for something they do not understand.

The Product Owner needs to engage with the team by explaining the product and its impact on users regularly. The team needs to ask questions about the importance of features and know what they are building and why. The team should collaborate and invest themselves in the product.

Time should be invested in ramping-up new team members. Get them up to speed on the journey the team has been on.

Always assume the people you are talking to are not on the same page as you. What you know is not necessarily what they know. Always discuss the value of a piece of work. The more exposure the value gets in the team, the more the team will understand its value.

Are they invested in the product?

If the team does’t understand the value of the product, the value they are adding or the role that they are fulfilling in the team, responsibility will suffer. People can easily feel overwhelmed and also not ask the right questions. Product Owners should constantly engage. Team leads should always ensure their members are aware of their roles and responsibilities and team members should feel safe enough to ask questions until they get the right answers. Managers and team leads should identify where members are feeling overwhelmed and coach the individuals or optimise the issues that they are experiencing.

Are they in control?

In some environments, teams are not in control of everything. In such cases it is unfair to expect the team to take responsibility for things that are out of their control. This will result in a negative vibe that will spread through the team. Eg. if a product in production experiences downtime and the team is not in control of the production environment, it is unfair to hold the team accountable.

Find ways for the members to interact and form relationships with the people working on the systems and processes that are out of their control. They need to understand these systems and processes if it has an impact on their product. If they understand this, they can come up with a checklists, processes and procedures to mitigate issues. This empowers the team and they will most likely feel comfortable to accept responsibility.

What constraints do they face each day?

The more constraints and dead-ends a team encounters each day, the more frustrated they get. Coach teams to optimise these constraints so that frustration is minimised. If they cannot be optimised then help teams work with these constraints by getting managers involved.

Do they have a support system?

If teams believe business just expects, expects and expects but does’t provide a necessary support system for them, they work against the business. Find ways to implement appropriate support systems that alleviate or optimise constraints. Coach teams to build relationships and ask the right questions.

“Accountability isn’t simply a matter of reporting facts. If I know that I created 40 defects this week and accurately report that, I have been honest but not responsible. I have not completed my work in a way I can comfortably live with. I am not behaving in a way that builds relationships, relationships necessary for good software development. Extreme Programming is my way of working. Its principles and practices contribute to my ability to be accountable while developing. Accountability encourages me to do my best work. I resist the urge to take shortcuts or leave ugly code when I know others will see it and care.” – Kent Beck