Time To Up The Accountability Of Your Agile Teams

In my last entry, I talked a bit about what accountability means to me. Check it out to create a shared understanding between us before reading on…

In this continuation, I will begin to dive into structures that support accountability at scale. For now, there seems to be enough material at the scrum team level and then subsequently at the scaled level. Here’s the delivery team level for ya.

Intro

Most of the companies I have worked with in the past several years are in the small (multi-millions) to very large (multi-billion) dollar range. Complexity, maturity, and age of the organizations were all drastically different. One of the steps I need in order to move the accountability needle forward in these organizations is the formation of teams. That’s the start of my scale. Good delivery teams.

More and more I am demanding that teams be an encapsulated cross-functional group of people with a purpose. It just works. I don’t need or want parts of people or percentage utilization… we do, in fact, need the whole person to make a whole team.

So what am I after with regard to accountability?

Most orgs I work with don’t have a great sense of accountability. The culture is all wrong to ask a developer to suddenly care about a product or capability. My approach to culture is to enable it to emerge. Ultimately, I’ll ensure the team is encapsulated and can be accountable for producing working, tested product.  It I don’t do that, a culture of responsibility won’t stand a chance.

Encapsulating the Team

By encapsulating a cross-functional team, I am enabling a more robust culture to emerge. I am able to hold the team accountable for the outcomes they generate. Given that my primary focus for scrum teams is to make and meet commitments that deliver working, tested product, holding them accountable for making and meeting commitments enables me to focus in on guiding the culture of the team toward a shared responsibility. Retrospectives become more meaningful as responsibility grows. This is the basis for my prototypical scrum team. A no-excuses team that owns their commitment and get’s better over time.

What is holding teams back from a responsible state?

When teams are encapsulated the problems become more obvious. Here are some examples:

• Teams don’t understand the problem they are trying to solve and simply take on work
• Taking features or stories with dependencies into a sprint
• Not making a credible sprint plan by tasking out stories in a thoughtful way
• Collaboration: i.e. Trouble adapting to doing work in public

As a coach, I draw the private moments into the light. Teams likely haven’t thought through how to deliver product and the team/person can be rightfully shy about not knowing about a subject. Getting used to collaborating in public is a great step towards taking responsibility. It may seem harsh to some, and it may not sound happy-go-lucky, but a lot of people are essentially sick and need some medicine. My empathy is like that of a doctor, in order to get the desired outcome, you will need to take this medicine and go to physical therapy… a lot.  It’s my job to prescribe, it’s theirs to do the intense work involved in the physical therapy.

By encapsulating teams and holding them accountable for not making and meeting their commitments we are enabling (demanding even) that the culture change. That requires respect for the encapsulation of the fixed team. Movement of team members during a release, allowing side projects, percentages of people, playing utilization games, forcing work through the system are all undermining the encapsulation and ultimately the predictability and commitment of teams. If you can’t form teams, get help.

Changing Value Systems for interdependent teams

In order to promote even more predictability, the new shiny team needs a dependency free, clear backlog. That’s where the traditional Product Owner or more likely for me, the Program Team comes into play.

To accomplish this and achieve accountability, I use working agreements and definitions of done and ready for delivery teams. Via workshops, teams define working agreements, ready, and done at the beginning of forming a team and continue to refine them at each review or retrospective during the first few months. This hardens the accountability and responsibility of the team to each other and allows me to promote a servant-leader attitude for the team.

Working agreements and definitions of done and ready are powerful tools for accountability. They give the team a known state that they can be held accountable to…. If they don’t make and meet commitments, then we need to review the definitions of done and ready and figure out how they can further solidify them to become predictable as a team. This does not mean beat the team with a stick, but rather being respectful of the capability of the team to deliver. I respect that and expect it too. Say what you are going to do. Momentary lapses of meeting a commitment aside, no team should devalue the importance of their commitment. As a result, organizations can grow frustrated with the lack of predictability in the organizational roadmap. It’s important stuff and there should be a dual respect of the organization and the people.

Next time

I’ll take it up a notch. We’ll discuss program teams and scaling this structure up. I’ll give some tangible examples of accountability of program teams and even list out exactly what one program team said that solidifies the notion of letting culture emerge.  A sneak peak… “It’s ok to accept change, in this system change can be embraced” – My new favorite BA when asked what she would tell other BA’s about moving to agile.