In my last post, I wrote a little of the history of the process at CivicActions and how we started to adopt the Agile/Scrum process. The first big step toward that was the formation of what we call Pods, or focused project teams.
The Formation of Pod One
It took about 6 months before we were able to roll all of our first Pod’s team members off of their other projects and get them into a place where they could focus. During that time, we worked on moving all of our maintenance projects to this Pod, to increase the focus of the rest of the team (who were not yet part of the pods structure).
At the same time, our Finance group began to create the tools to track this team and its capacity as well as how much work it was able to deliver to clients on a weekly and monthly basis. We needed some tools to really be able to tell whether this just “felt” better and did not change our efficiency, or actually generated some results.
Cleaning Up and Growing Up
While moving projects from the full team to the Pod did take some time and energy, what it did for us was to give us a clear picture of what our teams could effectively deliver to clients in any period of time. Essentially, it told us that what our clients got in value from having us do less than 10 hours of work per month for them was not what we were committed to. It took too much to manage and schedule without the results we wanted. Rather than changing the size of our Pods (the agile project team is ideally 7+/- 2), we chose to be clear about our service offering and to try to create some guidelines around how to make occasional work valuable to our clients and workable for our teams. Essentially, this was our Delivery group growing up and realizing what it does best, which is to provide the talent and passion of small, dedicated teams for iterative strategy, design and development.
This process also brought up a lot of areas in which we were not effectively serving our clients, taking too much time to get to important (but small) things, and generating a difference in how they had experienced working with us in active development, versus after launch. We did not want this gap. It was also hard to let go of certain clients who we had worked with for some time, not out of lack of passion for their cause, but rather lack of a “fit” between what they needed and who were were growing up to be as a company and team.
In some cases, we are still working with clients we worked with before our official switch to the Pod structure, and for some we found local-to-the-client or better sized teams for the scope of work they have ongoing.
Forming More Pods and Musical Chairs
Moving from one Pod to the point at which the entire company was organized into Pods was a challenge. As new projects came in, or did not, we formed and re-formed each Pod in our heads a thousand times. If this project, then these two together, if that one, then these two… and on and on. It seemed the Operation was an entity tempted to slip back into what it knew, however dysfunctional. There was the forming and the temporary unforming. There was the sharing of resources (which looked too much like our old system). There was the maintenance of the legacy resource request system (just in case). And there were still too many projects per team, which did not deliver focus. It took the better part of a year to get the team sorted into Pods, matched well enough along the axes of complementary skills, and as geographically close as possible.
But Revolution! At least our team was reporting that they were getting used to one another! They seemed to start to learn the particular personality of their teammates! Distraction seemed to wane!
Covering Skills Gaps
We still, at this point, had not yet applied the Agile/Scrum process within the teams. There was still very much a hybrid process happening, which had quite a bit of variation from team to team and project to project. It was not waterfall. It was not Agile or Scrum. But it worked for the time being until we got the teams all sorted. Getting them all to follow the same process was going to be the next step.
One of the things we noted early on, was that in our development team, there were a lot of specialized skills: theming, internationalization, complex site architectures, and other skills that everyone might possess a little and some a lot. There were other areas (notably CivCRM) in which our team either did or did not have experience. Using our old system of resourcing projects, a CiviCRM resource was just one type, and if the work was scoped and estimated, you could just make the request and when the person was free you would get their time. Organized in Pods, however, it was not so easy to just make a request, as that Pod’s leaders had likely allocated that person’s time doing whatever was on their list for that Pod’s clients. We also had User Experience/IA and Design resources who never used all of their time on one project or with one team, and so floated outside of the Pod structure. It soon became clear that we would either need to have a team in which we were all generalists, or create a structure by which speciality resources could be scheduled and obtained.
The Brain Trust
The Brain Trust is our name for the team of specialists within our team that possess more-than-generalist knowledge about Strategy, User Experience, Creative Strategy and Visual Design, Content Strategy, Campaign Management, Open Source tools like Drupal and CiviCRM, custom module development and other skills that our project teams do not all need all the time, but that greatly benefit our clients when they are applied when most needed.
Most of the resources in the Brain Trust are not a part of a Pod team, but others are, and make some of their time available for use by other Pods by special request. In this way, we do not need each team to employ all the time of each of the specialists, and the Brain Trust members can do the work that most excites them, even if that work is not in sufficient abundance in the projects their Pod takes on.
The Brain Trust also creates a convenient place to on-board new team members before they are part of a Pod, and to allow potential new team members a context that is similar to how our regular project teams work, so they can see if it will work for them.
Stay tuned for Part Three: Applying Agile/Scrum