Process in Kanban

Something bothers me for a while about Kanban. These thought re-awakened during James Bach’s keynote at the Let’s Test conference in May. James was talking about the 1990’s movement into process. Processes needed to be everywhere. That’s why he became engaged with what turned out to end as the context-driven school of testing. Here is a quote that I heard in one form or another from the Kanban community:

The process needs to be defined, published and socialized — explicitly and succinctly.

(I got this from here.)

The Kanbanistas keep on confusing me with this. Here is why.

Continue reading Process in Kanban

Which Agile project management tool should we use?

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.