The Bermuda Tri-Agile

I am currently, as of writing this post, a software engineer at BNSF Railway, I have been working here for 6 months and this is my first enterprise / Fortune 500 role.

The best part about working at an enterprise company to me is that I get to observe the workflows and thought processes of people vastly more capable at my job than I, which has led to my insane amount of growth over just the past 6 months at this company.

I could (and probably will) write very colorful posts about how much new tech I have learned, best practices I have adopted or the exceptional mentorship I have received from my colleagues, but this post is going to be highlighting some things that I feel like most people and teams I have worked with are just lacking in general. The first concept is that of - Social Version Control.

Social Version Control

This is a concept that I have recently coined in my mind, and it goes a little something like this...

Friday Sprint Planning

Business: “We want to add a new approval step before a customer can submit an order. The requirements are in the BRD.”

Design: “Got it. We’ll work from the BRD and get the approval flow mocked up.”

Engineering: “We’ll review the BRD and start scoping implementation.”

Monday Standup

Business: “Small update: after talking with Legal, the approval step is only required for orders over $10,000. I updated the BRD.”

Design: “We already finished the flow based on Friday’s requirements. We’ll update the mockups.”

Engineering: “We pulled the BRD Friday and have been scoping against that version. We’ll review the changes.”

Tuesday Standup

Design: “Updated mockups are ready. Orders over $10,000 now require manager approval.”

Engineering: “Perfect. We started implementation using those mockups.”

Business: “Wait, manager approval? Legal confirmed yesterday that it needs to be compliance approval. I mentioned that in the Slack thread.”

Design: “We didn’t see that thread. The BRD still says manager approval.”

Engineering: “And the mockups we’re implementing say manager approval.”

Business: “I thought the BRD had been updated.”

Team	Their current source of truth
Business	Slack conversation with Legal
Design	BRD
Engineering	Latest design mockups

By Tuesday, nobody is necessarily wrong. They’re just working from different commits of the same idea.

Run, just keep running!

As mentioned, this is my first experience working for an enterprise company where so many gears turn at the same time just to scope out a single feature or release. I don't know if this is just something that BNSF needs to improve on, or the industry as a whole.

Just to be clear, I work at a platform level, meaning that I am a fly on the wall for a bunch of different teams and verticals and yet this problem exists across the board, which is why I am writing about it rather than just venting about a single experience.

Now, not every team suffers from this exact scenario, there are some teams that are also pushing as much code as they physically can without any clear direction or guidance from the business or design teams. This is not really a good thing though, as during bi-weekly demos, this is where a bunch of backwards progress happens as these teams finally receive push-back from business and design about the features they are shipping.

Following the feedback, these teams (more often than not) ignore / pretend to forget the critiques and continue doing what they are doing in order to promote as much slop progress as possible by the time the next demo comes around. This is the other repercussion of social version control, some teams just tend to ask for forgiveness rather than permission and end up having to bite the bullet of having to gather better requirements before aggressively pushing to the trunk.

So, no matter how you slice it, during my time at enterprise compared to my previous experience at Vesta (which I would consider a startup in the software space) it's clear to see that the time from concept to 'acceptable' delivery is significantly longer at enterprise.

The Bermuda Tri-Agile

Here's my clever play on words for today. There is one thing I have not yet mentioned in this post that I have been avoiding on purpose...

For those familiar with the industry - you may be thinking that this entire problem I have been babbling about between role-agnostic team de-syncs and 'social version control' can be solved by something like FigJam, an AI transcript tool during meetings or a good project management tool with Agile or Waterfall-esque methodology.

Well, I can attest firsthand that while this may help, it's not a golden bullet. Bear with me here, but I'm going to list some things that I have seen firsthand that render any of these solutions ineffective:

engineers not updating / resolving tickets
designs changing and tickets not updated to reflect it
business requirements changing and tickets not updated to reflect it
defect tickets filed from non-technicals against intended behavior (yeah)

This results in, hear me out, the Bermuda Tri-Agile: where requirements and conversations get lost in the midst of unnecessary layers of abstraction.

Keep Things Simple

Normally, I'd wrap these posts up with a technical solution to the problem at hand as I am the greatest backseat junior engineer known to mankind. I don't really have anything though. I think that this is an issue with human behavior rather than a technical problem to solve, so I'm not going to provide a technical solution because putting abstractions to auto-magic more things would probably just make things worse.

In my experience of managing a team of software engineers that collaborate with non-technicals, please keep things simple and avoid as much buzz as possible.

Requirements, designs, tickets and conversations should all be held in a single source of truth. (when in doubt, GitHub Projects is free :P )