Leading Agile Teams : Conditions Teams Thrive In - II

In the last post we saw the infographic that included comments from four of the Team Leads that were interviewed for this series of posts. Here are some thoughts on the responses that were gathered.

Yvette Gaitan

"When the team has the proper tools available to do its work. Adequate communication from upstream teams about changes so that we are better prepared. Communication and team-wide awareness of the correct priorities in a space where priorities are constantly changing."

Yvette's team is often downstream from numerous other development teams. That explains the emphasis on communication both within and without the team. Agile environments are characterized by change and the ability of the team to adapt to such changes. Yvette's team seems to do this well as long as the priorities have been well communicated. They seemed to have understood that change is inevitable, but getting a heads up puts them ahead of the game.
Specialized tools that take the tasks that the team performs and automates them are always beneficial and welcome, regardless of team, methodology or industry. If the team is in unique situations and is given the bandwidth to come up with tools and processes that make them more efficient, the effects can be long lasting.

Michael Longin

"Informal attitude in the team room, balanced with structure through formal plannings, reviews and retrospectives.  Knowing that we are set up for success, but failure is OK.  Provide a safe failure environment and help people while they are failing.  Feeling of influence in the product."

A team working together day in and day out develops its own personality. For the team to develop both informal interactions to cope with the high pace and formal attitudes to achieve structure as Mike points out. Mike talks about a safe failure environment and contrasts it with being set up for success. This is important for the team and the organization as a whole. This means that plans are set up so that the team succeeds and there is no organizational backlash if the team happens to fail. Another important snippet here is "help people while they are failing", as signs of failure and opportunities to avoid/readjust are often present long before failure actually happens. 

Most development teams I have talked to mention this last point of having influence in the product. This is probably the single most empowering notion I have come across when talking to my colleagues. Influence leads to ownership, which helps make the team excited about the problems they are solving and the solutions they are creating.

Anonymous

"We work well under stress, specially when something has gone wrong. Team closes a lot of stories towards the end of the release. It helps the team to see where it stands in comparison to other teams."

Here we see a team that is under pressure and as a result has learned to deal with it by coming together and pushing hard. When things go wrong, teams come together and tackle the problem head on. This team seems to do that. What might be missing though, is the same coming together to come up with processes to prevent things from going wrong. The team here also seems to have a competitive spirit and takes pride in excelling especially in comparison to other teams in the organization. 

While this team is obviously working hard and producing results, there is something amiss in release planning for the team if end of release is when the pace picks up. This is not ideal. Teams should not need stress to perform well, in fact, stress, although sometimes unavoidable should be prompting reflection and change in team behaviour.

Mariana Sabogal

"Having a collaborative Product Owner is a great help. Team's feedback taken into account during planning, specially the technical perspective. This gives the team feeling of ownership."

Mariana reiterates the point that Mike has also made. Team having an influence in the product empowers them and gives them ownership.  Making technical feedback a part of the planning is a great way to get technical debt prioritized as well. Both Mariana and Mike talked about being closer to the customer and having input into the product as being a great components of getting the most out of teams. It would be good to clarify here that these are independent observations.

The importance of a collaborative Product Owner cannot be undervalued as Mariana notes. There are ample examples of a non-involved or no-collaborative Product Owner running teams off-course and being an impediment instead of a problem solver. Mariana feels that whenever she is working with a Product Owner that works well with her team, performance and productivity of the team is very high for that time period.