6 May 2013
With great power comes great responsibility
You can’t expect a team that is used to working in a command and control environment to suddenly make the switch to becoming a self-organized team without any guidance. All self-organization in nature happens within boundaries. Just like in nature, we will need to set boundaries when we help teams in becoming self-organizing. We need to show them ways to take up personal responsibility and collaborating with the rest of the team.
Expecting business agility with traditional development techniques
It’s really great that we have this system that can help us increase our business agility. It will not be that effective if we still build our software in a traditional waterfall approach, closing our eyes to extensibility and decoupling. If we need our process to be able to embrace change, we will also need to do this on a technical level. This is where software craftsmanship techniques like test automation, continuous integration and clean code come into play.
Rome wasn’t built in a day, your agile system won’t either
It’s great that you are passionate about improving your system. It’s commendable that you are really taking the time and energy to challenging the status quo. Don’t expect it to happen overnight. Even if everyone in your organization is convinced that this more agile way of working is going to improve things, human beings still have a hard time dealing with change. And the more change we try to force on ourselves, the more time and energy we will lose. This is why we propose to focus your retrospective actions to a maximum of three. It’s the same for change management within your organization. Focus on a small amount of improvement actions at once. Otherwise you can’t really analyze which action had a positive result and you will spend more time arguing with other people than you will spend dealing with real issues. Just like in building software, take baby steps, it will help you to reach your goal faster.
Give people the chance to experiment and fail
When our kids are still in kindergarten or even younger, we are perfectly ok with them not coloring inside the lines. You shouldn’t get mad when they pee their pants when they are potty training. They are allowed to make mistakes because they are still learning all these new things. Well guess what, learning is the corner stone of knowledge work. Stakeholders don’t know exactly which features or what system they need to solve their problem; they will have to learn this while the team is building it. Developers don’t know exactly how to build this new system that is supposed to solve the stakeholder’s problem; they need to learn this while they are building it. This embrace of the learning that is going on while building a software system is really the foundation of agile development. It is the only true way to embrace change in your way of working. And for that we need to accept that people will make mistakes. And they will fail from time to time, everyone will. The more energy we lose in trying to assign blame, justifying our actions that led to the failure and wallowing in self-pity; the more energy we lose to be truly creative and innovative in coming up with ways to learn and improve our way of working.
