First off, working fast does not mean sloppily stuff code into file, then stuff file into production. No that is not what I mean at all. What I am talking about is different from the harried quick deploys that a lot teams unfortunately undertake.

So in my early days, I was not invited to anything but stand ups. I got 3 minutes of fame daily and that is all the time I got to be heard. The rest of the time was for Seniors and Leads to discuss things out. With time and commits merged into master, I started getting invited to product definition meetings where “new” features were being discussed by folks outside of engineering and I started noticing that engineering leaders responded in one of two ways ( for the most part ) to such requests.

Engineer Response 1

The-NO-Response, I call this one “start with NO”. Have the product folks work hard to convince you to spend your precious and time working on this feature. The product person was met with nothing but resistance and the final scope of the feature would be about 10% of what the product person requested. Now there is some value in doing this and some of you will recognize this as a valid path to at MVP ( Minimal Viable Product). This practice essentially took a big idea and whittled it down into something that can fit into a sprint. The process was painful to watch, especially when the receiver does not understand that a MVP is what is being scoped out from a larger vision.

Thing is I think the engineer was not really trying to get a MVP out of feature, a lot of the time I think what was happening is that the engineer was trying to talk the feature off the table entirely. The individual usually wanted to spend time pursuing technical endeavors such as improving tests, or upgrading a needed library or improving the infrastructure. All good and valid concerns such as paying back technical debt. From this vantage point an unproven, uninitiated features are a waste of his/her time. I was surprised by the push back and a lot of times I would wonder how the business teams are putting up with such resistance. The technical debt vs new functionality debate rages on, this post is not about that issue.

Engineer Response 2

Endless bickering and arguing. This would be especially pronounced if multiple senior engineers were involved. Arguments that stretch for days about infrastructure choice, design choice, algorithm choice it would take a lot of time to reach a conclusion or get something productive to happen. This would be even worse if time pressure was added. The time stress would cause flare outs and even weirder responses. The entire time I would sit there thinking….wow we are arguing about arcane tech details no one cares about. In the last ten years this has improved in a huge way, implementation details are kept hidden. Discussions happen on a higher level, however arguments regarding philosophy are common place. I was happy to be invited and I would use these situation to listen and observe. I would ask questions once in a while in order to move the ball forward but in general I knew my place and I would remain out of the fray.

No more talk, time to code.

Most meaningful feature walk throughs or introductions would follow this now very familiar pattern. It would be Response 1 or 2 or some combination of both. I wondered in my mind at times, “hey some of what they are asking is easy” . One out of the 5 things they wanted is hard and engineering is pushing back on the entire thing because of that 1 hard thing. The situation was untenable, but I have found myself on teams that arrive here multiple times. I don’t think this happens intentionally, some of this is simply how engineers communicate. Back in the early 2010's codes of conduct were not as common place as they are now. Burnout was common, macho bravado ruled the earth. Feature grooming was likely an aggressive activity, with a lot of push back and complaints lodged at the junior product manager sent over to get “buy in” from the engineers.

Now that I was part of this new forum I began building relationships with the business folks ( product, marketing, account executives). I never wanted to break ranks outrightly with engineering so I would probe my leads on why the push back was so strong in private. Why are we calling out requirements ( we know will never be complete and detailed enough ) ? I never received a satisfactory answer. What I imagine is that a lot of Senior Engineers/Leads have been trained by circumstance to guard themselves and their teams from burn out and over commitment. No one ever told me this outrightly, now that I am in a leadership position it is something I notice myself engaging in this behavior to keep my team from being thrown under the bus.

The Plan (Minimal Maybe Viable Product)

At some point I got tired of the bickering, the endless jargon, the constant back and forth. The problem I began understanding is that we were making tons of assumptions based on thin requirements or light mock ups. I decided I would quickly build a prototype that the business folks wanted and use that to explore and understand future behaviors and configurations. I spun up a very quick version of what folks were asking for. When I say quick I mean super/duper quick. I used Rails Scaffolds where I could, links did not work , buttons were broken ( but something displayed ) I had url paths added so that I can fake navigate. Although we have better tooling today with things like inVision and/or sketch not all companies invest in such tools. Product folks would build out mock ups and watch them bite the dust on first contact with engineering. To solve for this I created flimsy prototypes in order to explore the problem space and understand requirements a bit better. When I first told a colleague about this approach, he told me to be careful because the prototype might become the actual production code. To guard against this the prototypes only sort of worked…they were Minimal Not Viable Products. With time and other engineers getting involved, this practice evolved.

Benefits of the approach

First off, this “light weight experimentation” or “spikes” (as they are lovingly called) caught on in a big way. Doing these little mock features had all kinds of benefits:

1. It got the engineer thinking about what will be needed if we really build this out for real. This was an immense value.
2. Estimates became way more accurate. While doing a little fun hacking around you get to understand what the tricky bits will be and that paid off right away in “better” judgements around time and complexity.
3. Whoever did the prototype came up to speed quickly on the details and could now serve as the domain expert. There was less reliance on a lead hashing details out, this made the process scalable compared to what we had before.
4. Engineers like coding ( no surprise ) more than imagining how something will work on paper or in Photoshop and so it was a win from that point of view.

On any team where I introduced this, it sort of brought some positive mojo back into the team. I have thought about this a lot and maybe doing this kind of work brings engineers back into “tinkering” mode which is a great feeling.

Eventually with time as the team got better and better at this practice, we began making small changes to our prototyping practice so that we can pivot to production readiness faster. Some examples:

1. Engineers started practicing TDD, although when I first started I skipped this overhead. Including TDD made a big difference in time-to-market when we decided to productionalize. In hindsight, I should have never stopped doing TDD for this, but that is the journey.
2. Engineers started adding small flags and config switches to the code so that we can release parts of the code into production without exposing the softer bits which still needed to be hardened in development.
3. Previous to this practice the scrum master would assign tasks in a ad-hoc fashion. Having deeper insight into how the work breaks down into tasks allowed for much better task breakdown and assignment.

Refine and Refine some more

Today one of the first things that happens on my team when we decide to build a big new feature. Is that we create a “spike” ticket or a “research ticket” ( for those of you in the enterprise world ).

Here is the workflow that has proved to be successful at multiple companies:

1. Create a research ticket with a strict time box around it. 2 to 3 days tops. The time upfront pays huge dividends in terms of accuracy of estimates and scope of work.
2. The deliverable from the ticket should be a small simple prototype with some of the mainline behaviors requested. The code should be chockfull of notes // documentation ( Not Helpful Code Comments ). None of these notes make it into production. These are notes to self that will be used during the real build out. Funny side note: If you ask an engineer to hand in some documentation you will likely never see it, but if you ask them to write some code and put some notes in a file and commit to git…that happens by EOD ( total magic ).
3. Present findings to the rest of the team. Communicating the hard bits, the integration points, third-party dependencies, unknown complexity that was unearthed all has to brought up and put in front of everyone.
4. Generally once the discussions above happen, the features is broken down and ticketed for real to be built for production.

This is a rough cut of the process that I proved to work well for me, I encourage you to take some version of it….refine it…then refine it some more.

Next Episode:

It’s the manager stupid!

This post is part of series:

Start Here

Part 1: Learn you something