Recently we’ve been training quite a few teams that do not have any link at all to software development. I thought I’d share a little about what we’ve changed in our training to adapt to a new context.
When we designed the one day agile overview, we kept in mind the brilliant Spine Model and started with the needs, or as Simon Sinek says, start with ‘Why?’. Why is an organisation like this wanting to be more agile? What benefits could they potentially get from working in this way? We built this step into the training so that the attendees could understand why they were there, and also maybe even look deeper into their own personal ‘why’.
We then moved into the Values of the spine model which can be represented by the values given in the Agile Manifesto. It turns out applying these to a context that is non IT related is a little more tricky than you would expect. I mean sure, Individuals and Interactions over Processes and Tools is simple enough to translate, but what about Working Software over Comprehensive Documentation? In this case it’s less about the words used in the manifesto, and more about the meaning behind them. It was an interesting challenge to get that across properly.
Next step is the Principles, 12 of them to be precise, and how to interpret them for generic teams. Again some are really simple to translate, such as putting the customer first, or building projects around motivated teams to paraphrase a couple. However some are more tricky to explain, like how does ‘Working Software is the primary measure of progress’ translate to teams that have no software connection? Again we found that talking through the meaning behind the principle was the answer, and in true training from the back of the room style, letting the attendees discuss how it could apply in their context came up with some insightful conversations.
Next in the Spine Model is Practices, and we decided to focus on an overview of Kanban as the main practice. Kanban is fantastic in that every team has some sort of process they can map out. Some way of work which they can make visible. the concept of ‘start with what you do now, and agree to continuously inspect and adapt’ is an idea that any team can buy into.
Finally we finish off with Tools and we can then talk through some tools that we have found really useful in helping to apply all of the above, and yet making sure we highlight that the tools is the least important of everything we discussed.
So thats a quick insight into some training we’ve been doing recently. It’s been a real challenge and a lot of fun to talk to people about agile that have no idea about software. Context does indeed matter, and being agile about our training has helped those teams shift their way of thinking about how they work together.