I recently took over a development team where the only ones left are two fairly junior people.

Both are quite good for their age and I thought one was a senior as he knows his architecture but they are both assigned to use frameworks they have never worked with before and their inexperience shows there as the code quality for many of the PRs is awful. They are the only two people writing an Angular app and neither of them has used it for more than three weeks.

They actually do know many of their mistakes but because the company is a "Scrum" company and this company tracks velocity twice daily (morning and afternoon standup reporting) they don't have time to check things and are just scrambling to get something done for the next reporting period.

It seems to be a stretch to think that I can get them to dump Scrum for another project management tool but this is my first Scrum company so I am not really sure what I can do within Scrum to get the developers more flexibility within the two week "sprint" period rather than the daily velocity tracking.

Any ideas?

  • 332
    What you are describing isn't Scrum. For Scrum to work properly, there needs to be slack in the system so people can inspect, adapt, learn, plan and pivot when needed. Tracking velocity twice a day is micromanagement and a form of pressure and control that goes against Agile values and principles. And velocity is a measurement not an objective. Measuring it twice a day turned it into an objective that your new team mates are trying to pursue at the detriment of everything else. Look beyond your team and beyond Scrum. The problem is the way the company works, irrelevant of Scrum.
    – Bogdan
    Commented Jun 9, 2021 at 7:00
  • 14
    You say you "took over", what is your role? Who is the team reporting their velocity to? Can you just tell your devs to stop doing it? Or the higher ups to stop asking?
    – Erik
    Commented Jun 9, 2021 at 7:08
  • 17
    To follow up from Bogdan's comment: do you want answers which would apply if you were actually following the Scrum guidelines? We can write those, but I suspect they won't be very useful to you. I could also write an answer as to what I'd do in your situation, which would be "find another job ASAP and help those junior devs get out as well". Commented Jun 9, 2021 at 7:08
  • 13
    Manager left, all but the most junior devs left. Totally consistent with the rest of the description as to how things work there. Commented Jun 9, 2021 at 16:25
  • 101
    Hey boss, I've been leading the team for a few weeks now, and I think I found out why our entire department walked out last month.
    – corsiKa
    Commented Jun 10, 2021 at 3:16

11 Answers 11


Well, you did right using quotes around the word "Scrum". What you describe is not Scrum.

I cannot stop companies calling their failed project management method "Scrum" as much or as little as I cannot stop North Korea calling themselves the "Democratic People's Republic". That doesn't make it true though. What you describe is not Scrum.

Let's start with the most obviously stupid thing: having a meeting that is officially called the "Daily Scrum", twice a day. That's not a failure on the complex project management level, that is a failure of first grade reading comprehension.

Apart from that, the meeting seems to be completely misunderstood. It is explicitly not for reporting project status or progress. It is for planning collaboration for the next working day. Saying it is a deadline is completely misunderstanding the Scrum philosophy.

You make no mention of a Product Owner. Or in fact of a Scrum Master, whose job it would be to control this mess and suggest how to get back on track.

