Anatomy of a Prototyping Engagement: AnyCompany & AnyProto
Part 4: The Dev Sprints
This post is part of a series walking through how I approach a PACE engagement end to end: the considerations, the decisions, and the consequences of getting them right or wrong. Details here are anonymized and composited for illustration; AnyCompany and AnyProto are stand-ins, not a real customer or product.
← Part 3: The Scoping | Series index | Part 5: The Closeout →
Scene
The scoping proposal has been completed and presented, data handover conducted, assumptions and risks acknowledged, weekly sync meetings scheduled. Now it's time for me to execute on the plan and begin implementing the software.
I likely would have already started doing some of this even before the scoping proposal was finalized. In a lot of engagements, I can preemptively lay out foundational components like web hosting and distribution, auth, API routing, and compute.
In fact, I can use an IaC template that gets me well off the ground with an API-backed web application that deploys in under 5 minutes. Getting started is easy; knowing where to go is harder, and much of that decision-making has already been handled during the scoping phase.
Now What?
This one is easy: I'm putting my hands on the keyboard and getting started. I won't dive into what the actual implementation of AnyProto looks like here, but I do have some general guidance to make these sprints go smoothly.
Work backwards from the demo. After doing all the work required to execute on the scoping proposal, I'm well primed to tackle the business problem from several different angles.
It can be difficult to determine where to take my first bite, so it's useful to work backwards from the demo. After the scoping proposal, I should already have a good idea of what each demo should look like.
Hint: they're in the user stories I wrote. A well-executed sprint follows the proposed user story closely, according to what both AnyCompany and I agreed on.
Communication doesn't pause for development. During development I don't get a break from creating slide decks and presentations. Communication is just as important in this phase as it's been throughout the engagement.
This phase, though, is more of an exercise in technical writing than the rest. I'm in the maelstrom of development, weaving technology into an application that addresses the business problem.
The trick is that even while deep in technical execution, I have to consistently step away from the IDE to take on the role of educator, salesman, and thought leader for the enterprise. Those discussions then inform the work I do as a developer, forming a kind of flywheel.
Frontload the communication prep. I find it's better to frontload communication preparation so that delivering information stays as seamless as possible. The context switch between developer and business consultant isn't trivial.
I don't want to halt the flow state I'm in during feature development just to copy the weekly sync deck, update the information, format it against the agenda, draft a weekly update email, and so on.
If I know I'll need 4 to 6 slide decks and emails over the course of the sprints, I scaffold all of that material up front, minimizing the friction that could otherwise slow down a high-velocity dev sprint.
Be deliberate about what to share. Regular communication looks like slide decks, sync meetings, and update emails. I have to communicate progress, including highlights, lowlights, and new risks.
During development I'll have picked up plenty of things I want to talk about, but I have to be scrutinous about what I present to my audience at AnyCompany, since I need to keep them engaged while also respecting their time. I also have to consider that the VP of Video is probably reporting my work to other people at AnyCompany. The better I communicate the impact of my work on AnyProto, the more eyes are likely to turn toward it.
My general goal is to communicate the technical decisions being made during AnyProto's development and their business consequences, whether or not they relate directly to the previously agreed-upon success criteria. The hard work I'm doing to hit those success criteria should be clear.
Some examples of updates that, while good to communicate, might be better held back and offered depending on the conversation, or saved for handoff documentation instead:
- "We're going with HLS.js for video playback in the web experience, since its versatility makes it a reliable candidate for prototyping different playback features." (Frontend software often gets overhauled once a project moves into production.)
- "We're using separate S3 buckets for video and video metadata storage, so we can enforce different storage classes and security schemes on each." (More relevant for developers and architects later on.)
- "We fixed the ffmpeg bug in the Lambda runtime by pinning the ffmpeg version in the Lambda layer and upgrading the Python runtime." (Bug fixes and workarounds are sometimes too technical for a business-value conversation.)
Some examples of progress points that win trust with stakeholders, or give them good news to relay to their own internal teams:
- "By changing our indexing strategy, we improved the precision of search results for video clips from 70% last week to 90% this week. Here are some of the tradeoffs with this strategy..." (Hard numbers that tie directly to success criteria are easy wins, if you have them, and you really should have them.)
- "Storing video segments separately from full source videos would be too costly, so the web application will fetch the entire video and use metadata from search results to serve users the clips. Here's what that looks like..." (Well-architected UX, cost, and performance tradeoffs matter for stakeholders to know about. I don't want to make sacrifices without their awareness.)
- "We've prepared a connector to manually ingest preexisting metadata into our OpenSearch cluster. Here's what the assumed input looks like..." (Conversations about connecting AnyProto to existing production systems often get stakeholders thinking critically about their own role in pushing the prototype forward.)
I'll talk more about how I think about demos in the closeout section. Here I want to focus on the considerations happening behind the IDE.
Security can't wait for the last week. At AWS there's a saying that security is the first priority, or "job zero" (the legacy phrase). I believe security strengthening should happen throughout the prototyping process, not at the end of it.
The worst thing I can do for AnyProto and AnyCompany is save security for the last week. By then, vulnerabilities will have piled up, sometimes affecting entire architecture patterns and software modules.
When software fails to clear our security bar, we can't hand it to customers, so it's important that I regularly run static code analysis to find and correct potential security flaws.
Code quality is a close second. Part of my obligation to AnyCompany is as a technologist, not just a builder. Security is my biggest concern during development, but code readability and portability are a close second.
Generally, I write self-documenting code to reduce reliance on comments and READMEs, which can sometimes add friction when reading code. That said, I do need to make sure the reasoning behind engineering decisions gets recorded and doesn't get lost to time.
I structure AnyProto's codebase so that most of the architecture is clearly discernible from the code itself, with higher-level decisions and more opaque patterns explicitly called out in READMEs.
I also pay close attention to the software licenses of any third-party open source software I bring into AnyProto. Certain licenses, like GPL, can create logistical obstacles for businesses that want to keep their software private.
Collaboration changes the equation. This entire section has been written as though I've been working alone. In practice, during my time at AWS delivering prototypes, I very often worked alongside a partner, either as the lead or as a plus-one. My general collaboration guidance is to err on the side of over-communicating, both in specificity and in frequency.
That said, it depends on the personality and bandwidth of the engineers I'm working with. Sometimes we both have the time to pour into every aspect of the engagement, the presentations and the technical delivery alike. Other times, I'm only getting design guidance and have to own implementation, communication, and delivery myself.
Whatever the scenario, I need to communicate my own needs and bandwidth clearly to my plus-one or lead. The more clarity each of us has around how the other works, the more efficiently we can collaborate, and the less likely the engagement is to get slowed down by mismatches in design and development.
← Part 3: The Scoping | Series index | Part 5: The Closeout →