The engineering discipline at Google can best be described as the Cowboy Methodology. This derisive monicker is used by agile practitioners to chide those who follow no process at all, the connotation being that they produce messy and often untenable results.
There are exceptions of course, many Google teams use various degrees of XP, Scrum, or something else entirely. However, these are few and far between in my experience. The lack of methodology predominates. This is not to say that software does not get written on time, nor is it to say that good code is not produced but the process under which it is, is largely non-existent.
When Wave was canceled, I started a new project with a colleague. We had a 6-person team and had set ourselves a 6 month goal for launch. Given entrenched practices at Google, I decided to try and run this project differently. We were fortunately armed with a product manager who was both very good and previously well versed in Agile methods. (A product manager at Google is equal parts Business Analyst, Iteration/Project Manager and Cheerleader.) It is too early to tell if the experiment has succeeded or failed, but I do have some interesting observations…
At first, everyone was enthusiastic about the project itself (quite an exciting area) and the people involved. Everyone had worked together before and respected one another. It was immediately apparent however, that terminology was a big problem. Most engineers are skeptical by nature and thus unimpressed with common Agile buzzwords: User Stories, Retrospectives, Showcases and Spikes rolled a good number of eyes. We discussed this early on and axed most of the names, replacing buzzwordy terms with less objectionable ones (Spike -> Experiment; Workshop -> Meeting).
Oddly, user stories were the next big problem. Let it suffice to say that you cannot convince rockstar backend engineers that every feature in an application should revolve around user behavior. Consequently, you’re not going to have much success with the vertical slice approach either (UI programming is anathema to many).
Other team members were willing to be more open. I was always extremely conscious of the appearance of too much process—it can make people dependent, and we neither had the resources nor the inclination for a curated, supervisory process. One advantage to our project structure is we don’t have managers, directors or clients telling us what to do. In that sense, we are akin to a startup. So we quickly replaced the story wall with a “task wall”, where stickies of undone tasks sat haphazardly until claimed, completed and discarded. There were no points, estimation or scoring. The theory being we could estimate velocity from the rate of task completion if necessary.
What else? Scheduled pair programming is out of the question. Iteration planning was largely unnecessary as we cut the process down to be very thin. The product itself is consumer focused so there isn’t really a client to manage. For a product like this, system metaphors are hard to come by as well.
So now we’ve ended up with something that doesn’t really resemble the canonical Agile method much. Have we whittled our way back down to the ranch of Cowboys? Not quite. Here is what did survive and what does seem to work in this style of environment:
- Stand-up: We are able to conduct a daily standup where useful if terse communication occurs. More importantly, it is enjoyable, people joke with each other and engage in a team dynamic.
- Retrospectives: I run one of these every 3-4 weeks when major issues need to be discussed and the next stage of the project decided upon. There is plenty of healthy debate and emergent changes in scope. Everyone has a goal after these meetings, and everyone feels heard, this is important.
- Unit tests: Our code is very well covered and tested for how much it changes. While not all the code is written in a test-driven style, the more critical components are.
- Code hygiene: Having an excellent code review/checkin process helps us keep ahead of most issues with code hygiene. Google’s toolset comes in handy here: providing continuous builds, a pre-submit queue and code review tools.
- Verbal communication/Co-location: We sit in a cluster of tables, very close to one another and can shout across questions or simply walk over with a minimum of effort. Engineers sit beside the UX designer and product manager too. So most technical and design doubts are allayed with this approach, quite effectively.
- Showcase: We throw open the demo to all interested parties (usually this includes other engineers in the office), and has been quite successful even prompting some other engineers to ask to join.
Of course, we are far from settled. It may be that we continue to whittle down the process and end up back at the Cowboy ranch. Or maybe we will continue to experiment. So far it has been interesting to see how the Agile process has worked in this kind of environment.
What do you think? Have we strayed too far from the holy path? Can Agile really work at a place like Google?