If you want to use Scrum (whether you think it's good or the company guideline says so) you need the following: one Product Owner, one Scrum Master, and one senior software developer in addition to your two juniors. I'm not sure what your role is there - maybe it's one of those? I don't know; you didn't say. But three people, two juniors and one supposedly managing, is not a Scrum team, no matter what you do.

I suggest you read a Scrum guide. It's not a complex piece of art; it's very understandable.

Then decide how far away from Scrum your company actually is and whether it's salvageable or not.

Scrum is not a silver bullet and does not claim to be. Maybe, for your company and your situation, it's better not to do Scrum. Maybe you need something else. However, the worst possible option is doing Scrum wrong.

As far as your developer problem goes: hire people that know what they are doing and educate the people you have that don't know yet. You have two developers and no Angular knowledge? I'm sure there are course providers out there who can help you. And I'm not talking about having your two juniors watch free courses in their spare time. I'm talking about paying for professional training, paid by the company, on company time. That is how to manage this professionally.

  • 54
    "I cannot stop companies calling their failed project management method "Scrum" as much or as little as I cannot stop North Korea calling themselves the "Democratic People's Republic". That doesn't make it true though. What you describe is not Scrum." Oh, yes. "Everything is agile"
    – Sascha
    Commented Jun 9, 2021 at 7:14
  • 11
    "...and no Angular knowledge.. a professional training, paid by the company".. Holy smokes! You'd be surprised how many companies have crew managers who don't even realize what their workers do and pay nonsense because of their lack of knowledge including the work's actual value! I'm pretty sure you're working in a normal company, got a laptop and phone provided by the company alongside with a normal salary, but there are so freaking many developers out there who get nearly nothing for their knowledge and endeavors... Please, listen to this man, companies! I'd adore to work in normal company..
    – Artfaith
    Commented Jun 9, 2021 at 16:32
  • 6
    @Sascha Even if you go with a loose interpretation of Scrum and just want it to be "agile" with a Scrum smell, what OP describes is also totally anti-agile. While I think just blindly following the Scrum book is toxic in many contexts (i.e. cargo cult), when you deviate and aren't even agile that is typically worse... twisting something that was made to enable teams into disabling them. Commented Jun 9, 2021 at 20:04
  • 4
    I appreciate that the OP question provokes a defensive response from Scrum advocates, but still I find that the OP does not actually state what his issue is, and therefore answers like this don't really address the problem. Who cares if he calls his methodology Scrum or not? Why can't he introduce pragmatic change, and what pragmatic change does he want to achieve?
    – Frank
    Commented Jun 10, 2021 at 9:19
  • 1
    @Sascha "no organization of work and standards = A G I L E!"
    – user11153
    Commented Jun 10, 2021 at 12:45

nvoigt's and gnasher729's answers are both excellent at addressing why this is not Scrum. I want to zoom in on one point that is independent of Scrum that I think is very important.

they don't have time to check things and are just scrambling to get something done

But checking things is getting something done. Learning to use a new architecture properly is getting something done, too.

When these things are required, you estimate how long these things will take, and you add it to the total estimate for how long the work will take.

If a team can't get past this conceptual hurdle they'll always be missing deadlines.


A lot of comments on this answer mention the importance of having a "definition of done", and while that is important (and stressed by Scrum), I was aiming at something rather more basic: that "invisible" tasks like testing, learning, and planning, have to be acknowledged as being work. The phenomenon of them being ignored is sometimes referred to as "Why Isn't Mary Programming" or "Why Isn't Sam Coding Anything".

  • 7
    Every team needs to agree on a definition of “done” which should include unit tests and QA IMO.
    – ColleenV
    Commented Jun 9, 2021 at 10:29
  • 4
    @ColleenV I had one project where I moved an awful lot of code to a new operating system. The first version was done after three months. Definition of "done": It compiles and launches. It crashed within five milliseconds :-)
    – gnasher729
    Commented Jun 9, 2021 at 13:08
  • 8
    @gnasher729 As someone whose god-given talent is crashing software in ways no-one has ever seen before, trying to get me to accept a definition of done that doesn’t include automated unit tests involves a lot of metaphorical kicking and screaming ;)
    – ColleenV
    Commented Jun 9, 2021 at 13:16
  • 5
    @ColleenV My thought exactly. In my opinion, if something isn't tested, it's not done. Commented Jun 9, 2021 at 15:29
  • 4
    "But checking things is getting something done." YES, this cannot be overstated enough! Commented Jun 9, 2021 at 16:19

On a daily standup (daily, not twice daily) you report what you have achieved. If you haven't achieved what some dubious individual with no clue has decided you should achieve, then you report that this task is not finished. And your task for the next day will be to finish it. Which you may or may not achieve.

If the company wants more speed, then they need to hire more developers, or senior developers at higher salaries, or wait until your junior developers have learned the frameworks that they are using. What the company forces them to do right now is counter productive and will result in a much delayed shippable product.

