Stage One - Pre-Genesis
The first in a series of articles I'm calling the Seven Stages of Communities of Practice
This is the first part of a series I intend to write about Communities of Practice and, like all good stories, there’s a story that comes before the story. Today we will meet Dave. Dave is a software tester working in a waterfall delivery environment that is about to go through an Agile transformation…
Dave is a software tester. He isn’t exceptionally gifted or talented at his job (in his opinion anyway), but he’s good at it and he cares about doing a good job. Dave works in an IT department that delivers software for the used and sold by the wider company that he works for, and in particular he is part of the Test Team. There are 11 other testers in the Test Team, a slightly larger number of Programmers in the Development Team, and again a similar number of Business Analysts in the BA Team. The BA’s provide requirements to the Development Team, who then hand a build over to the Test Team, who then test and sign it off before passing it on to the Release Team to deploy. Everything works smoothly in a nice and stable waterfall and task focussed environment. Well, that’s what they tell themselves anyway. I’m not going to sit here and discuss the various merits of Agile versus Waterfall, as its been done a million times by much better informed and more articulate people than me. Suffice to say each team is working in a task focussed environment, with work slowly appearing through the flaps of the theoretical conveyor belt to be worked on as quickly as possible, before it disappears through the next set of flaps and into the ethereal void of being someone else's problem.
Much to the relief of everyone, this way of working was left far behind as the department was restructured towards an Agile way of working. The big siloed teams were dissolved and rebuilt into smaller, multidisciplinary, product focussed teams. Instead of having four big teams, the department was restructured into lots of smaller teams made up of a BA, four Programmers and a Tester. Regular stand-ups took place, iterations were iterated, retrospectives were reflected on and many Post-Its were used. Each team is now working smoothly in an Agile way and everything is much better.
As time goes by, the management team begins to notice a problem. They’ve optimised their teams and got rid of the silos, and each team is working as efficiently as possible with its own product and within its own problem space. Every team is diverging further along its own path to optimisation, but now each time Dave or one of his colleagues goes on holiday, has to take time off sick or gets promoted/leaves the business, there’s a hole that’s much harder to fill. Moving Jane from another team for a couple of sprints leaves that team short of people and the work is unfamiliar to her, and when they bring in Peter to replace Jane there’s a really steep on-boarding curve as there’s no one there to help; no one who’s working in that particular way to teach him how to do it. Not to worry - the management team has the solution, and so begins the second phase of the transformation as the teams form Programmes. Each Programme team consists of three of the smaller multidisciplinary teams which structurally haven’t changed, but they now share ownership for their products and practices rather than every team owning one each. This cleverly solves the problem as it removed the single points of failure that their first transformation attempt had introduced - there may still only be Dave in his team, but if he goes on holiday there’s at least two others who are familiar with the product, the test suites and infrastructure and can cover for him relatively easily. Surprisingly, this new approach actually works quite well (and not just because it's an abridged version that I’ve made up). As time goes by the department is able to optimise further, teams become more efficient and they actually end up becoming an effective Agile working environment delivering high quality products to their customers.
After our whistlestop journey through this fictitious Agile transformation we’re going to come back to Dave, and we’re going to realise that actually we’ve caused another problem. Dave likes working in the new environment and his new team so he doesn’t really want to say this out loud, but actually…….he actually quite misses being part of the Test Team. He liked the fact that he was surrounded by people doing the same task as him, surrounded by people he could learn grow and optimise in his craft and specialism. He’s a tester and he’s proud to be a tester. He’s still doing that now, but now……its hard in refinement sessions when he’s the only person in the room that looks at the problem with his viewpoint. He feels the pressure (whether genuine or not) to bring quality considerations to the table, and he feels like he’s trying to push a rock up hill by himself. That hot-house environment that he was once in where he and his tester colleagues could rapidly experiment learn and roll out new approaches and develop their craft has gone, and now he feels alone. He has no idea what is going on in the other Programme teams, they are practically too far away and focussed on their own product to share the innovations and learnings they are coming up with. When Dave does manage to find something himself that helps him do his job better, he doesn’t have anyone around him who REALLY cares about it. What’s ultimately happened here is that we’ve taken our big siloed teams and broken them down into lots of little silos of knowledge and experience, and made it harder for those who might benefit from new learnings to communicate with each other and access them. In the pursuit of product focus, we find we are inadvertently harming the people who deliver them for us.
This is obviously an over-simplified and convenient scenario because I made it up, but it isn’t a million miles away from a very common story that many readers will be familiar with. It's my belief that the growing number of companies adopting Communities of Practice in recent years can to a large extent be attributed to variations of this scenario. A Community of Practice will generally thrive at the nexus point of three needs - where people are looking for others who share an interest in a particular domain, who are practicing a common task or skillset, and are looking for a community of other like-minded people. In our story, Dave is good at his job and proud to get better at it, but has found himself without that sense of community of other like-minded people around him or others who share his interest in software testing. He will now begin looking for a means to meet that need, both within the company he works for and beyond it. Whether he knows it or not, Dave has reached the realisation stage of his journey with Communities of Practice, the next step being for him to begin trying to find his community.
I’m always curious to hear people’s thoughts on the things I talk about, so please share your own experiences - be they similar or a million miles away to those covered here - and I’d love to talk more about them. The next stage of Communities of Practice will be The Spark, and with any luck should be with you next week 🙂
Thanks so much for reading, if you’ve enjoyed this post I’d really appreciate it if you could share it - alternatively you could always buy me a coffee :)