During the past several months I’ve had the distinct opportunity to fly out to Chicago every week, working with an agile software development consulting firm called Pivotal Labs. I wanted to take some time to highlight some of my experiences and observations working the “Pivotal way.”

Truthfully, I had never heard of Pivotal Labs before our engagement with them but over time I learned they are a pretty big deal. Big brand names in aviation, social media, and insurance have all turned to them at some point to help them build projects the Silicon Valley startup way. What follows is my understanding of how these guys work (so take it for what you will) with my own views sprinkled in.

Team Structure

The team structure consists of some key members. Pivots (Pivotal employees) are full-stack consultants capable of writing their own tests while doing front and back-end development. They work closely with the project manager and product owner to manage scope and direction, face-to-face every day in a tight feedback loop. The necessary roles to be successful on a software project are:

  • Software Engineers: The people that write the code.
  • Product Owner: A person who knows the business intricately and can make make authoritative product decisions that align with the organization’s goals.
  • Project Manager: Collaborates with the product owner to steer product scope and direction.

High Fidelity Communication

The entire team sits together in the same space to reduce communication overhead. Pivotal requires their clients to come work with them in their office space. This reduces the organizational baggage and I must say this aspect was refreshing. After we got settled in, I rarely had to open my laptop to check my work email to delete the usual 10+ cross conversations going on from overuse of an email distribution list. If you have a question you turn to your left or right and ask the relevant person.

The Code is the Documentation

Big fat requirement documents are no longer the cool kids on the block. Agile software development dictates that short and concise user stories are sufficient for capturing requirements. Software is dynamic and any assumption can change anytime business requirements or the product owner changes. You may have used tools like Trello, YouTrack, or Pivotal Tracker to track user stories but they are not artifacts that should be maintained or archived. They are simply side effects of software development.

Lets say you left a project alone for one year. When you return to it and want to familiarize yourself with the way the system behaves, what are you most likely to trust? A requirements document? Maybe a portion of it. Archived user stories? Test cases? Maybe. But you and I both know the probability of those artifacts getting out of sync. The only authoritative source is the code and even better would be the unit tests and integration tests…

Test Driven Development

In the same way continuous integration has become an industry standard, test driven development (TDD) is also exploding in popularity. TDD is a development process that relies on short development cycles where automated unit tests and integration tests are coded into specific test cases that pass the user story before the code is written. By forcing a developer to think about the behavior of a piece of code before it is actually written ensures it will live up to its desired expectations.

Automated tests require writing code. There is no easy way of getting around it. At Pivotal, we had zero quality assurance folks allocated to the project. The developers are responsible for writing all of the unit tests and integration/feature tests for the project. Once deployed, the project manager does a quick verification the software’s behavior matches what the story said prior to the product owner reviewing the changes.

That’s not to say quality assurance is not necessary or important. There were other projects ongoing at the Chicago office that used QA to do exploratory and user acceptance testing because human users will still find ways to break software that automation just can’t account for.

Practicing TDD was very revealing. It felt liberating to have lower overhead and process around deploying code to production. However it does take some disciplined practice. Like most developers, I am slightly narcissistic about my work and felt I could hold myself to the extremely high standards TDD commands.

On two different occasions, I found myself dismissing pieces of functionality as not testable before I was proven otherwise. While there were a few scenarios where our team agreed a piece of functionality was not testable, it’s a reminder that you must constantly hold yourself to the high standards this process requires.

Stating that something is not testable is not an excuse when operating in this paradigm. You either find a way to test the code in question or you don’t deploy the code at all. Actually, if you are practicing TDD properly, you will not have written any production code anyways so it should be a non-issue. Sometimes it is necessary to perform exploratory coding to figure out what an API does before writing the tests but 100% coverage is the goal.

An impact study on TDD was performed at the University of Mississippi. The study showed that productivity and quality of the software developed through TDD was clearly better than the traditional human approach. It also gives a developer greater confidence to make changes as new requirements come in because the behavior of the system can be verified in real time. I felt this first hand and it’s probably the main reason I found TDD useful. We wrote many times more tests to the amount of production code. Even if I didn’t write any of it, I can quickly come in and start making changes without worrying about whether I broke existing behavior.

This is a serious trend and the benefits are numerous. I am 100% in favor of test driven development but it will only be successful if the company you work at has bought into it. Pivotal practices it religiously.

Pair Programmingpivotal-computers

The Pivots pair program 100% of the time on their work. I understand it helps break knowledge silos and increase code quality most of the time. However, I still don’t believe pairing is the most efficient utilization of development resources. It feels like an expensive replacement for code reviews, communication and team members rotating project work tasks. Pairing was the least enjoyable aspect of this experience for me. It is more of a personal preference than a mark against Pivotal. I won’t go into more detail here as I have already outlined the problems with pair programming elsewhere.

Pivots Rotate All the Time

The Pivots rotate across client projects and within the project they are currently assigned to work on. The members on our team have changed 100% approximately four times in the seven months we worked with them. Pivotal will tell you it brings new perspective to your project but I feel like it benefits the Pivots more than the client.

Re-explaining and revisiting old topics many times for new team members felt like a time waster rather than keeping a consistent set of Pivots on the project from the beginning. I see the rotation as a perk for the Pivots to keep them interested in their work with fresh projects and technology stacks.

