On-boarding. The process can be summed up as throw-you-into-the-deep-end-sink-or-swim. The code base I worked in wasn't documented (more on that later) so all of the learning I did had to be done in the code itself. I wasn't expecting thorough documentation, but an outline of the application's architecture/design would have been helpful in getting started.
Point quota. Developers are expected to meet a minimum number of points completed per sprint (6-8). Keep in mind 1 point was considered 1 day's worth of work. A sprint is 2 (work) weeks long so developers have 10 days to meet this quota. This may seem like an adequate amount of time to get the work done but keep reading and you'll see why it isn't. The quota was the reason I left the company because it had the following problems:
- Massive Bug Backlog - Code was written quickly to earn as many points as possible in the shortest period of time. This caused developers to make mistakes and not test thoroughly so when the testers actually evaluated the quality of the product, a bunch of bugs get logged. Those bugs, however, don't get fixed immediately because unless management pulls those bugs into the current sprint and assigns point values to them, no one will work on them (nor are the developers allowed to pull the bugs in themselves, it must go through the pointing process).
- Code Duplication/Quality - It's faster to copy/paste code than it is to refactor it so there was a lot of copy/pasted code in the code base. I often noticed other developers (myself included) doing the bare minimum to pass code review (and earn points). Refactoring didn't earn developers "extra points" so without the incentive, why spend the extra time to clean up the code? Management only seemed to be concerned with the number of points earned vs the quality of the code written so why spend the extra time to make the code better when "functioning" is good enough?
- "Extra" Points Don't Rollover - Each developer is expected to earn 6-8 points per sprint. If a developer earns more points than that, they do not rollover into the next sprint. There is no incentive to do any more work beyond the bare minimum. I once had a sprint where I earned 16 points then took my time in the next sprint to carefully refactor a portion of code. When my refactor didn't produce any completed points at the end of the 1st week of the sprint I was messaged by management asking why I didn't have any points done.
- Lacking Documentation - None of the developers bothered write documentation on the code base because writing documentation wasn't worth any points, so why do it? This was the reason why my on-boarding process was more difficult than it should have been. In general, the quota prevents developers from doing additional work that could benefit the team in the long-term.
- Work/Life Balance - Developers who don't meet their point quota get messages from management asking why and if additional (over 40 per week) hours were put in to attempt to meet that quota. This happened to me a few times which is disappointing because it shows that management prefers quantity over quality. Likely because it's an easy metric to sell to stakeholders. Honestly, I don't even know how the quota applies when people take time off. Evidently it seems that senior developers were still active on Slack and doing code reviews despite taking time off for vacation which I find alarming.
- Discourages Discussion - Often times when there are questions around requirements it's normal for developers and product reps to have a discussion making the requirements more clear or even changing them to better suit the user experience or the technical limitations. Since developers are always expected to be churning out points, we're less incentivized to carefully discuss the requirements when we had questions and often the went with our "best guess." This often led to re-work when either the product rep noticed the requirements weren't met or a developer would notice that the feature as written didn't make sense from a user/technical perspective.
- Doesn't Account for Blockers - A perfect example of this was our pull request (PR) builder. A PR cannot be merged until the builder has been run and passes (code compiles, tests pass, etc...). Our Jenkins jobs were setup in such a way that there could only be one active build job running at a given time including the build for the master branch as well as the builds for all PRs. This means that if multiple PRs were made at the same time (like say towards the end of a sprint) then each PR would get queued until the previous PR finished building. The same would occur when a PR was merged into master and the master build would kick off. As you can imagine, it could take a long time to get through all of the pending PRs slowing down the entire development process. It was even worse when Jenkins would go down. The quota doesn't account for issues like these which causes developers to work more hours (see Work/Life Balance above) or possibly get a "nasty gram" from management. When I brought this up to management during sprint retrospectives it wasn't clear to me if they followed up on it or what the outcomes of that were as they never mentioned it again (but the problems continued).
- Estimates - Developers use pointing poker to determine how many points a given card is worth (usually based on how much work the card required). One would think that since developers control the points this system would work right? Wrong. The stages for a card go like this: coding -> UX review -> testing -> done. The only part of this process that we as developers can accurately estimate is the "coding" stage. We cannot possibly be expected to estimate how long a designer will take to review the UI and how long a tester will take to test the feature. When I brought up my concern to management they simply replied that developers should account for those steps in their estimates. I don't think that's fair. Not to mention, if a story card fails any of the intermediate steps it goes back to the "coding" stage where the process starts over. Which means developers need to juggle multiple cards at the same time and monitor the processes of each in case follow ups are needed or someone in the process is dragging their feet. The quota unfairly judges developers on their productivity when they may not even be the reason why a story card isn't "done."
- Personal Development - Since developers are always busy trying to earn points and juggling story cards, there isn't much room for your own personal development unless you do it on your own time. This can be difficult if you're working over 40+ hours a week. It seems to me that the way a developer grows here is through trial by fire through an assignment that you may not necessarily know how to do. This is unfortunate because with the quota in place developers are not incentivized to grow their skillsets, but rather stick with what they already know and understand for the sake of earning points consistently.
- Turn Over - I worked at SemanticBits for 5 months. In that time, one other developer from my project left the company, shortly followed by me. I witnessed a conversation occur on Slack between the developer and management which discussed an issue management had with the developer's inability to join impromptu meetings in a "timely" manner (it took the developer a couple extra minutes to log into meetings due to the internet setup they had a home). I personally had two issues with the entire conversation: 1) it should not have been done in a public channel where everyone could see it, and 2) I suspect that no one other than management had an issue with the developer's delay in joining unplanned meetings which seems unfair to reprimand someone (albeit a minor reprimand) when so few people had an issue.
- Developer Evaluations - I didn't work at SemanticBits long enough to actually receive a proper evaluation, but I suspect the overall points earned for the year (or average per sprint) are a major factor in the evaluation. I don't feel those metrics accurately measure the level of contribution any one developer has made to the project or team as it ignores other useful measures like:
- Helping other team members
- Mentoring
- Code quality
- Code performance/run-time
- Staying up-to-date on current technology
- Learning the product
I also noticed that one-on-ones did not occur between developers and management at all (they did occur between HR and team members though) which further supports my theory that performance is based on points. I find that concerning because it indicates that management is not aware of the activities any individual developer is doing besides the story cards they are actively working on and/or completed. I also felt I was micromanaged quite a bit. In my 3rd week on the project, I received a message from management inquiring as to why I hadn't earned any story points yet. It's a little unsettling to be watched like that especially when I was still new to the project.
Advice to anyone looking to work here. You should ask about this stuff during the interview process. It's been over a year since I've worked there so any number of these things may have changed.