An iron rule in development: The more you rush, the longer it takes. And they are just starting. The next iron rule: The longer you rush, the worse it gets. With your current method, expect an unmaintainable mess with absolute standstill in development about 3 months from now.

  • 9
    Adding more people won't necessarily help. Commented Jun 9, 2021 at 13:58
  • 4
    Senior developers at higher salaries might not help much, unless they can find senior developers familiar with the particular framework the company wants to use. Seems like management isn't familar with the concept of learning curve.
    – jamesqf
    Commented Jun 9, 2021 at 15:32
  • 8
    It might be worth clarifying that the purpose of the daily scrum is a team coordination meeting. The team to meant to inspect progress toward the Sprint Goal and adjust their plan accordingly. This might involve reporting what has been achieved, but that isn't expressly its purpose.
    – Stephan B
    Commented Jun 9, 2021 at 17:21
  • 4
    @jamesqf most seniors worth the name will either call out the mess of a process they seem to follow like a cult or be gone in a bit. ;) Commented Jun 9, 2021 at 20:07
  • 11
    "I'm sorry I wrote you such a long letter, but I didn't have time to write you a short one." the principle applies in so, so many ways to software development. "Sorry I spent so much time fixing bugs, but I didn't have time to fix them when they were still easy to fix."
    – corsiKa
    Commented Jun 10, 2021 at 3:19

I can see the root of your problem in this one sentence:

It seems to be a stretch to think that I can get them to dump Scrum for another project management tool

This is the root of your problem. You have no idea what Scrum is. It's not a "tool", and it's not "project management". It's a workflow concept. There is no application called "Scrum" which your project managers use to schedule features, it doesn't exist (or if it does exist, it ought not to exist because such a thing is stupid).

OK, so based on that, here's some other things you don't understand about Scrum, although I prefer to use the term "Agile" ("Scrum" is one small part of "Agile", and if you're doing Scrum but not Agile, you're probably going to have a bad time, which it seems you are):

Reduce meetings. Check-ins should happen once per day, if that. As an example of what happens (and probably is happening at your company): Let's say your developers work 8 hour days, 9am-5pm. Take out an hour for lunch, so 7 hours. Take out 30 mins twice a day for 2 daily check-ins, that's 6 hours. Take out about an additional 30 mins per day for walking to and from the meeting room, and context switching back and forth from "work-mode" to "meeting-mode, plus time waiting for everyone to sit and be ready for the meeting, and all the other nonsense that goes along, that's 5.5 hours. Take out an additional 15 mins per day, because nobody wants to be in the middle of a line of code when a meeting is called, so probably your developers are checkpointing their work and then sitting at their desk doing nothing for around 5 minutes while they wait for the meeting, that's 5.25 hours. You've cut off 3/8ths of your developers' 8 hour day, just like that.

Now, here's the alternative plan: Let's say you do a daily check-in ("standup") once per day, and let's say you do it at the very beginning or very end of the day (beginning is more useful, for a reason I'll get to in a moment). Now, you've saved 30 mins of meeting time, plus 15 associated minutes of context switching time, plus 7 mins of waiting time, that's almost an hour. That's almost an additional hour per day that your people can be doing things. It's about an extra day per pay period (assuming your company has biweekly pay periods). Would you rather them be using that extra day per pay period to do work, or to sit in meetings? It's up to you.

As for why you should do standup in the mornings: Standup is primarily for planning the day's work ahead. The previous day's work should be briefly mentioned, because you want to know what people have gotten done, but if you have a functional Kanban Board you shouldn't need too much detail on that, it should be evident from the board status. So the main point of standup is to plan today's work, and to share any issues that people are having from completing the previous day's work ("I planned to do X yesterday, but I wasn't able to because of Y"). Then you can spend the first part of the day with people giving help to those who have problems to help them resolve their problems. That's called being "Agile": You don't just focus on your work alone, instead you help everyone to get everyone's work done as efficiently as possible, moving from place to place, task to task, sometimes helping others with their tasks instead of just your own, and responding in an agile way; that's specifically why it's called "Agile" and not "Scrum", as mentioned above.

