Management Tools vs. Team Tools
Just this week I participated in a WebExchange of yet another “enterprise Scum tool” with all the cool database, web access and reporting features you could dream of. Apart from some serious misunderstandings of just what Scrum is and how it can be made scalable, the tool was OK. It had some nice features, did some interesting things with traceability (oddly enough ignored tests), but it was not a tool I would recommend for any Scrum team.
Over the years I have worked with teams, I have tended to avoid these electronic tools since they do not support the dynamic I am trying to foster when I work with people. I want people to talk face-to-face with each other and I want them defer complexity and detail until the last responsible moment, i.e. the Lean concept “decide as late as possible”. I want to encourage the growth and development of collaborative, cross-functional, self-organizing teams. IMO, these tools hinder the creation of that dynamic more than help. [Please note, I am ONLY referring to Teams and Product Owners that are co-located in the same work location and same time zone. I am not so arrogant to say electronic tools are not applicable for geographically distributed teams across multiple time zones. Distributed teams need different tools.] For the longest time, I could not articulate why, well now I know.
These electronic tools are management tools for reporting up, they are not tools the team needs to create a collaborative, cross-functional, self-organizing team. There is no reason why a co-located Team of 8 to 10 people should be using something other than task board and Excel files to track their own progress, especially when they are starting out. The unfamiliarity of self-organization and collaboration requires simple of the tools that encourage communication. There is only so much you can write on a stickie note or in a field in Excel. To be successful, you have to get out of your seat and talk to someone.
With so many of these electronic tools, it is so tempting (and so easy) to fall back on “bad” habits of command-and-control. These enterprise tools with their workflows, forms to fill out, work groups, web services and clean looking graphs we can email with a click of a button, encourage us forget that we are trying to become more collaborative, cross-function and self-organizing. We sometimes get so wrapped up in giving the tool the data it wants and follow the process IT lays out for us, we forget the reasons why we wanted to be more Agile. IMO, the only things these tools buy us is the ability to cleanly report up to management. So why does the Team allow a management tool to govern their own Team interactions?
Before you shut off your brain and dismiss my criticism of these tools as “just another Agile zealot”, I want to be very clear I believe Teams MUST be visible and accountable to management. Teams MUST report their status to management with the metrics they expect in ways they can understand. Not to do this is not only is this disrespectful, but the Team is in for a surprise when management kills their Agile initiative because they are viewed as “rogue”. Providing visibility and accountability is where I can see how these enterprise tools can be valuable to the enterprise, but filling the tool with the information it demands is not the responsibility of the Team. In my ideal world, the Team should not even know the tool exists – you basically only need as many licenses as you have Teams and Product Owners. It is the ScrumMaster’s (or the XP Coach’s) responsibility to translate the Team’s metrics into the tools format since their role is to provide the “management deflection shield”. No one else should be entering information into the tool but the ScrumMasters (or Coaches) and the Product Owners (or Customers).
