Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Find a Way to Own the Agile Values
When I first read the Agile values and principles, they seemed to be an expression of beliefs that I had always held, but had never been able to express formally. I suspect that many people who read those words will have a similar experience. I knew immediately that I had to find a way to use those values to tackle my biggest problem: a divided project team. Perhaps your biggest problem will be different. Maybe you have a relationship with business partners that doesn’t invite collaboration, or perhaps the processes that govern your projects are bureaucratic and inefficient. The key is to find a way to apply the Agile values and principles in a meaningful way.
I don’t recommend that you try to share these values and principles with your project team, business partners, or any other project stakeholders yet. You need to apply them to yourself first.
I began by re-engaging with my project team, with a new attitude. I wanted to build a team with qualities that would ensure success: initiative, collaboration, ownership, discipline, and innovation. I wanted everyone on the team to have opportunities to demonstrate skill, provide leadership, and make a difference, regardless of experience level or background.
This effort crystallized in a simple set of maxims created by the project team that captured all of the qualities we wanted our project team to exhibit:
- Be title-blind contributors. In other words, anyone who can contribute positively to a task or activity is allowed to do so. This practice reduced bottlenecks and bad attitudes, as work was no longer funneled through a single technical "leader." Instead, every project member had a chance to be a leader at various points along the way.
- Play to everyone’s strengths. We decided to use our understanding of what we were good at (and what we weren’t) as part of the criteria we used to make decisions. This technique helped us as we decided who would perform which tasks throughout the project.
- Have thick skin, shed no tears, and bear no grudges. All project teams fight, debate, and argue. Our project team decided that this behavior was healthy and acceptable, and that we weren’t going to make a big deal out of it.
- Know the difference between different and better. This principle became a powerful guide as we debated design options. When we encountered differences of opinion, we would ask whether one option was actually better than the other, or whether the two options simply were different. If they were different, we flipped a coin and moved on.
Despite their obvious simplicity, putting these four short sentences into words printed on a page was a major first step in building a team that could work together effectively.
One important note: I still hadn’t used the word Agile to explain my new approach to the project. It simply wasn’t necessary yet, and I didn’t want to risk creating a pointless debate about Agile methodologies.