~/About.json

# A quick rundown of current information
{
  about: """
  I'm Brandon Martinez a Sr. software engineer who specializes in ETL pipelines, system tools, and highly availiblty services.  My favorite projects usually involve creating tools for other developers.  I have a passion for low level tech and efficiency.
  """,
  resume: "RESUME_LINK",
  contact: [
    "brandon@ibreak.systems"
  ],
  strong_skills: [
    "golang",
    "python",
    "linux",
    "bash",
    "offensive security"
  ],
  learning: [
    "rust",
  ],
  minor_skills: [
    "electronics engineering",
    "fusion 360",
    "3D Printing/CNC"
  ]
}

Battling Scope Creep Without A Fight

I have been working in web/software development for more than thirteen years and at least eleven of those years have been Agile based. In those eleven years I have never experienced anything other than perfect Agile team synergy. Agile is a perfect system and not easily abused and made overly complex, where ceremony becomes more important than coding. This is everyone’s experience, right?

Let’s be honest, I don’t know many software folks who ever felt like their Agile development was done correctly. Is this a flaw of Agile, the engineers, the managers, the business folks? Let’s figure it out.

What is Agile?

If you are an engineer you probably have the Agile buzzword somewhere on your resume, but what exactly is Agile? Some will be quick to respond with “Scrum!” or “Kanban!” which is technically correct, but Agile is a wider interface term that is implemented by these processes. At its core Agile holds three stages: preparation, sprint planning, and the sprint. These three phases are meant to be fast and iterative. The idea is that mistakes become less expensive, and minimum viable products(MVPs) more realistic and releasable. In your preparation you define your work, usually based on existing road maps. This includes your requirements for the current iteration and the intentions of the iteration. In the second phase, sprint planning, you lay out your tickets making sure that your engineers have enough work, while minimizing context switching and over saturation. Then finally you have the sprint! This is where you let your engineers do their thing and be the “rockstar engineer” you hired them to be. In parallel the managers leverage company resources to keep engineers unblocked while setting up the next sprint of work to be knocked down.

Agile Benefits

Seems like Agile is a lot of overhead just to assign work to engineers. Why can’t you just say “go make product X” and the code monkey walks away for three weeks, eventually coming back with a new service? Well, quite frankly, engineers are usually terrible product managers. Having scope and quick iterations is one of the best ways to make software. It lets the engineers do what they do best while giving the team room to make mistakes. Maybe that document database wasn’t the best way to go. Maybe REST over gRPC wasn’t the greatest call. Having a tighter feedback loop, like you should have in a sprint, prevents burning developer hours. If you send someone who problem solves into a brick wall, they might focus on the brickwall more than the implication of what it means to overcome that brick wall. When these brick walls are encountered it can be taken into account by product managers for the next iteration that is being planned, but the iteration should still have a conclusion. Is it worth the developer time, should we divert, etc. Agile makes your team move quickly by focusing on the small steps with knowledge of what the journey’s outcome should be.

Agile’s Reality

So given Agile’s strict workflow, quick iterations, and focus on momentum there is no way this slows development down right? It always goes smoothly… right? In my tenure, no. Normally the process goes more like this. During preparation tickets are usually left vague and given loose business requirements. This makes giving estimates very difficult and makes designing infrastructure even harder. In your sprint planning you will be asked to give a ticket story points, this is a rough estimate that has no concrete definition. The core unit changes between companies, teams, and individual engineers. So not only is the proposed work vague, but the estimate you give is also not based on anything real. I can’t say “this will take about 2 full days of focused work” you have to say “this is 5 story points” and then you gauge how your peers react only to then say “well maybe it’s 3”. Once your loosely cobbled together sprint is done you get to work.

You start off the sprint with a spike so you can research the API your service will source data from, it meets the product needs and you start the real development. Everything is going smoothly, maybe the frontend needs an API spec update here or there, it’s a bunch of 15 minute tasks who cares. Then it all goes down the drain when you get a new feature shoehorned into the middle of the sprint. It’s a 5 pointer(still don’t know what that means) and it is a P1, it’s always a P1. You start your work and then suddenly you find out that third party API no longer meets your product needs, you are now blocked and as a reward for your attention to detail you get to sit in meetings with vendors and your stakeholders for the rest of the week. In addition the database schema that just passed RFC for this product to be updated because the model is no longer sufficient to meet the product features. Don’t worry, the other 10 points of tickets you won't get to will just be moved to the next sprint and this will be brought up in your semi-annual review as a burndown chart with a bunch of plateaus.

This seems broken, clearly the managers are to blame with their vague tickets! Or maybe it’s the engineer for not making the sprint planning meeting longer by being pedantic about tickets. Or maybe it’s leadership! Why aren’t their goals more clear?! Do they just make things up on a whim, introducing all this scope creep on these poor innocent engineers. Who is really to blame for all these headaches?

Scope Creep vs Scope Discovery

