Last week our leadership team allowed us to learn from one of the top consulting software development firms in the world: Pivotal Labs.

I had been very excited to head down Chicago and see the differences in how they operate compared to our team. Meeting in Chicago means at least a 4:00 am alarm and a 90-minute drive before traffic - thankfully none of us were late!

We arrived around at their office around 6:45 am and waited for everyone else to arrive before breakfast - we ate with them (they get free breakfast every day!) before their daily stand up.

Why Visit Pivotal

We visited their office to learn from one of the best.

Immediately I was impressed with the dual-screen systems that made paired programming simple, and quickly learned don’t be a keyboard hog! Teams of two programmers sat next to each other, each with one monitor and keyboard that controlled their screen but edited the same code live.

They had spaces to ease collaboration with their team of teams set up. Each team had different ways of managing their agile process, but all teams had sticky notes everywhere, diagrams written on boards, and attitudes of people who enjoyed what they do.

With our product and development team fed and debriefed on the day, the main event began - the tour!

Learn more about Pivotal Labs by clicking on the link above.

Things We Learned

I’m unsure how much detail I can go into, so the things I’ll share will be things that could be found on their website with a few extra tips.

Paired Programming + Test Driven Development

Pivotal labs had dedicated work hours since everyone was co-located, allowing them to almost always pair program.

By doing this, they were able to constantly do code reviews (so they didn’t have to for pull requests) and ensure that good practices were followed. Further, if someone had to step away for a 1-on-1 with their manager, progress on the story could continue. Not only did they do the pair programming, all of the monitors we were able to get a glance of had a test file on the right and code on the left within the split-screen editor.

They always wrote their test first before coding (TDD), with very descriptive expected functionality to make it easy to learn of any problems later. I liked one thing our tour guide mentioned here about why they do this.

Yes, testing is a good practice and helps with future changes not breaking old code, but he also expressed the code quality increased because of how it must be written for easy testing.

One example used the dependency injection pattern because it lets them better control variable states within the function they were testing. Another huge positive of pair programming (switching partners each day) was the concept of context.

Each team member knew the codebase very well, so switching between different parts of it was not a hard task. Makes sense!

Automated Pipelines

Many of the teams had their pipelines up on monitors or their monitor to make sure nothing was broken. Their pipelines always included the basic deployment and automated testing within them, in addition to different features being added as needed on a team by team basis.

This re-iterated the practice to us and made me quite glad we were using it already. DevOps is still a fascinating concept to me and one I enjoy utilizing.

Focus and Context

Developers at pivotal rarely had meetings since they were co-located with their team of teams.

I felt like this was a huge reason for their success, because they didn’t have many meetings or reasons to check their email throughout the day. Builder professions need this to be effective.

Why?

They knew their user story and they didn’t have many meetings and they didn’t communicate story progresses via e-mail, but via tools. This helped them track the context and changes within the story; giving them a huge plus for their developer productivity - awesome to see in action.

What’s Next

For our team, I think the first big step we will be taking is test-driven development.

I absolutely loved this in practice and with a bit of a push from seeing others doing it so well - I know it’s possible. The focus will make development intriguing in the upcoming week.

This will help drive us to design and plan better upfront and also make sure changes in the codebase doesn’t break any of our original functionality throughout the story.

I can’t wait to try it out and also to do a quick run-through of all of our past testing, nothing like a bit more time spent to harden any descriptions.

Concluding Thoughts

Accelerating your own best practices by learning from those who do it best leads to sure improvement. We’re eager to dive in this week to start incorporating the learnings into our young team.

The director of their office in Chicago was well-read, and I’ll be asking him for some book recommendations since he kept quoting them throughout the tour (impressive!).

Lastly, it was great to have this opportunity and so important to always keep growing as you get more knowledgeable in your field. Huge shout out to our leadership and Pivotal for the collaboration here!