13 February 2011

Applying agile practices in an environment of mistrust

Recently I had an opportunity to reflect on my past experience of applying agile practices in various projects. I want to share how I think its effective application heavily relies on trust in relationship within a team.

There’s an element of trust in any relationship. We tend to grow mutual trust relationship over time. When trust is broken, people sometimes seek counselling to start a long process of building back the relationship. A Counsellor is bit like external consultants who you might bring in when things are not working for your organisation. As external consultants, it’s tricky to get the nature of engagement right. I’ve been on a few projects where external consultants were brought in to deliver a solution but no one in the company was interested at mending that broken relationship. Often many agile practices were used with an aim to provide greater transparency and repeatable success. They are a great stepping stone of building trust and eventually mending that broken relationship. Although it’s important to keep in mind that agile practices are just tools not your main objective. In fact like any tools, it can be misused especially in an environment of mistrust.

Let’s talk about misuse of velocity. Velocity measures how fast a team goes through an iteration. It’s based on trust that everyone in the team performed their best. Actual velocity, when sustained over a period of time, can represent capacity of the team in delivery. Knowing a capacity helps to prioritise stories knowing how much can be done. I’ve seen a few projects where the management focused solely on managing target velocity and variation from estimated points for each story. So much so that there was no time left for them to engage with rest of the team as new features were built. This encourages negative behaviour from developers. I’ve seen a few instances of skewed representation of velocity (such as taking partial points from partially done stories or stories that hasn’t been integrated to the rest of systems) to live up to an expectation of higher velocity than what was delivered. I’ve also seen inflationary trends in story point over time a bit like bubble in property market. When velocity turns into a target, it’s no longer a useful tool.

What about iteration? No I’m not talking about iterative development. Iteration is a tool for an iterative development, and it’s not the only way to do iterative development. I’ve seen a few projects where planning an iteration was a struggle. Filling enough work for an iteration of one week or two were relatively expensive exercise. Running an iteration in such environment can sometimes encourage people to switch their mindset back into project delivery based on rigid contract. Friction between managements and developers arisen from requirements churn was not uncommon. “that’s a new story, it wasn’t in the acceptance criteria” said a developer. “this new story can’t have any story point associated with it, it’s a bug” said a manager. When iteration turns into rigid contract based interaction between managements and developers, it’s no longer a useful tool.

It’s true that agile practices makes inefficiencies in an organisation so painfully visible. But applying agile practices out of context in fact could harm business moving forward, out of that bitter relationship that you sought counselling for. In my opinion, all these agile practices should be treated as tools not as goal, focus should be on supporting managements to run their business idea iteratively. Look out for an opportunity to engage in with management. Support them to try their incomplete ideas to capture the timely sensitive business opportunities. Does that encourage positive change in behaviour? It has vast impact on people's mindset. For developer, it has to be cheap to try a fuzzy idea. For management, it has to be nimble enough to respond to an unexpected outcome. You will be encouraged to innovate. You will find a close relationship between business and technology and thus greater trust. One tool I would recommend to help that series of short burst of trial and learn process is continuous delivery. In fact releasing a few times a week for every new feature shouldn’t be hard. If that sounds hard and risky, let's make it easy to deploy and revert. Keep your development and deployment cycle short so it's cheap to make mistakes along the way.