How well do you remember who spoke, or what they spoke of when you graduated from high school or college? While I can’t recall who spoke or the title of their speech, I do recall from my undergraduate college graduation that the speaker was trying to drive the point home that to be successful in life we must be constantly learning, expanding our knowledge beyond our current capacity. At the time, I thought I had reached my full potential and the speaker was trying to sell me on piling on more debt to achieve yet another degree. So, I laughed it off.
I won’t give you my age, but I can tell you that I joined the workforce at the time that desktop computing was just taking off. There was so much advancement in technology year after year that I was spending a good chunk of my free time searching for books or attending seminars so that I could keep up. The internet has finally matured where a Wikipedia link or YouTube video keeps me up-to-date lately. After many years of this, I reflected on my career and surmised that this was what the speaker was trying to tell me.
Along the way, my career in software has seen its share of processes adopted by companies to solve performance and quality issues. Occasionally these improvement processes would be adopted and quickly thrown away for another, “better” process, sometimes all within the same year. What changed with each new implemented improvement process wasn’t the underlying work flow, but the names of those processes and the new documents we’d create to support each one. Just like learning the latest technology, I spent a lot of time reading the latest books or attending seminars to adopt the latest process improvement method. Once again, I reflected upon my career and was reminded that this was what the speaker was trying to tell me.
Sometime around the time that I matured in my career, Agile came along. What a breath of fresh air. Deciding to give more value to individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Just like before, it seemed like the time to start reading more books and attending more seminars. But something was different this time.
I remember taking part in my first team transition to Agile, with a two-day interactive training session. Scrum was the Agile approach we were being taught. We learned what Sprints were, who was the Scrum Master, who was the Product Owner, what is a standup and so forth. After two days, we marched back to work, patting ourselves on the back that we were now Agile. It was so different from all the other processes I’d learned over my career that this must finally be the answer we’d been searching for. Just like my graduation day from college, I felt I had reached my full Agile potential and there was nothing else to learn.
The first few weeks back to work we could barely contain our excitement. We did our Sprint planning, our daily standups, demos, and retrospectives. Quality improved and we were meeting deadlines. But as the weeks turned into months, I saw a change I hadn’t expected. Quality issues started to crop up again and deadlines started slipping. Not only that, but our excitement was gone. Could this be another failed process improvement method?
No matter what role I assumed in Scrum, I’ve seen this pattern reproduced time after time. Each time I revisited all the books I’d read, the seminars I’d attended, and the internet articles I read but couldn’t solve the problem. It’s about that time that I was invited to a recurring meeting to share my knowledge in a technical area with which I was well versed. We called the group our community of practice (CoP).
Here at ISE we implemented a Scrum Master CoP. The purpose of our CoP is not only to share our knowledge but to learn from the others in our field and to work out our problems. We make it our safe space for learning, where we can share ideas without fear of failure. We stop trying to solve a problem the same way over and over, and instead try to come up with new angles and fresh perspectives. We take this new knowledge back to our teams and ask them to experiment with what we’ve learned. I look forward to these meetings and can’t wait to share some new technique or get help on a problem that’s been stumping me.
So, what did we learn by implementing a CoP for our Scrum Masters? We learned to solve problems together, to reach out and ask questions of each other. Books, the internet, and seminars aren’t the only methods of learning. We each have something we can teach to others, we just need a forum where we can let others hear us. By doing so, we’ve begun to recapture the excitement, maintain our commitment to quality, and meet our deadlines.
I’m reflecting on my graduation day once again, and I can see that the point was not only do we need to continue to learn but to also continue to learn how to learn.
Are you experiencing a similar scenario and cannot find a solution? Why not try bringing a group of peers together as a community of practice and let them work on the problem. Be unafraid to try new solutions. ISE’s Agile journey has led us into adopting the community of practice approach and to branch out further into coaching others to be successful based upon our experience and training. We’d be happy to work with you to make your Agile journey more successful.