As for velocity: It sounds like your developers are being overloaded and they don't have time to complete the features they are assigned. There is an old saying: "Do it right, or do it twice". Sure, your developers can pound out code and get something delivered, but if they're just pounding out code to meet some deadline, the code they pound out is not going to be high quality, and you're going to have big problems (I was laid off from a company that did this, where the company had this sort of philosophy, and because of it they hemmhorraged money and laid off over 50% of their dev team, myself included). In the end, they didn't do it right, so they literally had to do it twice (actually I think they did it 3 or 4 times). This is why project deadlines should never be decided by project management or sales teams alone: They are not technical people and they have no idea how long it takes to get things done. They can say to a client "We'll build Google for you tomorrow, complete with GMail and Google Photos and Google Hangouts, and the best search engine on the planet, we'll build it for you and it will be done tomorrow". But when you actually try to do it, it turns out you can't build Google overnight, and even Google did not build Google overnight. This is why most functional companies have some input from development teams when it comes to getting things done, either during negotiation with clients, or they get some go-ahead from the client to reduce feature requests pending developer availability. Without either of those things, everyone in the work pipeline is blind: The developers are being told to do something way above capacity and they can't talk back, so they just do it and it turns out to be crappy. Project management has no idea that the work is crappy, they just take what the devs provide, and they won't know how bad it is until it's done. Sales has no idea what it takes to get the job done right, so they overpromise and underdeliver in order to get contracts, and the end-client thinks they're getting the world but actually they're going to end up with unusable garbage and they're going to badmouth your company. Nobody wins.

As for how to solve this: Your developers need to have input into how big the feature requests are. They need to have the ability to go to project management and say "You are asking for a week's work to be done in a day, we can't do that, you need to reduce your ask so that we can do it properly", and project management listens to them and helps them, rather than pushing a timeline from Sales. It's on you as the team lead to be the one to have that conversation with project management on your team's behalf: You are their shield to protect them from unreasonable requests that can't be completed, and to manage expectations for what's coming out of your team in terms of features. Additionally, you should have sprint planning meetings to prioritize and allocate tasks, and make sure your developers aren't being overloaded by being assigned too much work for too short a time (this is part of Agile, which is not part of Scrum, which is why it's important to do Agile and not just Scrum, and why Scrum doesn't work without Agile)

In summary, here's what you can do to help your team:

  1. Reduce meetings and cut down daily check-in to once per day, in the morning. It doesn't matter that this is "company culture" or whatever. You lead your team; if you can't even do something as small as determine how many meetings your team has scheduled and when, you're not a leader except in title.

  2. Push back against unreasonable requests from Project Management to ensure your team has the time allocated to complete their tasks. Shield your team from things that you know would be unreasonable to ask of them, and make sure that the work your team does do comes out right.

  3. Do sprint planning to make sure that you are allocating your resources effectively. Do not plan for 100% capacity of work for each developer, you're not going to get 100% capacity; you may get 80% capacity if you're lucky, you're more likely to get 70-75% capacity, especially from a team of junior developers. It sounds like right now you're asking for 120% capacity, and that's why your work is coming out like garbage.

Remember: Do it right, or do it twice.

  • 6
    "Take out 30 mins twice a day for 2 daily check-ins, that's 6 hours. Take out about an additional 30 mins per day for walking to and from the meeting room," What sort of Scrum have you been doing where standups are held in meeting rooms and take half an hour? You stand up in the area around your desks (hence the name), and spend maybe 1-2 minutes each describing what you got done and any blockers you might have encountered, so that with a team of about 5 people, it takes 5-10 minutes.
    – nick012000
    Commented Jun 9, 2021 at 16:12
  • 4
    You made one mistake there. You said "nobody wins".... but the salesman does win. His commission has been paid out long before any of the trouble you mentioned. Even if he indirectly causes the company to fail, as a high-performing salesman, he can easily get hired elsewhere. Rinse and repeat.
    – JoelFan
    Commented Jun 10, 2021 at 1:13
  • 3
    "Reduce meetings and cut down daily check-in to once per day, in the morning." The obvious problem here is that it's assuming all your developers are morning people, and could give coherent accounts of status in the morning. Also the perhaps obvious: reducing meetings to once a week allows even more time to be spent productively :-)
    – jamesqf
    Commented Jun 10, 2021 at 16:55
  • 1
    @jamesqf I feel like if your people come into work in the morning and are not even mentally equipped to talk about their work, nevermind do their work, then there's probably something wrong that's outside the scope of this question. I don't think it's a big ask to have your people be coherent during the work day.
    – Ertai87
    Commented Jun 10, 2021 at 17:53
  • 1
    @jamesqf I feel like you were very very fortunate indeed to have a job where you were allowed to work 4 hours off-time of the working schedule of your colleagues. Most people do not have such flexibility.
    – Ertai87
    Commented Jun 11, 2021 at 14:55

