Happy Global Accessibility Awareness Day!
Three things you need to know about accessible digital design compliance
I consider myself an amateur mixologist. Building a perfectly balanced cocktail from scratch is very satisfying. Take the very simple Whiskey Sour: lemon juice, simple syrup, and whiskey. When constructed with the right amounts of each ingredient you create a fantastic drink, but if you get the balance wrong it can be a disaster.
Like the ingredients in a libation, there are a lot of ways trust affects Agile teams. Stakeholders have to trust Agile teams to deliver value, Agile teams have to trust what stakeholders hold as valuable for the product, and Agile team members have to trust each other to be honest challengers. In this article, we’ll explore each of these and how when done right they are the secret ingredients of high-performing Agile teams.
For a team to be effective, there are some basic needs. The team needs all of the skills necessary to do what is asked of them and they need to be empowered to use those skills to accomplish the goal. It seems simple but in many organizations, these basic needs are just not met.
There is a lack of trust. The organization doesn’t trust that the team can self-organize to the point of taking responsibility for their actions.
“We need to make sure that, that development team can’t release bad code and take down the company!”
“Testing is done in the quality assurance department, not the development department. We can’t have them do that!”
“Okay, we have a directive from the CEO, we need to build a product just like this…”
Change can be hard, but it is important to trust the team and give them the space to take ownership of their work. Just letting them know that you believe in them can go a long way. Trust to give a team all the power it needs to limit risk, self-correct, and have pride in what they do to do a great job.
Stakeholders who formed the teams in the first place need to believe in the reliability, truth, and ability of that team to deliver. Stakeholders should tell their team they trust them and empower them to self-organize and deliver what they are capable of. Do this and you have the first ingredient to that secret sauce for high-performing Agile teams.
It’s human nature to want to do a good job. No one sets off to just do a mediocre job. However, if the job they are assigned seemly has no purpose or they are micro-managed, people and teams will do just enough to meet expectations. This is why setting a clear mission is critical. How does a team know what a good job looks like without being informed of the mission?
The best teams have stakeholders that set a clear, concise business objective with a very believable potential value and then back away. For the highest performing self-organizing teams, this is all you have to do to see huge results.
If a team believes in what they are building they will have a sense of pride and want to do their very best to make sure it happens. I like this old parable about the two bricklayers seemingly building two identical walls to illustrate.
The first bricklayer is all glum and is working at a pace just fast enough to get by. When asked what he was building the man says, “What do you think, I’m building a brick wall here.”
The second bricklayer is humming to himself, has a smile on his face, and is moving at extremely effective speed. When asked what he was building the man looks to the sky and says, “I’m building a cathedral! Isn’t it great!”
With a little bit of care and explanation of the end goal, a team will rocket in productivity. Not only that but the solution to get there will likely be better and more creative. Telling a team to build a brick wall is way different than asking them how we can best build this cathedral.
Setting a clear business objective with key result factors is critical for a team to believe in the mission. Objectives and Key Results, also known as OKRs, are a form of goal-setting. They are typically ambitious goals that should feel somewhat uncomfortable but achievable. The Key Results are easily graded success factors that when it trends up you become closer to the Objective. In a future blog post, we’ll talk about how to set OKRs effectively.
OKRs should be posted publicly so that the team, the stakeholders, and all of the stakeholder’s peers can see the results. This public display increases the level of trust between stakeholders and team as they are publicly proclaiming that this is the mission and we all believe in it.
The final ingredient in our trust cocktail is intra-team trust. Team members need to trust each other for self-organization to work. Being Agile is about being able to react to change. With a strong self-organized team that trusts in one another you can throw what would normally be crippling changes and they will adapt. They trust the skills and expertise of their members and know that they will be challenged constructively if correction is needed.
Individuals all have strengths and weaknesses, but as a team the synergies created should be greater than individual effort. However for this to work, team members need to be open and honest with themselves and their teammates on the areas in which they need help.
Sprint goals are the overall deliverable for a sprint. Commitment to the goals is done during sprint planning by the team, not individuals. Each member needs to completely believe that when other members say they will do a task, that it will get done. The belief that your teammates are reliable when they say they will do a task and have the ability to execute it is paramount to the team’s success.
Beware of the team heroes. A team hero is that individual on a team that tries to take on too much and potentially works to point of burnout. This individual likely is taking on the amount of work they are because they don’t trust in their teammates' ability to get certain tasks done. When a hero emerges this distrust must be identified and rectified or else the team will very quickly form bottlenecks around the hero.
With trust, a team becomes more open and honest with one another. One of the main inspect and adapt moments in Agile are retrospectives. In a retrospective, the team is looking for what could have gone better during the sprint. Without honesty, the team won’t speak freely about issues that are causing major problems with delivering value. If it gets really bad the team may even fall into the blame game. Blame is a waste. The time and energy spent pointing fingers at each other are completely unconstructive.
It is important that a team feels that a retrospective is a safe place. Stakeholders should not attend as their presents will stifle the team’s openness. The retrospective facilitator should early on have a frank discussion about team trust and how they need to give each other constructive feedback to quickly resolve problems before they get out of hand.
So there you have it. I hope you are sitting back reading this with a cool drink in your hand and that you have taken away even a small nugget you can use to balance your team with trust and create that high-performing Agile team.