I have been working with Agile for a few months. At Berteig Consulting we are using OpenAgile to run our small business. As such we try to use various tools to make our life easier. I have already mentioned that we use CardMeeting for our cycles and tasks. I have tried using PlanningPoker for online estimation. It seems useful, but maybe our team is too small to make great use of it. I am also looking for other ways to manage the reflections and learning from each cycle.
I have received an email from David Wolrich of CardMeeting that states: “Anyways, I rely on the trickle of news from legitimate organizations like yours to let users know that CardMeeting is still around, that I am still adding features, and to generate interest; thanks again.” So maybe some of you could try it and give him a shout. Much like other free applications on the net such as Drupal and Neo Office this one could become more robust and useful.
I am wondering if I am spending too much time on tools and not enough reading and researching Agile methods. I am enjoying reading about Agile success stories. Anybody know of small businesses that have documented or written about achieving success in Agile? Is there an Agile bible or maybe a book about the best ways to succeed using Agile?
So this is the question that I am wondering: Are tools better than books when it comes to Agile?
Affiliated Promotions:
Please share!
I would answer a clear no.
I’ve seen really successful teams just using a card board and excel for backlog management and reporting. I’ve also seen teams using RallyDev and other very complete software fail.
Remember the Agile Manifesto, “Individuals and interactions over processes and tools”.
Don’t get me wrong, i think tools can help. But before you start using them ask yourself “what problems do i have now that a tool could solve ?”.
I would echo that “no”.
Select tools which support the team’s Agile process, and which are flexible enough to continue to support the process as it evolves over time.
It is not satisfactory to substitute tools for learning. Without an understanding of why it is you are doing the things you are doing, you won’t be doing them right. By simply dropping a tool into a new Agile team, you do them the disservice of enabling them to not learn what Agile development is.
(One caveat I can see is if your team is not co-located. This is a tricky proposition anyway, and an educated selection of tools to help your team out would be beneficial).
As far as books for learning Agile, I particularly like http://www.amazon.com/Practices-Agile-Developer-Pragmatic-Programmers/dp/097451408X,
http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445, http://www.amazon.com/Agile-Project-Management-Microsoft-Professional/dp/073561993X and http://www.amazon.com/Agile-Estimating-Planning-Robert-Martin/dp/0131479415
I have also found http://news.gmane.org/gmane.comp.programming.scrum.general to be a useful resource.
Thank you so much for your comment Hugo. So I need to re-focus on my interactions with those that I work with. It seems that collaboration and consultation are much more effective than tools and systems.
Were the teams that succeeded more united than the ones that used complete software and fail?
One the things that I enjoy most about the Agile community is the collective passion for learning. I feel part of a community that actually cares about each other. Very unique for to work in an industry that promotes learning and collective action instead of individualism and competitiveness.
I can tell you from experience, I too was against the thought that a tool could help us with Agile, but I still believe in people and process above tools. However, don’t discount tools that automate some of the areas that make practicing agile techniques easier.
As for an agile success story you should visit this blog by Accurev. Automate to innovate, read to gain knowledge.
http://damonpoole.blogspot.com/2008/05/agile-case-study-litle-co.html
Don’t let the marketing of agile dillute your common sense and good luck with your future endeavors.
~D
It sounds that when you are talking about tools, you are referring to software tools here? In my opinion, as Agile practitioners, we need to be very wary of software tools – a good rule of thumb is that more tangible tools are also more collaborative. Planning Poker, for example, is a great tool for a collocated team when used with real cards. The software tool is just a poor substitute when you can’t be colocated.
l
For a good book, I would recommend “The Art of Agile Development”. Again, still better is *direct* contact to other practitioners – join a local user group, go to conferences, etc. pp.
I agree with both of these comments. Tools tend to focus our attention on the tools, and not on the people. Tools have a great place, but only after you’ve already become efficient in adopting agile as a methodology. Once you’ve done that (which necessarily will cause you to tweak the methodology and adapt it to the way your organization can make sense of it) then you can look for tools to make your existing process more efficient.
The reason the tools exist in the first place is that someone with an already-adopted agile practice needed to get more efficient. So, by adopting a tool, you are basically conforming your business process to theirs. Unless it’s a tool with so many option settings that you really need to have your process figured out beforehand in order to know which options to set! Which again bespeaks the need for getting your adoption clinched before starting with tools.
Better to automate a manual process than automate a non-existent process. Too much theory can spoil the whole soup. (Or something like that.) 🙂
Good luck,
Bob Smiley