Lessons in Agile: Six Months at Pivotal

I didn’t pair or do test-driven development (TDD) before Pivotal. In six months I’ve learned as much about communication and process as I did about writing cleaner code. If you’re new to the Pivotal process, I hope these lessons serve you well in your journey.

Pivotal is making 40+ products on 40+ teams

Take the time to understand the big picture, and where your team fits into it. Teams dogfood each other’s software, and understanding the use cases of teams upstream and downstream from yours is the best way to understand what your own team builds, sells, and cares about. It is normal to feel overwhelmed. Also, teams and products pivot all the time. Don’t worry — it’s a good thing.

Pairing is life skills 101

A fellow pivot likens pairing to ‘an arranged marriage’. There is now another human head that you have to explain your thoughts to. With some pairs, you’ll have an instant connection; with others, you will struggle through differences before figuring out a workflow. But pairing with different people is what builds your character and communication skills. The effort may tire you at first, but you can rest well knowing that you are a better person than you were the night before.

Embrace feedback

Your goal is to be comfortable with your teammates. Bring up issues as soon as they arise and expect your team to do the same. If you are pairing with someone and a situation happens, address it right away. You will spend the next 8 hours with this person; you can make that time really fun or really awkward. Also, receiving constructive feedback is a great help. Your teammates did the work of scoping the problem and you just need to implement and learn from it.

Being kind goes a long way

You will realize this most when you pair with someone who’s greatly empathetic and sensitive to your needs. You will also notice when you pair with someone who flips through their phone or jumps around or hogs the keyboard.

You spend enough time being someone’s pair that it’s worth being a really great one.

Copy the habits of people that put you at ease. Ask your pair “Do you need a break?” “How can I help you with ____?” If they look unwell, frustrated, or distracted, address these cues and express support.

Pick up the stories you’re curious about, but with people who know it

When I first joined Pivotal, a lot of stories in the backlog didn’t make immediate sense to me. I got used to picking up a story and working/asking my way through it. But as I became more comfortable with stories in our backlog, I kept picking up the new things I wanted to learn about. I soon realized that I was always throwing myself in the deep end and not finishing stories faster. I tweaked my heuristic. If I want to pick up a story I have no context on, I should pick it up with someone who feels comfortable doing it. That way I can learn it but also make good progress. But if I’m soloing and see a story I have no idea about, I should not pick it up. It’s okay if I need a nudge, but if I’m flailing after 30 minutes, it’s more productive to put it down.

Honor (most) conventions

Resist the urge to break conventions. The productivity of a team is directly correlated with its consistency. Look at past examples of what teammates have done: test setup, file structure, commit messages, opening github issues, writing chores, etc. And if you see a better way of doing something, bring it to the team! What’s great about new people is that they are not yet immune to the problem areas. And conventions drive people to improve the generalized process for everyone as opposed to just optimizing their own way of doing things.

Keyboard shortcuts

You can write terrible code, and break CI daily, but if you know how to do it all very quickly, you will still dazzle your team. Pivotal has custom configurations for all workspaces; learn them so you can feel like a master of your art. Additionally, if a keyboard shortcut takes 1 second and saves you the work of 4 seconds, and you learn 5 of them, and you do each one 20 times a day, then you have saved yourself 300 seconds, or 5 minutes, which you can use to grab a snack and hit ping pong balls very quickly.

TDDing will be your greatest safety net

If you didn’t TDD before Pivotal, you will discover a new confidence when writing code. You will jump into refactors, knowing that if you missed a spot, a test will likely catch it. If you have to change a part of the code and discover that it’s untested, you will emit an audible gulp of horror. It will become a major retro item that week. Somedays you may even write too many tests. You may become emotionally attached to them and have to look away while your pair deletes the extra ones. But if you’re scribbling tests on napkins at restaurants, you may need help.

Play to your team’s strengths

If you’re like me, you may be reading Hacker News daily and convinced that your life mission is to get your team to use the hottest technology out there. But it may be wiser to use more primitive technology that is stable and your team knows super well, than to misuse the newest thing and it bites someone later. A great developer doesn’t just use the latest technologies.

A great developer has good judgment about which tool gets the job done best.

Fly solo

Pairing all the time at first helps build pairing habits and provides the safety of instantaneous feedback. But there are bits of knowledge that slip through the cracks, that you don’t notice until you have to sit by yourself and do all the steps. Soloing is a great time to fill in gaps in workflow and understanding and to explore the codebase at your own pace. It also boosts your confidence and gives you a good indicator of progress. You never know what you can do until you solo on it 🙂

Be a backseat driver

That is, when you can’t be the front seat driver. Coding is a learn-by-doing skill. And with pairing, you risk settling into a passive observing role. One way to ensure that you’re just as engaged when you’re not driving is to be a navigator and communicate what should happen next. This can range from very helpful to very annoying, so use your judgment and discretion.

Just ask

My pair once made a comment that I had an incredible trust in Google. He believed that the majority of questions anyone has can be answered by their teammates. Independence and resourcefulness are terrific, but it’s wise to recognize when asking a two-minute question will save you half an hour of searching. It’s even worse when you don’t ask your pair and start searching for the answer yourself; your pair may feel disregarded or insulted especially when they know the answer. If they know the answer, you’ll get it right away.

Ultimately, you want to best serve your team. Do the right thing, do what works, and be kind. Oh, and if six months in, you’re writing articles about how cool your company is and your friends are saying you drank the kool aid, realize it’s a small price to pay for working at a company that has great process and great attitude.

Thanks to Amelia Downs, Aakash Shah, Urvashi Reddy, Stephen Casale, and Caroline Taymor for their thoughts and feedback.