Some of us in the Agile community are not fortunate enough as to work within collocated teams all the time (is it most of us already?). Some of us may spend a significant part, or even all, of our effort as part of geographically distributed or dispersed teams. Just one of the myriad difficulties when working in such teams is to replicate the high-touch techniques to increase participation and collaboration in team events, such as planning and retrospectives. Recently plenty of online tools have reached maturity, allowing teams to collaborate in real-time, in simple and effective new ways, that is, closer to the same room experience.
This post describes in detail a real-life example of using Trello to run a retrospective. Please note no technique or tool is universally applicable and these ones are no exception. You will need to check the circumstances and forces influencing your own problem before applying any specific tool to solve it. Expect some story telling ahead.
How can a facilitator help a team finding what done means for them, considering their environment and their work. How do I facilitate the Definition of Done (DoD) discovery workshops. What you can find below is my current standard practice. There might be better options for your teams and I’m sure I will keep evolving it and I will uncover a better way but it worked for me a few times and I don’t know better as of today. I hope it can be helpful to some of you.
How to Run a Definition of Done Workshop
Note on the publishing date: This post first appeared on 2013/02/25 as part of the now defunct leannovation blog header, which died because it happened to coincide with the name of an unrelated existing company.
Since I joined my first non-corporate software development team a few years back I have seen plenty of examples of product development organizations trying to do too much in parallel. I’m not talking about the usual peak of activity here or there, but about a constant stretch to higher utilization levels or to a bigger number of projects crawling through the development life-cycle.
I am bringing one particular example as an illustration. It was maybe an exaggerated case which, fortunately enough, I have only witnessed but never been a part of. The organization in question was a software development department within the IT division of a mid-sized corporation. By then they usually bought most of their software “in-a-box” or through externally contracted development projects so the department was not very big. Most of their developers were allocated to multiple projects; the most demanded ones to as many as 10 projects. Teams didn’t last long enough to gel and individual allocations were “calculated” through some pretty sophisticated resource management techniques, considering several variables like title, occupation, availability (in chunks of 5%) and even cost.