I’m going to assume that you don’t have the power to fix the company’s mistaken ideas about Scrum and focus on what you can do with what you’ve got. It is very difficult to break some types of software development into daily tasks, especially when your team consists of two junior developers.

First, you need to try to shift the thinking from “deadline” to “report on progress”. Try to focus on the team’s progress according to the plan and not individual progress or number of tasks completed.

Help your team show that they are on track by reporting that the progress made matches the plan even though a task wasn’t completed. You can try reporting whether the progress made today is “on track”, “ahead of schedule”, “blocked”, etc. instead of “completed task 123”. What is important is that the team knows where to put their effort to stay on track. If someone is stuck or falling behind on a task, the team helps them get back on plan.

I would lobby hard to get the meetings down to one a day, preferably at the start of the day. The team shouldn’t have to stop working at some arbitrary time near the end of the day to meet. If plans made at the beginning of the day can’t survive until the next morning, that’s a problem that should be fixed. Part of agile is getting better at estimating how long something will take, so if a junior developer didn’t include time to test in their estimate, they shouldn’t be pressured to skip testing; the plan should be adjusted to reflect reality and next time we estimate better.

  • 3
    WRT the last point, it seems like developers are being pressured to cut corners (e.g. write low-quality code, skimp on testing) in order to meet arbitrary "deadlines" set by project managers who don't know what they're doing. This is exactly the opposite of what they want to be encouraging. Commented Jun 9, 2021 at 15:28

This is a classic example of getting what you measure. If you demand showing some movement on velocity twice a day, you'll get velocity (but not necessarily quality, which the organization is apparently not measuring).

