I have witnessed the birth and death of more communities than I care to count but I have never observed one quite like the Agile Community I started about 8 years ago. I’m not saying it was a unique sequence of events however it certainly is one that taught me so much about myself, communities and organisations that I wanted to take some time to share it with you.
In the beginning
I spent 7 years working for a large UK bank and one of the most rewarding activities was creating and sustaining an agile community. We wanted to be as valuable as possible and tell everyone in the organisation how awesome agile is, writing that today is simple in stark contrast to how it was achieved.
It all began when I joined a Scrum working group set up by some colleagues, having recently started using Scrum and spending many of my evenings attending meetups I was very excited to see what this internal group were talking about.
The working group took the form of experience report sharing on a fortnightly basis. I attended my first session and whilst the story shared was interesting I was overwhelmed by a sense of untapped potential, what this group needed I arrogantly thought to myself was to become a real community, not just a mechanism for broadcasting peoples stories about their attempts at Scrum.
Working with some key people from the group we reformed with some grand plans, yes we would start with a community but it would grow (we thought) and assume responsibility for agile capability within the bank (up until the day I left 6 years later I still had the original “Agile Academy” folder as a homage to what could have been). It was exciting, so much enthusiasm, so many big ideas, they were happy times.
So we killed it through good intentions, not once but many times.
Why did we kill it I’m sure you ask. It wasn’t intentional, in fact, quite the opposite. Much like the tail of Cats in Borneo it was a great example of people trying their best but not understanding the wider repercussions of their actions or the balance between short and long term effects. I won’t list every way in which we killed as time has withered those memories, what I can share is some of what I remember as the most interesting:
We treated it too much like a Project to be managed
We did a lot of upfront planning, we had big plans, we wanted to take over the world. So in our pursuit of doing so, we spent a lot of time focussing on what we needed to do to coordinate and synchronise. We diligently spent time creating a mailing list, chat room, setting up regular time in all members diaries. Unfortunately, we didn’t know Why. Sure we had a great idea of What we wanted to do and How we were going to go about doing it but as for the real motivation, not really there! As the community began to wither and die we reflected and whilst doing so came across Roman Pichler’s Vision Board and Goal Oriented Roadmap. In this instance, I think we went for control over collaboration
Lesson learned: Short term quick wins feel like progress. Make sure they are valuable to the people that will make your community successful with a clear vision.
We tried to do too much upfront
With energy now focussed on creating our community vision, the effect it had was fantastic. It pulled together the core members of the community, allowed us to have meaningful conversations about our raison d’être.
With hindsight, this should have been enough for us to start being useful, instead, having found a new toy in Goal-Oriented Roadmaps, I wanted to give it a go, ah the bliss of being an enthusiastic amateur. Needless to say, I spent far too much time putting together a road map that may have sounded great but was never going to be that useful. My desire to create drew me away from thinking about and doing meaningful community activities and thus stuck in roadmap purgatory community membership dwindled and with momentum lost the community once again began to shrivel up like a patio worm on a hot summer’s day. What we needed people said was leadership!
Lesson learned: Knowing where you are going is great, having a strategy for getting there can be very valuable. But having a roadmap for a community can hinder organic growth and for me dew me away from the important foundations of a community active recruitment, social learning and how it should be lead.
I didn’t think a community needed leadership
Leadership was probably a good idea, at that time though I didn’t think communities needed leaders and if there was going to be one it certainly wasn’t going to be. So with the community already having one near-death experience and currently on life support things were not looking good.
Back in that time I was quite dogmatic (as many of us before we know what we are doing) and held firm that a community should not under any circumstance have a leader. My inability to move away from this mindset led me to focus on all the wrong things for too long. I distinctly remember a scenario where I tried quite hard to entice a newly joined and seemingly confident community member to take the mantel of leader. When he knocked me back by default I became the (somewhat begrudging leader), which picked the community and got it back on its feet.
Lesson learned: For some the creation of a community requires self-reflection and introspection on who you are and what you want to get out of it. If this is you then being willing to change your worldview can make the difference between a hard and not so hard experience.
Too broad and thus too shallow
There was no focus or urgency anymore. The vision still existed but too much time had passed since creation for that original sense of “we have to do this!” had become more of an “I’m not sure I’ve got the time to help and even if I did what should I do” which made me think deeply as to what was happening.
After taking time to ruminate I hypothesised that by morphing the Scrum working group into an “agile community” we had broadened the topic out too much, people didn’t know how they could contribute meaningfully as we were trying to be everything to everyone.
With such a large topic it made focussing very hard as whatever we did we left a proportion of people dissatisfied and with a lot of the work falling on my shoulders I struggled to share the burden. I feel now the community could have been divided into smaller sibling communities creating more focussed areas of interest. instead, my opinion was immutable and the community continued as one amorphous blob. What most people wanted was answers to questions about how they could work with the project management framework, how to refactor untestable code or how to help a team realise empowerment. What they got were very broad and shallow conversations about agile values and principles which of course provided no motivation for the majority of people to turn up. Without people turning up the community shrunk to a few core, long-standing members and we prepared for the worst…
At this point, we probably should have let the community expire to give space for those enthusiastic parties with something to share to fill it with new communities. With hindsight and an understanding that once a community has matured and been self-sustaining for a period it can require transformation, a transition into another state (as outlined in McDermot and Snyders Community Lifecycle). I see that we were following a natural pattern, which if observed could have led to lots of new experiments and experiences.
Lesson learned: Don’t be afraid to let go. The death of a community can be the beginning of something even greater as this will remove constraints and change perspectives. With the resultant freedom allowing people to fill it in ways that are right for them at that time.
Didn’t get it endorsed and supported enough
The one recurring problem I have always found with communities is getting people the time to contribute. I was fortunate enough to get myself in a position where I had up to a day a week where I could focus solely on community activities, I was the exception however as everyone else saw community activities purely as an optional coming second to their day job.
If you want to make a difference the community is as much the day job as anything else.
Many of those in positions of power are unable to understand the plight of the average team member (which is why Go See is such a worthwhile practice). People work hard, are often not happy, are nearly always professional and this cocktail of variables leads them to not want to put in their mornings or evenings into supporting a community. The opportunities to learn in a social environment rarely override the pull of other activities such as binge-watching something on Netflix.
I was able to change this though (at least once) and what I found works is generally a mixture of two things, a strong purpose (the Why) that senior leaders can relate to and answering the “What”, which in many cases was “What’s in it for me as a community member” whilst creating transparency of the will of the people and making sure their feedback is heard.
Lessons learned: Having to convince senior leaders in this context can be a challenge. Good leaders will listen if you have a value proposition that is focused and meaningful to the objectives of the organisation and will listen and act when relevant feedback reaches their ears.
And so it survived (with a few lives remaining)
So through hard work, perseverance and sheer bloody-mindedness it survived. As with most things in life if you have a goal and work your ass off good things will happen, in my experience communities are no exception.
If I could leave you with one thought it is this, communities should not be a permanent fixture stuck in stasis, they are living evolving social organisms whose makeup and shape will change, sometimes a little, sometimes a lot. This is what makes them so worthwhile.
Make them short-lived, make them hugely impactful (even if it’s only to those involved) and acknowledge their lifecycle and use it to your advantage. Find a problem, find some people, be patient and don’t be afraid to let go.