Maybe it’s just me, but the whole “which Agile project management tool should we use” debate drives me nuts.
Maybe it’s just me, who can’t understand what “Agile project management” means to start with. Try to think in products, not in projects. Your product portfolio is the bigger problem, not how you taylor the work to create multiple projects.
Maybe it’s just me, who does not understand a thing about project management, but about software development instead. I don’t know what I want, but I know how I can get it: take small steps, iterate and reflect.
Maybe it’s just me, who heavily remember Conway’s Law:
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
(Source: Wikipedia)
Maybe it’s just me, who also understands the other direction of that law. Once you introduce a tool, it will constrain how you think about changing your organization. That said, it will keep you away from meaningful steps once they become necessary.
Maybe it’s just me, but we shouldn’t be talking or debating about Agile project management, or about Agile tools. We should discuss about what makes us successful. Remember: A fool with a tool is still a fool.
No, Markus. It is not just you.
It is definitely not just you.
Markus asked for an example of a meaningful question, but he asked on Twitter, where there is insufficient space to answer properly.
The reason I think this is not a meaningful question is that people should not shop for tools until they understand their own process. I think it is better to work out most of the details of the process manually, and only then shop for tools that provide a good fit with that process.
When people are new to lightweight methods derived from “agile” and “lean” thinking, they tend to choose a tool and then limit their thinking to the features that particular tool supports. By concentrating first on the process, they will have a better chance of finding a tool that meets their needs.
So, to arrive at a meaningful question, I would try to guide the discussion toward an understanding of the information they need, in their context, to support their project planning and tracking needs. Then I would probably suggest they use low-tech methods, such as cards on a wall or a spreadsheet program, until they were pretty comfortable with the way the work flows in their organization. Then they will have a list of features to look for in a suitable electronic tool.
Hi Markus,
The term “a fool with a tool is still a fool” is now overstretched and used outside its original context. A tool really makes project management better, and really helps organize the work.
I did publish something on the same notes on PM Hut. You can find it there: http://www.pmhut.com/yes-virginia-there-really-are-pm-tools-which-can-support-both-agile-and-waterfall-projects
Hi Markus, you make some very valid (and widely shared) comments and observations.
I think it’s important to first break down what you’re trying to achieve first (engineers and technologists love to start with the tool don’t we) but that’s not necessarily the right approach!
There are 3 steps to consistently and successfully completing projects:
1. the process,
2. the tools to support the process, and finally
3. the people who need to follow the process and use the tools having the skills and experience to do so.
To find the right tools, it’s first important to define the process which they should support. There are 2 elements to the process. Firstly there is the product process (traditional stage gates or more iterative agile methods) and also the PM Process (plan – execute – review).
There are many, many PM Tools out there (on my blog pmadvisor.co.uk I list over 200!) but often the simpler the better. If you just want to collaborate then something like Basecamp is great. If you want the tool to do more then define what your process needs and then shortlist according to that need.
I hope this helps!
I claim it’s more important to find the process the team currently uses, and if you happen to need a tool after a low-tech alternative has sharpened your understanding of the proess, and you still feel the ned for a tool, then findne that supports your process best. Otherwise you will run into the trap of Conwall’s law.