When you have a new requirement in the middle of a sprint this is commonly referred to as scope creep. Scope creep isn’t always as obvious as the ceo learning over a mock up and saying “add this feature, I want to see a prototype by next week”. It’s usually more innocuous, remember those vaguely worded tickets? Well suddenly ticket that says “add a language translation layer” turned into “add a translation layer that supports right to left languages” all based on information fed to the product team and the product team having to decide to once again pivot. This small detail now changes all the UI, the character support, and sometimes even the transport layer of the services that are being leveraged. Is it really scope creep if you have to stop doing work that will be 100% fruitless or is it scope discovery? Let’s look back at the previous example where the schema RFC has to be updated due to a feature change. Maybe this feature was on the roadmap, but it wasn’t considered part of the MVP. Maybe this feature was mentioned, but the product manager wasn’t psychic and didn’t know to grill everyone on details about it. What if there was some casual watercooler talk and a manager found out that the stakeholder expectations for the iteration are out of sync with the teams? Reality is very messy and seldom is an all or nothing approach the wise thing to do, it usually lies somewhere in best effort. This is why I have started adopting scope discovery, which looks a lot like scope creep, but it is different in intent and process.

Scope discovery is applied when an iteration will be useless or hurt momentum without this scope change. Scope creep is brought out when leadership doesn’t have a solid direction, when engineers don’t ask enough questions, and when product managers do not use explicit language when describing their tickets. Scope discovery happens when the realities of a product design create scenarios where the logical conclusion is to pivot. Scope creep and scope discovery are inevitable, however they can be mitigated.

Scope Creepscovery Mitigation

In order to figure out how to mitigate scope creep we must first understand its causes while recognizing that scope creep is a symptom and not the disease.

Preparation

The first layer of scope creep protection happens in preparation. Leadership should do their best to understand their quarterly goals. If a quarter is too long of a time period then a minimum monthly iteration should be understood and set in stone. This does not mean that the implementation needs to be set in stone, that’s the engineer's job, just figure out the product roadmap and expectations. With this product managers can break up this time period into concise pieces of work. If the ticket is too big and too complex that ticket needs to be broken down into smaller tickets. If there is too much work for the team then this feedback needs to immediately be made known to the stakeholders. Communicating early and often will be a theme here. This is not so they can change the iteration requirements, but so they can manage the time expectations and not over promise. This is also a good signal that maybe additional teams need to be onboarded. Now you are ready to start involving engineers.

Sprint Planning

The sprint planning meeting is the meeting most engineers dread, it’s very slow and very tedious. The way to make this less painful is having engineers the business day or two before a sprint planning actually review their own tickets and make comments. It’s important that the product manager knows when requirements are not sufficient, this is your time to make sure you aren’t feeling like the bottle neck keeping everyone from lunch by making the meeting go long. If these meetings are running too long, maybe the team is too big. During these conversations of reasonable length engineers, their managers, and product managers need to be comfortable with the phrase “there is not enough information to start this ticket”. If your sprint doesn’t start for a day or two this is a perfect time for your product managers to update the tickets and tighten the requirements to make them best represent what is needed for this iteration. Communicate with your managers, have a tight feedback loop and over time you and your management team will communicate smoother with less out of sync time.

Sprint Proper

Now it’s time for the sprint, go forth rockstar code monkey and implement that service! You have your well defined tickets with details and intentions all understood. You know your expectations and your product team’s expectations are all in line. Your team has perfected Agile… You get a Slack Jira bot notification, you have been assigned a new ticket in the sprint. Oh no it’s the dreaded scope creep, we did everything perfectly. It must be those pesky stakeholders making stuff up! Fear not, we have a process. Start communicating with your engineering manager and your product manager immediately. You want to include your engineering manager because they need to know why your work isn’t going to get done like the other engineers and they usually control your raises. Let both managers know this ticket was not part of the current sprint. Follow up by asking them why this ticket can't be pushed to the next work cycle. You will be surprised how often that is enough, people are human and get requests and they want the request filled, sometimes they forget protocol. If they explain it’s high priority, ask if the product will not work this iteration if we don’t have it immediately, also ask yourself does this affect the way you are doing your work. Maybe it is super high priority, there is no point in the sprint without it, or maybe it isn’t super important but the inclusion of it heavily affects your schema or your infrastructure plan. Or maybe it's just a bug in production and you're the person with the domain knowledge to fix it. Either way we are now dealing with scope discovery and have left scope creep behind.

Accepting Scope Discovery

Scope creep does not need to be done in the sprint, it’s usually just people being impatient or disorganized. If that’s the case, work with your managers and get organized, however if you are organized and you get scope discovery the only real answer is does it make sense to pivot. Is it worth it to drop your current work and context switch to this new work? Ask your manager, ask your product managers, let them know what work will be lost. Maybe in the scope discovery only 15% of your work is wasted and it makes sense to keep going, but maybe the whole sprint is trashed. But in either case you need to follow up with your product managers and your engineer manager, have a retro with them. Look at your processes and treat this how you would treat an outage. There is a gap in the system that let this happen and how can we prevent this specific outage from happening again. This clearly lays it out to management and leadership that scope creep and even scope discovery are bugs from a system misbehaving and are abnormal. Overtime if these things don’t improve you can always leave, you are not beholden to an employer that doesn’t respect the structure they set up, if they can’t manage a product how will they manage a company with a consistent vision.

If after all of this hullabaloo you still have to do the new ticket, make sure your other tickets are removed from the current sprint. This explicitly communicates you are no longer responsible for that working being created. Now you can finally work in peace.

After all that drama and ceremony your work is completed and it’s time to get all your tickets reviewed, tested, and merged. You have a consistent and quick code review process, right? It’s not going to be a blocker for a whole other sprint… right?