Grockit 4
I started a job at Grockit a couple of weeks ago. This has been my first chance to see what an agile shop looks like, and it’s an eye opener.
You show up at 9:15 am every morning. There’s a daily stand up meeting (truly stand up, everyone is around a circle), and then breakfast, which is served in house; people sit down and chat about stuff they’re doing, but it’s less formal than the standup is. (I don’t have a good handle on how retrospectives or user story planning work, but from what I can tell there’s an overall direction that is set during releases, and then the business owner participates in standups to ensures that everyone’s on the right page. Spot demos also appear to be frequent, although I don’t know how much of this is a conscious strategy.)
Following the standup, there’s a secondary huddle where engineers look at the list of user stories open, and pick off the stories that they want to tackle. Pairing is done by the tech lead rather than the individual engineers, and there’s an emphasis on switching pairs around. Tasks get written down on the whiteboard, photos with names are assigned to them for the day, and then it’s time to find a free workstation and move in.
Pair programming is the natural order of things at Grockit. The workstations (Mac Pros with 30 inch monitors) are all set up in exactly the same way (IntelliJ IDEA with Ruby Plugin, QuickSilver) and have two keyboards and mice attached. There are two engineers per desk. The first thing you do is bring up Pivotal Tracker, find the user story that you’re working on, and then mark it as “In Progress.” The user stories are typically single sentences such as “Put the top players per week on this page (refer to mockup)” and have points assigned to them by the engineering team beforehand. Then you discuss a couple of ideas, make sure you know what the state of play is, and start coding.
Only one person codes at a time. At this stage, I don’t know enough about the application to be effective on my own, so I’m mostly monitoring and following what my partner is doing. It’s an involving process to watch someone else code; you’re not just looking at the physical processes involved, but also the intent – usually I can catch bugs a couple of seconds after they’ve been typed, although I usually give feedback after we’ve reached a pause and I can be sure I’m not interrupting my partner’s flow. Actual disagreements are rare, partly because no-one is attached to an idea yet, partly because everyone is “on the stage” – you know that whatever you’re typing is going to be peer reviewed almost immediately, and it’s important to write something that’s going to be clear and acceptable to the partner at the time. I think that mixing pairs every day is also a factor here. Any time someone’s had a problem with code, it’s been new code that is unfamiliar to one person and not the other, so there’s a fair amount of learning that goes on each day.
It’s also draining. Reading code is almost as intensive as writing code, and there’s a ton of moving pieces, plus a couple of custom built frameworks that I’m unfamiliar with. More often than not, when someone asks me to take over or asks for suggestions, I have the odd experience of saying to refactor code using features that I’m not consciously aware of. I can say what to do at the time, and how to rework it, but when I get up from the computer, I have no clue what I just said or even what it meant. It’s a nice ability to have, but it’d be nicer if I actually knew how it worked.
The other reason it’s draining is because either you’re typing or you’re reading. There’s no downtime or distractions while you’re pairing. The “why” of this is interesting.
Grockit has email, but it’s mostly used for company broadcasts, housekeeping and customer feedback. It is not used intra-company, and this is a deliberate choice. Nearly everyone is in the same room. If you want to schedule something or start a group discussion, you mention it at startup and pull everyone in later. Likewise, there’s no instant messaging. No IRC channel. Nothing. So, no distractions. This took a while to get used to – I had to start scheduling and communicating with friends in one large block once I got home, and some people were even worried that I’d vanished completely.
So. You work until 1:30 pm, and then the lunch bell rings. Lunch is served in house, and is delicious organic vegetarian. After lunch, there’s a break where some people check their email on personal laptops, or play Rock Band, or run errands. People usually head back into the office at 2:30 pm, and then it’s pairing time again.
At this point, you’ve got most of the code written and you’re reworking and adding new tests to verify that what you’ve got actually works and that you can check it in. (Or the TeamCity build has broken, which results in immediate and productive feedback from the team.)
The test suite at Grockit is beautiful. Most of it is integration tests, with some mocks in place where they want to see specific exceptions. It makes heavy use of nested describe and contexts, and even has a very elegant use of should_behaves_like in the order processing logic that would have otherwise taken some complex metaprogramming of specs to do. There’s a strong bias to make tests useful and not repeat themselves, so tests usually only happen at one level. If the code can only be adequately tested using Selenium, for example, then there’s no point in writing unit tests for each method that would also test the happy flow.
Having said that, most of the tests involve business logic or concepts that I have to ignore because they’re not related to the problem at hand. Having to write or refactor tests while simultaneously not looking “over there” is mentally taxing, and then there’s the extra juggling involved with the mocking framework, selenium, and the assumptions made in the code itself. This is usually the point in time where my brain gets full. I have to pick up the threads of where we left off before lunch, so either I have to rummage around before I feel I know what’s happening again, or I just get a blinding headache trying to jump several steps ahead. Apparently, this is a common phenomenon during the first three weeks of coding, so I’m hoping it gets better soon.
At some point, the main user story is finished, tested, demoed, and handed it off to be accepted or rejected. Typically we get this wrapped up by 4:30 pm, and then pick off a couple of smaller user stories that involve front end work if they’re not too complex. This goes on until 6 pm, at which point the work day is over and everyone goes home.
And I mean, everyone goes home. There was one user story that I thought we could do, but was told “We can’t finish that; we only have 10 minutes left.” That’s discipline.
To recap: you show up at 9:15 am, do good solid work for eight hours, and then go home. You do not take your work home with you, or work on the weekends. User stories and estimates are scheduled so that all the work you can do is done in eight hours. Velocity is automatically tracked and measured using Pivotal Tracker on an eight hour basis. The hours you work is eight, and that’s the time you need to do a good job, with covering tests and code that checks the edge cases.
I like it. It’s not easy, but it’s so, so worth it to me.