Yeah; working tickets in a small company without seventeen layers of corporate bullshit feels so good.

You take a ticket. It contains information about the expected state of the product and how reality differs from that, relevant additional information, as well as information on who reported the bug/requested the feature. You start work on your task immediately because everything you need is right there. If you have questions you know exactly who to ask and how to reach them. Your bureaucratic overhead consists of a daily 15 minute standup with the other devs. The codebase may be a bit old-fashioned but is sensibly organized and reasonably easy to understand. Two days later you submit a merge request; the code review is done in another day and you set the task to done.

Now let’s see how it goes in a corporation:

You join the one hour pre-refinement meeting and see a new PBI. The PBI contains a vague description of something that may or may not be your team’s responsibility. While trying to turn the description into ACs you realize that it references an old version of the DOM so your architect has to talk to the operating department for clarification. Regardless, the PO points out that the issue is on a hard timer so the PBI passes through pre-refinement half-finished.

During the two hour refinement meeting the PBI has to be estimated based on the architect’s best guess on what to do. You plasyx planning poker because you have to despite having no idea about how complex the task actually is. This is still very important for planning so you guess it’s an 8. After this the team adds tasks to the PBI based on what you think needs to be done. These tasks contain no information beyond their titles.

Unfortunately, the PBI lands in your lap. While trying to make sense of the description and ACs you realize that it’s impossible to understand without looking at the DOM, which requires you to launch Enterprise Architect and hope that you currently have access rights. After parsing a 125-element UML chart you ask your lead dev for help. He refers you to someone on another team but can’t remember their name. You track them down and message them on Teams. A day later they actually respond and you can start working.

The codebase uses a hexagonal event-driven CQRS architecture with eventual consistency and ROP everywhere, which means that it’s virtually impossible to step through the code and see where values actually come from. After wading through application-internal events that generate other application-internal events you finally realize that you made the mistake of relying on your IDE’s “Find all references” functionality, which isn’t reliable in a codebase as enterprisey meticulously engineered as yours. A repository-wide regex search finally leads you to the place where you need to make your change. One of them, that is; you also need to update three domain event handlers, two feed workers, twenty test classes, and a stored procedure in the database. This takes over a week, especially since in the meantime you also had your half-hour dailies, a 90 minute retrospective, a two-hour sprint planning session, a CAB advisory, weeklies for three workgroups you’re in, and a joint review session.

Finally you submit your code and open a pull request. Azure DevOps fails to build your application because SonarQube complains that one method contains more then thirty statements. That method initializes a domain object with sixty-eight properties so it’s probably okay. You log into SonarQube, which fails because SQ’s Entra ID integration is flaky. After five attempts you finally get in and mark the method as “won’t fix”, which has been done twenty times already for this method. ADO still can’t build your application because in the meantime the security team have made a small adjustment to the firewall which means that ADO can’t talk to its build runners anymore. They promise a swift resolution.

As you log in the next day the runners still don’t work but that’s okay because neither does your dev VM. Or maybe it’s the AVD session you have to dial into to connect to the dev VM. Either way, fifty other devs are also affected. The platform team promises a swift resolution. At 4 PM you can actually log into your VM again. The runners now work but the build’s test cases fail because you forgot to tell the DBAs to deploy your stored procedure to the PROD and STAGE databases. You do so and the ticket gets a 48 hour SLA.

Five hours after the SLA has expired you ask the DBAs when they’ll do your changes. They realize the changes are trivial and do it in five seconds. You restart the expired build pipeline and finally take your PR out of draft stage so your team can review it.

One reviewer notices that one of the integration tests is no longer as precise as desired after your changes and asks you to sit down with the team’s QA engineer to completely refactor it. Simultaneously the PO asks you if the PBI needs to be moved to the next sprint; the pre-refinement meeting starts in five.

That is a great point. And the fact that you enjoy the work you do also suggests you’re good at it and that you therefore bring meaningful value to your colleagues and firm.

Keep being you.