How CivicActions Adopted Agile/Scrum – Part One – The Way We Were

“A Quiet Revolution” is how I can best describe the process by which CivicActions has, over the last two years, adopted the Agile/Scrum process as our means of working with clients, internal teams and one another. And it continues as we learn more, add team members, work with new clients and shift into our own, more functional and agile organizational structure.

Our Ecosystem

When I first joined the team, the process of acquiring the team members with the requisite skills needed to complete a project was based on role+time requests on a per-project basis from each of the Project Managers. These requests were then matched to our team’s availbility and skillset and “leveled” which gave no priority to one project over another. It seemed the most egalitarian way to balance the needs of clients and the availability of the team. At that time, there were two, then three, then four Project Managers, which is when this system really started to challenge us.

How We Applied Agile (at the time)

Well, really, we didn’t. Between the Project Managers, and some others, there was knowledge of Agile, but only our newest Project Manager was ScrumMaster certified. It was a process that many of us pined for in terms of simplicity and clarity, but did not apply at the level that it was going to make its way into our day to day process. It felt somewhat insurmountable with the way that we assigned resources to move to this type of process while we also worked on 16 or more projects at a time across the team. It felt dangerous and risky.

If it can be said that we applied anything agile across the board, it was probably the concept of feature teams, though we did not give our feature teams the benefit of focus through the completion of their feature.

What We Learned

  • Teams were always evolving and changing around the set of projects each person was working on. There was little gain in familiarity of work-style, or communication style for any one project before the work of that project was done and each person was off to the next project.
  • It was hard for our team to maintain focus with multiple projects. Even slight shifts to a project or development schedule resulted in sometimes unpleasant confluences of work for some of our team.
  • Our process and makeup limited our flexibility to respond to expanding needs. Every hour of our team members’ time scheduled on one or another project allowed us no capacity to overrun a schedule without impact elsewhere.
  • Our distributed team (everyone works at home) meant that there was little of what I call “Learning by Osmosis” happening among team members. We had to convene calls and run formal agendas to discuss process at almost any level. We did this, by pratice area and project team, but it was resource intensive and hard to apply lessons learned because many of the challenges were actually caused by the process of assigning resources to projects or were very project specific or hard to diagnose once we all could get together to discuss it.

Our First Target: Focus!

Focus allows time and presence of mind for quality work. Improving the quality of our work for our clients was Job #1. We want as a company and as individuals to deliver our best work for our clients. It is our way of changing the world and working for good. Our Revolution had to begin with getting each team member to a place where they could focus more completely on their work.

For a team of more than 30 people, working on more than 20 concurrent projects (some in active development, some post-launch, and some in a slower maintenance mode) across many time zones, generating space for focus was no small feat. It hurt my brain to think about it. I took out butcher paper and made maps of our team and what projects they each worked on. I used crayons, post-its, markers. I broke our team down and built it up again. And it came to me! Pods!

The Answer? Pods!

It seemed so simple! Why not let a Project Manager and a Technical Lead just stick together for a while and work on maybe more than one project in a row? At least then they could get to know each other, and how they each liked to communicate. And while we are at it, what if they also have another Engineer on their team so they can all learn to work better together? And so on, and so on.

Now, at the time, I thought this was a good idea, but as soon as my head stopped hurting from thinking about how to create focus, it started hurting again thinking about how we would move from where we were to where we needed to be.

So, following well known wise words, we started the journey with a single step. Create one Pod.

I discussed the idea with Owen, our Director of Engineering, half-expecting to hear that there was no way this would work due to the technical skills of our tech leads, and how each project was special and therefore… But he got it! And it seemed like it was worth a try to him too!

J and Kevin were our test case. They liked working together already, had similar desires in terms of project size and issue area, and they are both from Canada! Alex in Spain was added to their team due to his time zone, and the fact that J and Kev really liked working with him in the past. Alex and Kev had complementary skills. We let this mini-team know that they would have all of one another’s time from here on as an experiment in what was possible in workability, balance, and client service when there were no question marks around resources, and the team could just relax and dig into the process of getting to really know and work with another while they worked on each of a series of projects.

A Revolution indeed!

Stay tuned for Part Two: More Pods!

2017-03-31T06:20:06+00:00 Categories: Agile, How-To|

About the Author: