I have just finished a very interesting workshop. Interesting for a number of reasons. The idea was to check if I can help two related companies in transformation from “traditional” to agile way of working. The problem was that the companies ware related only organizationaly but were playing on completely different markets, neither was related to software development and, on top of that, the participants spanned all the hierarchy levels. And I really mean all.

I’ve chosen to focus on the the basics of the “agile way”, starting with the manifesto tuned to non-software world and continuing from there but I had to be more specific as well. So I briefly explained scrum and kanban as two methodologies working in very different ways and repeating over and over again that in the context of these companies it is not the intention to implement either framework as a whole but to pick bits and pieces that look promising. That worked, I hope, but in tha process of explaining this I have realized that maybe there was a better way of approaching this part.

What if I presented a number of initially separate “tricks” that could be used for specific purposes — remember that I thought I would be talking to complete newbies. For example the combination of a product backlog, a product owner and a sprint review as a way to approach communication with a client or a subcontractor? The daily meeting as a way to help communication within the team? Drawing a kanban board as a way to understand what is really going on in the organization? Then, only after explaining this “tricks” separately I would pull them together and show that they can make a complete “system”.

This idea is built on the premise that not only agile methods but also their elements are suposed to be tools that we use as necessary. Of course there are niches where we have tested complete frameworks — like scrum in the software development field is usually a good start — but in the end we should always inspect and adapt which, here’s the kicker, makes all discussions about which agile method is better completely pointless.

So, dear agile experts, what do you think about such approach? Do you subscribe to the “toolbox idea”? Have you ever tried to present it like this?