How to identify individual accomplishments / successes for a resume, when I'm working in a Scrum team that is overall frequently failing to deliver?

Question

I am a developer on a Scrum team which I joined in September and for reasons which will be evident, I want to leave and am trying to figure out resume lines.

The Scrum team I'm working in is problematic in ways like:

• The other devs don't finish their stories or the specs are absurdly wrong and it is a "team failure."
• We are 6 sprints in and it seems that there is no meaningful difference between finishing one's work and just not finishing.

I hate this kind of environment as I have always been an individual technical performer and am not willing to drag others along. Teamwork is great, but only if others pull their own weight.

My current situation:

At this point I am just overestimating how long work will take, coding to the spec (no matter how absurd) and funneling the rest of the sprint time into Udemy courses, but I can only do that so much to add technologies to my resume after weeks. I maybe need 15 hours to complete all my work and am doing the same number of points as the other developers.

As it stands, I seem to have no oversight (I speak to my manager maybe once a week and he doesn't work on the same projects I do). Heck, I am openly working on Udemy courses and nobody has said anything. We don't seem to have individualized evaluations of any sort.

I am looking to move on...

I am certainly not staying the length of the project, so I can't put that on a resume.

What is the best way to extract an individualized benefit out of a Scrum environment? I don't get a defined project area. I am not responsible for any given components outside the two weeks of the Sprint. I am basically a generic factory worker. Factory workers might at least be ranked by widgets (points in scrum) relative to peers, but we don't keep track of that either.

In terms of "achievement" what should I be putting on my resume when I try to exit at 6 months?

I suppose this question is a bit off topic, but how is the "succeed or fail as a team" in Scrum supposed to work? Whether the team succeeds or fails seems immaterial to my interests, so a Scrum worker wouldn't do anything special to make it succeed unless they are a company lifer. Same with the "eliminate waste and increase velocity" thing.

Answer 1

The point of software development is to develop working software that has value.

"Coding to the spec" and "not willing to drag others along" are not valued attributes. Half-finished features have no value. Features blindly coded to a bad spec have no value.

If you're given a spec that has problems and you're the only one who realizes that, your responsibility is to speak up. Ask questions, clarify ambiguities, tell someone when a requirement is nonsensical.

If you've finished your sprint tasks, but the rest of the team hasn't, then your job as a team member is to step up and ask how you can help, either by taking on additional work or by unblocking a teammate.

Software development is not order-fulfillment. It's knowledge work.

---

The above addresses the side question of how the "succeed or fail as a team" aspect is supposed to work.

For the main question of what to put on your resume:

Since you seem to want to consider only individual accomplishments, talk about the quality and/or quantity of your individual work. Also talk about what you've been working on, both the type of project and the technologies you used.

• Is your work of the highest quality, up to standards, with excellent test coverage and free of security vulnerabilities?
• Did you complete most of your features on time and under budget?
• Don't forget to include the relevant buzzwords in order to make it past the recruiter's buzzword-filtering software. As someone who occasionally reads candidates' resumes, I suggest putting these in prose rather than in a bulleted list. Example: "Built a Froznot Zyvhar using React on the front end, with a Node.js Express server on the back end. Wrote unit tests using Jweivwh. Created performance tests with Taysdjhv. Automated the build, test, and deployment process using Jenkins. All source, tests, and deployment scripts were committed to GitHub using the Git Flow development process."

Answer 2

The usual method is that the team assigns points to tasks, and then team members pick up whatever tasks they like. If you somehow manage to get too many points assigned to your task, I'll pick it up and look good :-) But really that's not going to happen with scrum done properly, because all the other members figure out that the points are inflated.

If you have an ineffective manager, that manager will count task points and that's it. An effective manager will notice that you deliberately coded tasks according to the specs and nothing else, leading to wasted work. It won't go unnoticed. An effective manager will also notice when someone picks up difficult tasks, or avoids difficult tasks. And a good manager will notice that some people will ask some other people for advice, and receive advice (and asking for advice is good if it saves time and bad if it wastes time, while giving advice is seen to help the team). So being selfish and only looking after your own points will get noticed.

It's interesting that you think a person wouldn't try to make the company succeed unless they are "a company lifer". I started at my current job with the intent of making the company succeed, and my goal is to get to a point where I can honestly say I've done a good job and I'm not needed anymore, and then start somewhere else and do the same thing again. For a better salary obviously.

Answer 3

It is probably just a bad fit for you

Some people are very focused on feedback and feel lost without it. Others prefer to be in a company where they can just do their own thing. I don't think those personalities can work together for long. There are also those who closely follow incentives and those who don't and again, they can't work well together. Scrum seems to exacerbate differences because everyone is just kind of thrown in the same pot and stirred.

Your team doesn't seem to offer opportunities for direct achievement and almost seems like an orphan project. Consider what I did for an internship a few years back (for different motivations). I was on the innovation team and I were sent out to one of our offices to shadow a group of team members for a day to see what could be done better.

I found a bunch of things and reported them back to my team. No action was officially taken (understandably, as every team member did an expedition and found many potential improvements), but our culture and my boss were fine with me pressing ahead independently.

I chose to replace a piece of software that cost many thousands of dollars annually and wasn't even performing its function accurately anymore (it was a 20-year-old legacy leftover). I spent a week, coded it up, send it off to the team that used it for test case verification, and then handed it off just as I left for school again. It was a couple of jobs ago, but still makes a great interview story.

You have a ton of time available, so go find some group far from technology (finance, human resources, or operations) and automate something for them. Translate the labour savings into man-hours per year, multiply by the estimated salary paid and you have your accomplishment. SQL/Python can be enormously useful here.

There are plenty of repetitive tasks which could be made more efficient by software. Find one, automate, claim the savings, and ask the manager of that group to write you a reference for LinkedIn. Then you can move on.