Velocity should be tracked at the end of the sprint, not twice a day. Velocity between this morning and this afternoon makes no sense - I'm not even sure what that's supposed to mean (or why people think that it's important). Most non-trivial engineering tasks take more than a couple of hours to complete, so the only way I would show any velocity at all between the morning and the afternoon is if I was working on some very small task. Unless you're breaking things down to an absolutely absurd degree (in which case you'd effectively be doing 6-hour sprints) or people are focusing on minor tasks, your velocity between the morning and afternoon should be 0.

Even the 0 figure is debatable because it's unclear what velocity even means if tracked on a daily basis. If I take three days to finish a 12-point task, does that mean that I had zero velocity on the first two days and 12 velocity on the last day? Or should I say that I had a velocity of 4 on each of the days? It's not clear why this is an even slightly meaningful measurement.

Also, the use of the word "deadline" is highly questionable. In Agile, the Product Owner writes and prioritizes user stories and then the Dev team accepts which ones they think that they can complete in that sprint. It's definitely not the same as a traditional "deadline." The expectation is definitely that the Dev team should be completing the work that they committed to for that sprint within that sprint (if they're not, that's typically a failure in planning), but there's no concept of a due date independent of the end of the sprint - that's superimposing traditional project management on top of an Agile process, not Agile.

While I would expect that developers would be able to show some kind of progress in each standup, the standup is not a deadline. Developers do not need to have a completed story each standup.

Make sure that you include time for testing and learning in planning. If the developers are learning a new framework, it will take longer to complete tasks in it (at least at first); any planning process that doesn't account for that is fundamentally flawed.

Finally, tasks aren't "done" unless they're tested. Developers should never be pressured into releasing untested code - that's the exact opposite of the kind of behavior you want to encourage.

  • 2
    It seems like a clear case of inconceivable-itis (“You keep using that word, I don't think you know what it means.”) on the company’s part. They’re calling it “velocity” because they’re “agile” now, but it is really just micromanaging.
    – ColleenV
    Commented Jun 9, 2021 at 15:06
  • 3
    My experience with corporate agile transformations is that some of the existing project management staff and managers never “get it” and think it’s a vocabulary change and not a fundamentally different way of doing things. If those people are the ones with the power to dictate “how we do things around here” this sort of thing is what you end up with.
    – ColleenV
    Commented Jun 9, 2021 at 15:14
  • 2
    @ColleenV Yes, their use of the word "deadline" also seems like it's not particularly agile. I edited to mention that too. Commented Jun 9, 2021 at 15:23

This is a version of scrum driven by people who don't understand the purpose and abuse it.

A standup twice a day? Reduce it to one standup per day. Also, reduce the "report" aspect of the standup - measuring velocity twice per day will help nothing, but waste time. The standup needs to be focused on solving real problems, blockers, unexpected difficulties and discussing what keeping you from finishing a specific story.

Otherwise, just follow the SCRUM process.

  • I never heard that it includes daily deadlines and assignments.
  • use the sprint velocity when it comes to the next sprint to estimate which tasks you realistically can take
  • The produce owner needs to prioritize with you based on the teams estimation

As far as finding a way to accommodate these developers within your company's system (whatever they are calling it), you say that they are struggling to complete tasks in time to have something to report.

Is it possible to work with them to break tasks down into pieces small enough for them to complete between reporting?

If so, I think this would be a useful exercise for junior developers regardless of the circumstances.

  • 1
    It certainly would be instructive to practice breaking down the tasks further into smaller pieces so they have something to report. Also gaming the system which they appear to be stuck with!
    – R Davies
    Commented Jun 9, 2021 at 8:17

Not really a direct answer but over the last three and a half decades I have seen your situation so many times in so many different ways. Your question is simply this:

"How do I battle against prevailing dogma/ideology for a pragmatic goal?"

I think the above answers saying "this is not scrum" miss the point really. It's useful as a retort to the powers-that-be to be able to say

ah well you see this is not scrum and real scrum is.... blah blah

but only in so far as it helps you change the prevailing dogma. If the powers that be come back with "well Scrum is open to interpretation" you are kind of stuffed.

One problem with your question is that you don't actually specify what your problem is. How is changing the methodology going to help you here? Do you want to get them to add tests? Do you want to send them on an Angular training course? Do you want to hire new devs? Is the problem bug count? What is that you want to achieve and why?

Do you have authority to make changes? If so what authority and what changes do you want to make? What's stopping you?

  • That is a lot of questions... Commented Jun 11, 2021 at 6:26
  • @PeterMortensen because the question should be closed as there is nothing in there to solve. All it is provoking is scrum fanboy and fangirl responses, all of which are irrelevant to the key problem, that he doesnt know what to solve and doesnt say if he has authority to solve it
    – Frank
    Commented Jun 12, 2021 at 3:45

Answering metaphorically:

You inherited a dumpster fire of a project.

Don't try to stomp it out. Put a lid on it until it chokes itself out or walk away. Trying to fight it will raise a big stink nobody wants. Otherwise they would have stopped the experienced devs from walking out.


Welcome to the absolute average Scrum/agile project.

Scrum is a super fragile construct that fails as soon as one of the key actors (company lead, product owner, scrum master, team) does not understand (or does not want to follow) their role.

One thing that amplifies that problem is that Scrum means to take power from the managers and give it to the developers. And, guess what, most people in power don't like to give that power to others.

That's how we ended up where we are now: companies transform to agile, because having that word in your company's description is en vogue, companies transform to agile in name only.

So in the end, you have three options:

Beat them

Get management, the team, the other teams and everyone else to move to proper scrum. Good luck with that.

Join them

Improve what you can (e.g. remove the second daily and daily velocity reporting) and game the system for the rest. For example count training/testing/code reviews towards the velocity and overestimate tasks to include all of the above. You get what you measure, so include what you want in the measurement.

Leave them

If you can't work with that system, get another job with a better system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .