Let Your Dev Team Choose Tools, Not Management

by Alex on March 12, 2012

This post was written by Kelly Taylor – @ktinboulder from PR Newswire

Kelly Taylor

I am the Product Owner on a 10 person development team building tools to help  our PR, Marketing and Investor Relations Communicators teams find insights in the social web and traditional media then distribute their text or multimedia content to targeted audiences. We are using Ruby on Rails, jQuery, MongoDB and many APIs in our web applications.

Our team was using an enterprise ALM tool for a year which was wonderful for Product Owners and Executives as the user interface was very conducive to planning Sprints and Releases. Backlog management was great and Stories could be well elaborated. However, the development team hated using the tool and it was a constant source of frustration.

PR Newswire

We decided to try AgileZen using a very minimalist approach and a commitment from the team to use the Kanban Board. Our team also uses Campfire, GitHub and Jenkins in our workflow and have leveraged APIs to post updates automatically to Campfire. The frustration ceased and we have never looked back.

Being part of an enterprise, we struggle with large team collaboration and consolidating portfolio roadmaps. We have leveraged AgileZen’s multiple boards feature to have high level portfolio planning boards for management as well as our day to day development team board. The ability for each team or group of stakeholders to define their own workflow for a board has been key to the success of AgileZen for us.

When your development team is empowered to use the tools that optimize their workflow, consistent delivery of quality software will follow.

629cce03d46a9e81349e55fcbd311ecc
  • http://twitter.com/martinb9999 Martin Burns

    Which is nice when you’ve only got one dev team.

    Dev tools are a satisfier – they can’t get in the way or be painful – but that’s a lower bar to clear than allowing full choice. The support costs of multiple tools, plus the *hideous hideous* costs when a team-member moves to a different set, mean that there’s a huge plus to standardisation. As long as it doesn’t get in the way.

Previous post:

Next post: