There are a dazzling array of agile project management tools out there, with new ones being added every day. More and more of them are targeted at geographically dispersed teams, claiming to increase productivity, enhance communication, and improve our insight into the state of the project.
The hidden cost of these tools, however, can be complexity. I asked David J. Bland, an Agile coach and a speaker on distributed agile project management, to write about the pitfalls of complexity, and the virtue of using simple tools in a dispersed agile software development team.
So your enterprise organization has decided to adopt agile. Everyone on your team received a two day training course, a subscription to safari books online and a login for the spiffy new Agile Project Management (APM) tool. Now go forth with your distributed team and conquer the world! We’ll expect to see working software in two weeks. Good luck!
It may sound cliche to quote the agile manifesto at this point, but it still seems that our focus is on the processes and tools.
These APM tools tend to reflect the founder’s interpretation of what agile is supposed to be, so there is quite a variety out there today. One founder told me that many entrepreneurs are ex-project managers who feel that they know how to do it the right way. I actually have no major complaints about this except that when companies go all in on an advanced tool during an agile adoption, the adoption assumes the identity of the tool.
For example, if the APM tool has usability flaws that make it difficult to plan ahead, what aspect of your agile adoption do you think will suffer? You guessed it, the planning ahead part. I’ve seen teams that lacked fundamental agile knowledge base everything off of what the tool did and did not do well. They steered around the bits that were clunky, and were reluctant to use any other means to fill in the gaps. At times management can pressure a team to use an APM tool for all things agile, especially when a significant amount of the IT budget is involved.
If the APM tool is difficult to use or overly complex, then the team will channel their frustrations into the tool and use it against you. I spoke to one person on a distributed scrum team that refused to participate because the tool was too hard to use. I had later found out that this individual had received no agile training from the organization, but the message to management at the time was all about the tool.
The great thing about agile is that it can be ran with very lightweight tools, which places the focus on your team. If you have a Google Account you have enough free technology available to pilot a distributed agile team. For you business folks, try to think of this in terms of Crossing the Chasm. Avoid getting too wound up about how the tool scales or how many different metrics you can bathe in, otherwise you’ll never see the chasm coming until it is too late.
So let’s focus on easy to use, lightweight and low cost solutions for the time being. Yes you’ll need to worry about scaling and pricing and such at some point, but if your agile adoption never takes hold, then chances are you’ll have much bigger problems to face.
Title photo © Zhi Yong Lee.
