Building a Strong Agile Team
Agile is about the people who build the software and their interaction with the people who consume it. In this context, the reduction of hands-off should be to the smallest or non-existent between Agile teams. Meaning no specialized teams should exist in this type of environment. The problem is that each Team has its own goals and agendas, even when there’s a top-level goal for the company.
If the framework team members lose touch with application needs, they can build the wrong code. If the application team members don’t get what they need, they may bypass the framework to get deadlines or slow down to wait for what they need.
In a well-organized Agile environment, every piece of share code usually starts with a need within a team. It then moves to a generalized solution for everybody else. Who maintains this type of work? The same team that invented it in the first place. The reason is plain they were the ones with the need.
The problem arrives when teams are building things for the fancy of it or learning new technologies. Understanding technology is one aspect of building a software system and a minimal one. The worthy project to pursue should be the ones attached to business impact.
People will only change the way they work if they see the value. Businesses should only be involved when there is a significant impact on the cost or duration of the project. Companies and developers should have conversations about business value, not technical practices.
Developers should not ask for authorization to write tests. They should not have separate tasks for unit tests or refactoring. They should not have different functions for making a feature production ready. Every time developers volunteer details of their work, they invite managers to micromanage them.
The practice was renamed Whole Team to clarify that a development team was not a customer/programmer dyad. Questions can be asked and answered within seconds. The experts who know the answers are always near. Organizational stability gives people confidence, security, and optimism during disruptive change. Organizational strength allows employees to keep calm, act, and adapt as the situation evolves.
To Build an Agile Team, commit to organizational stability. Leaders can create peace through psychological safety. They welcome and try out new suggestions and ideas. They can also do so by using failure as a teachable moment for all, avoiding blame and harvesting lessons about what worked and didn’t.
Dedicated time in weekly recap meetings for these teachable moments can help get the word out. Besides, it’s more important than ever during disruptive change that leaders take extra time to check on their people.
Foster Organizational Stability by creating a safe environment for every team member. Team members are empowered to negotiate between them. Projects are planned, developed, and maintained by the entire Team, not individuals. Team members have direct access to those who need the solution. There’s no such thing as a team if there’s no identified customer.
A group where every member has the skills, confidence, and empowerment to take the initiative, make decisions, and lead others. When people see problems, they think, let me take the lead in solving this issue. Communicate project status to stakeholders. Manage and call out risks. Team members should ensure the quality and reliability of shipped products. Help the team ship and delegate (both to the Team and upwards). Motivate the section on the way. Set up a framework for collaboration. Break down the project into milestones & provide estimates on these. There should not be a global entity managing the work of the team members. Individual team members are not a good metric to assess the complexity of work.
—
