A Day At Pivotal Labs in Chicago!
Published on 2018-02-18
4 min read
Last week our leadership did something I consider really awesome, they gave us the opportunity to learn from one of the top consulting software development firms in the world.
I had been very excited to head down to Chicago from Milwaukee to see the differences in how they operate versus how our team does. Meeting in Chicago means at least a 4:00 am alarm and a 90-minute drive before traffic - thankfully none of our team was late!
We arrived around 6:45 am and waited for everyone to arrive before breakfast - we ate with them (they get free breakfast each 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 really made paired programming simple, and quickly learned don't be a keyboard hog!
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 really enjoyed what they do.
With our product team 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.
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.
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 request) and ensure that good practices were followed. Further, if someone had to step away for a 1on1 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 quick glance at had a test file on the right, with the code on the left within the split screen editor. They always wrote their test first before coding, with very descriptive expected functionality to make it easy to learn of any problems later.
I really liked one thing our tour guide mentioned here about why they do this.
Yes, testing = 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 that it let them better control variable states within the function they were testing. Another huge positive of doing paired programming (switching partners each day) was the concept of context.
Each team member knew the code base very well, so switching between different parts of it was not a hard ask. I really liked this one!!
Many of the teams had their pipelines up on monitors or their individual 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 definitely enjoy utilizing.
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 really need this to be effective.
They knew their story and they didn't have many meetings. They didn't communicate story progresses via e-mail but via tools. This helped them track the context and changes within the story. A huge plus for their developer productivity - really awesome to see in action.
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 is possible. The focus will make development really intriguing in the upcoming week.
This will help drive us to design and plan better up front and also make sure changes in the code base don't break any of our original functionality throughout the story.
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.
Accelerating your own best practices by learning than from those who do it the best is usually a safe bet for improvement. We're absolutely 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 really 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 to Pivotal for the collaboration here!
PS - My training plan is going well (I made some updates to courses I'm taking). I'll share some of those learnings with you soon - have a great week!!