In my last post, I wrote about the important step we took in forming our single, large team into small, focused project teams (called Pods), and how we did that. Once we got the important step of generating Focus out of the way with the Pods, the way was clear, even though we could hardly believe it, to start to apply the Agile/Scrum process.
Training the Team
We started this by sending all of our Project Managers to school (at Scrum Alliance, to get ScrumMaster certified). They came back with wild tales of simplicity, easy to remember structure, and absolute clarity of communication! They marveled at the ability to all of sudden see “percent complete” clearly! They thrilled at the idea of a self-managing team! As a group, we finally had a shared vocabulary from which to discuss our project process and the focused teams necessary to attempt to adjust the process we were using company-wide. And then the challenges of applying any process came up:
- The role of Project Manager shifted dramatically.
- There were different ideas about when to use Agile and when not to use Agile.
- There were different versions of Agile.
- There was variation of interest in applying this specific process (over other options).
- There was variation in the understanding and interest of the team members in being self-managing (one of the core requirements of a successful Agile team).
- There was variation in the level of training in Agile across the team and how it applied to their specific role. This was especially challenging for our Creative team which was used to being asked for complete design and wireframe documents before projects started into development.
- There was a challenge in selling the new process to our clients.
We are still in the process of rolling the Agile training out across our internal team and each of the Pods, but have a budget for each team to use to work out their process related to Agile and to get training if they still need it. We require any new members of our team to get Agile training before they begin working with us.
Keeping it Agile
Now that we have applied the Agile/Scrum process to our Pods, the challenge remains to apply it UP (so that the entire organization of CivicActions lines up along this process) and keeping it Agile across the board in the Pods. The challenge lies in avoiding micro-management, while also maintaining some level of standard and similarity across teams. There is a lot of freedom in a loose framework like Scrum to make it work for the specific team using it and for the specific project, but keeping it similar enough that our clients recognize our company’s process regardless of the team they work with is ongoing.
- Training our clients in the Agile/Scrum process begins when they first contact us. Since this is the way we work, we describe it to make sure our clients are aligned around how our work is done. Since they typically take the role of Product Owner in Agile, their buy-in is important.
- Identifying and enforcing best practices has taken on a rhythm within the company. Best practices are shared with Pod leads, and at times brown-bag sessions are proposed for a specific team to review a recent success (or breakdown) and what they learned from it. A shared knowledge base provides a broad selection or resources to anyone on the team. This is one of the ways in which we create the Learning by Osmosis that might happen in a non-virtual environment.
- We let the teams come together. Even though Agile/Scrum is the best way to work with a distrubuted team, it is important for people to see one another and to have time to connect and work in person.
- We participate in the ongoing process of obtaining (and re-obtaining) buy-in internally and externally as we formalize our version of the framework as applied our company’s type of projects.
- We support the tools to support the process. This is an ongoing process, but one in which our team feels free to suggest tools that would support the effective delivery of our work using our chosen process.
- Sprint retrospectives are happening across the board.
- Feedback from retrospectives is shared on lists, to which Account Managers are subscribed so they can share best practices across pods.
- We have an ongoing process of culling and discussing what we are learning, and also a framework for change management/rollout within the pods and the company that gives us rails on which to roll out any changes we are making to the process we are using.
- We get a LOT of direct feedback from clients about how the framework and process are working for them, through retrospectives, and also through their account management contacts. We use this to improve immediately when we can, but also to target our next client education materials, and adjust other processes if needed.
I hope that this series has helped to demonstrate a bit more how we do things, but also what a process it was to determine what was not working and how we wanted to do things in the future.