Working 100% in their Offices

The most common issue Pivots face on projects have more to do with their client’s organizational baggage than the project at hand. It’s why they require you to be on-site to get you away from the bureaucracy. A lot of Glassdoor reviews of former employees confirm this sentiment. We accomplished a lot in their office but we did face some bottlenecks when trying to reintegrate back in house as is the case with just about any project done remote.

Lightweight Micro Services

Lightweight micro services are a common practice at Pivotal. These services are independently deployed service oriented architectures (SOA) characterized by decentralized governance and decentralized data management. These granular services are preferable to the monolithic enterprise service bus (ESB) end of the spectrum.

Micro services are a great idea if you want the ability to easily swap them out for another implementation. A monolithic service going down could take out many dependent systems with it. Resiliency to upstream service degradation is preferable to one big fat service. It also makes continuous delivery easier as the system components are segregated.

Under this approach, the complexity of monolithic architectures shift into network problems like latency, load balancing and fault tolerance as each micro service talks to other services to accomplish their goal. Perhaps the biggest problem I see with micro services is the increased knowledge barrier to maintaining and updating each distinct service (hopefully architecture and standards are defined upfront).

There are bigger considerations when choosing between the two but Pivotal will steer you toward micro services. I think each approach has its own valid use cases.

DevOps = Developer Empowerment

Another trend that Pivotal practices is DevOps, the blending of software developers and infrastructure engineers through collaboration to achieve automated processes for software delivery. I hope this new paradigm shifts in more empowerment for the developer to have more control over deploying what they build. After all, who would know better than the person that built it in the first place? DevOps is everyone’s responsibility.

Free Food & Video Gamespivotal-food

Keeping in tradition with the Silicon Valley way of doing things, unlimited snacks, drinks and alcohol were just a few steps away. Each morning breakfast is catered in and usually lunch on Wednesdays during a tech talk. The hipster tech office would not be complete without ping pong and video games. They even bought Hydro Thunder for the office Xbox for me on a help desk ticket. See how far that kind of request gets in your approval flow at your current company.

A sizable portion of today’s workforce doesn’t get paid by the hour or even get overtime. It is in the best interest of employers to energize and caffeinate their employees while at the office to encourage more office time and less traveling out for coffee breaks or lunch. Strategy Business said it best: “If the provision of free food and drinks can save 30 minutes of time, five days a week, for 50 weeks a year, that adds up to 125 hours of downtime avoided, the equivalent of about three weeks of full-time work.”

Repeatable Processes

Perhaps the most important observation I came away with was their unwavering commitment to their process. Don’t have a product owner to get the project started? Oh that’s too bad, come back when you have one. Want Pivots to come to your place of business to work? Nope. You must work in their office. When I look around at Pivotal, I see a very cookie cutter template across the teams. Each team uses the same set of build and code tools more or less.

User stories are stored in their proprietary Pivotal Tracker tool. Building a server? They will use Spring. Building a mobile app? They will be building native apps (no Xamarin or React Native). I’m sure there were some projects that deviated from the standards but I would recommend if you’re going to work with them your technical resources are included in the conversations upfront to avoid a lot of conflict.

Unifying how all teams at a company build software allows you to easily move engineers around, scaling a project up or down as needed. Internalizing team member rotations within a company might also be a good benefit for employees to spread fresh ideas to new areas of the business.

Pivotal’s demands meant the majority of the technology decisions were in their hands. Although I am confident the solution we built with them is solid, their technology stack “template” may not be right for every company. I would recommend businesses that need to supplement their workforce with contractors to start involving the IT team in reviewing the statement of work. Bringing in various contractors for different jobs means low consistency across projects and increased maintenance when it is brought back in house along with everything else you already have to maintain. Unless of course your tech stack is already compatible with theirs then this is a non-issue.

Takeaways

What Pivotal sells is utterly simplistic yet hard in practice. Anyone can read and comprehend the concepts behind extreme programming and agile software development. Implementing those practices and following them is what they are here to help you with.

If you are a company simply looking to supplement your existing workforce and/or already understand and practice XP, then Pivotal is not for you. Their biggest strength from my perspective is their stringent practice of extreme programming principles. Of course, the engineers were also experienced in their area of expertise. We didn’t spend a lot of time researching how to accomplish something because they knew their stuff.

Pivotal can help your organization cut through the bureaucratic noise and accomplish something otherwise encumbered by existing process.

This slideshow requires JavaScript.

3 Comments A Client Perspective on Building Software at Pivotal Labs

  1. clay shentrup

    Interesting. I worked at a company that did a Labs engagement in 2010, and I had pretty much the exact opposite experience with pair programming. Having worked at a variety of startups since then, I’ve never seen the same kind of quality and productivity with non-paired teams. I’ve never found code reviews to be a substitute for pairing, and I find them to be almost excruciating in terms of the interruptions and bottlenecks they produce. Though I think a more “fair and balanced” view is articulated in this piece.

    http://phinze.github.io/2013/12/08/pairing-vs-code-review.html

    Reply
    1. Adam

      I think it comes down to your environmental preferences. I also heard of others having a more enjoyable and also less enjoyable experience.

      Reply

Leave A Comment

Your email address will not be published. Required fields are marked *