Our teams include a mix of functions. We used to think the all code-programmer team throwing something over to an all Quality Assurance (QA)-tester team when they are done was good. It wasn’t. We instead elected to have a mix of QA and Developers on the same team. If possible we had a technical writer, a designer, and surrounded the team with availability to subject matter experts for security, architecture or whatever the need was. This re-mix of a team met with resistance in some places because ‘my people’ and ‘your people’ wasn’t as neat and clean as it was on paper. Especially when we took these teams and co-located as many of them as we could. This is what we found: Feedback was Quicker as we created software. We aligned our expectations on what we needed to deliver and how. We had many eyes with many perspectives examining and contributing to make the solution better. Many times we were able to deliver more of the solution – than just a piece of it. We learned more of everything it took to get that solution through the organization and into the customers hands. This also meant we could improve the organizational processes and tools as we went. There were also the difficulties… some teams matured faster than others, skipped or adopted practices without sharing the best of them across the other teams. Sometimes it might have felt like a role was isolated or not supported within a team.
Abbreviated as COP – a Community Of Practice targets something specific. This can be more persistent and dedicated for a role such as a QA or Dev COP, or spin up and only occur when needed such as a Database COP. A scrum master and the program lead or subject matter expert can form an effective effort in establishing one in any program. For the more persistent role-based COP, I will often hold this at a regular fixed interval. Some organizations may prefer weekly or once every two weeks in order to:
- Discuss and Decide
Continuous improvement for quality and best practices for the role across all
The meeting content and method can change from time to time – the intent to grow this role or domain knowledge remains the same.
As a Working Session
This time is used to address a particularly large program problem. Remember, in-sprint work will often rely on cross-team communication as well. So a working session might be appropriate. Here are some examples:
- All testers moving test cases from one tool to another.
- A demonstration or ad-hoc testing of a feature together.
- Regression testing – handing out tests and recording bugs on the spot. Perhaps a good old-fashioned ‘bug-stomp’. (Usually I invited developers here too. The same could be done on a team level)
Discussion and Decision
This might be a role retrospective, communication for a process change, or sharing of a teams specific problem/decision. If for instance a program was adopting a process change for the first time I might solicit and list some good and bad practices, generate some examples, and afterwards post these as a wiki. Any decisions might not need consensus, but I certainly wish to get everyone’s input and involvement. Decisions by the group should be noted, as well as some reasons. We are not only developing some training material for anyone new to the program, but lightly remembering why we tried something. We want continuous improvement, so if in the future these reasons no longer apply we can again ask the question. We WANT to move forward and get to something that is actionable. Agile Scrum when done correctly is active! These decisions aren’t necessarily set in stone, they do however help guide us for the moment. Good empowered teams naturally try to improve tools and processes.
Coordination and Learning
Empowered teams are actively learning. If across the program the we are actively adopting a new tool, technology, best practice, process improvement, and simply wish to share a learning experience, the COP is a great place to do this. It can also be a place to foster shared leadership. Different members of the COP might take turns presenting or leading the group on particular topic. Teams will often exhibit this shared leadership behavior from time to time. Even visiting SMEs can have a chance to teach. This might be an opportunity to set expectations for the next sprint. This helps grow responsibility for people within the role especially when there are so many responsibilities to be . It is a chance to level up. Aside from the day to day sprint activities, what additionally enables us to make the program better with the perspective that this role brings to every one of the teams? Examples might be:
- Test Driven Development
- Best Practices
- Automated Testing
Usually a wiki or a shared OneNote sufficed to keep track of useful information. Some meetings were even recorded as future training sessions. Any whiteboard drawings might be replicated or photographed for purpose of teaching, improving upon, or communicating outward.
- Give everyone some individual support. How can they grow? What might be their next role in helping the program? What are their concerns? How can I help?
- Have some fun! Someone said I cannot look at the sun, but by it all things are seen. It is often when we are not directly working on something, and instead allow a bit of time for creation, risk and innovation – these endeavors will help the program in the long run. A bit of ‘lightening up’ now and again before getting back into the trenches helps the team form and do their best work.
- Thinking ahead. Pull everyone up just a bit. It is usually harder to learn when your head is down. Too much activity might point to an unsustainable pace.
- A visit? How close can we get to a customer or a remote site?
- A Sense of Balance. I ever ask of myself – am I distracting or am I enabling? Is everyone so buried this particular week that actually cancelling would be wise? Cancelling a meeting was something I did not want to fall into the habit of doing, but at times made perfect sense based on need of the program. Here I questioned a simple timing mechanism and am stressing the ability to be flexible.
- Tactics for involvement such as a round robin, rotating topic presentation, asking for a group list of top concerns and letting everyone have two votes for which priorities to pursue as a program, a ‘fist of five’ for confidence in the product, or a completely different activity (volunteering in the community) to bring them together as a specific team.
Make it your own! You are a there for a reason, with the qualities and leadership you bring. Stressing what was next, to go after, often relied upon some timing and maturity of the program. Knowing how to manage growth is often one of the hardest things any organization can do. Different areas of capability, scale, new skills, using a tool differently, or even discarding a process that wasn’t working. Higher quality in software is not always an immediate speed boost in the velocity of our teams. It is however a long term speed boost because we make less mistakes and wrong turns. Keeping architectural concerns or a roles growing strong across several teams can be a challenge; a COP can help.