Building an Agile Team with Psychological Safety
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 stability 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. People will only change the way they work if they see the value. The only thing that should be acceptable is to only accept a practice by providing a better alternative. 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.
Questions can be asked and answered within seconds. The experts who know the answers are always near. The practice was renamed the Whole team to clarify that a development team was not a customer/programmer dyad.
Agile is the set of methodologies and principles software teams use to deliver the highest value product to the customer. Agile processes promote sustainable development. Agile is about the people who build the software and interact with those 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. As important as they are, these toys should be kept to the least due to the cost they can bring to the company. The worthy project to pursue should be the ones attached to business impact.
More features mean nothing if you’re flying blind. Before getting busy writing code, you need evidence that it’s the right thing to do. Search for opportunities to simplify it instead of adding more complexity to your work. Simplicity over complexity. Sprint by Sprint; the team strives to provide end-users value through incremental delivery.
The software industry still needs to work on enjoying true agility. A practical approach to Agile follows a transparent, open environment to avoid micro-management. The fear of uncertainty forces people to create processes and limit responsibilities. Separate teams should use their extra time to uncover opportunities and create value for the business.
Failure is uncertain and scary, yet, when teams do everything to prevent losses, they also reduce innovation. Agile is a mental shift toward producing value beyond feature development. Good collaboration removes some of the blocks people have to do their jobs but only sometimes makes them more skilled — customer collaboration over contract negotiation. Instead of having to change deadlines is better to collaborate often with the stakeholders of the system that the team supports. Sometimes we have to if we’re combative, but most times, in a good business environment, we are going in good faith and collaborating.
[²]: Brave New Work: Are You Ready to Reinvent Your Organization?
