I manage a team of 3 developers (4 in total) and every sprint we either fail to deliver the work we commit to, or deliver work that ultimately fails the QA process. Even though half the team is quite junior (this is their first job) everyone is smart and capable of writing logical, working, and tested code.
Things I've tried: * Reducing the scope of the sprint to something that should be very easy to deliver on (Parkinson's law got us) * Daily 1:1 10 minute meetings with each seemed to be a burden on a everyone and didn't lead to productive conversations. * Creating a rigid structure for the daily standup (Usually a ~5 minute meeting) but people seem to indicate everything is fine until 3-4 days before the end of the sprint.
For a young, scrappy, startup (we're under a year old) I'm struggling to understand if it's an issue of motivation, organization, team, or there are just some fundamental things that need to be fixed.
I would argue that everyone likes working with each other - so "starting over" isn't the first choice for anyone.
If you've got a technical manager who's trying to be the senior engineer, you'll have a conflict of interest in long term quality vs. meeting commitments.
If you have only a dedicated senior engineer you'll have worse relationships with stakeholders and communication out in general.
A senior engineer will help you meet deadlines. A manager will help commit appropriately (to keep same worklife balance).
But you also can't just have two folks on the team because they'd both burn out. So you need these two roles but then you also need another 2-4-6 developers, a mix of senior and junior.
This is the real killer. You need to find out why. Do they really think everything is fine, or are they afraid to indicate that things are not fine? What does "seem to indicate" mean here? You can't really know what to do until you know the answer to those questions.
Also, if I may be blunt, how do you know they're capable of writing correct code? Presumably there were conditions at some point under which they did so (or else you wouldn't make that assertion); what is different about those conditions to now?
Are you committing too much volume? Too much complexity?
You say that half the team is quite junior: I have found that junior developers often have a more difficult time judging how long something will take more than they do actually shipping a feature. They haven't been through the weeds like senior developers so they don't have that experience of "okay, well this can go wrong this many ways" yet.
> deliver work that ultimately fails the QA process
Hearing this makes me think that it's a complexity problem, tied in with bad estimates.
It sounds like you're committing to too much complexity and doing that with too much volume. Reduce scope, reduce volume and I think you will see better results.
It might be an unreasonable amount of work to deal with. Is it actually a team decision the amount of work that gets set for the sprint, or is it a senior's best guess?
It's also a very strange & distracting time to be alive, it's reeking havok with my mental health, it must be for other people as well.
My bg: Grown engineering teams from 1 person to 20-25 strong and have done this 3 times at various early stage startups. So you know can judge whether this might apply or not.
Depends on people: Are they task oriented / goal oriented ? You can detect based on how they talk about previous projects. Do they say they did x, y, z or do they talk about the big picture of the problem being solved, why they chose what they chose, its features/lack of features etc.
1. Task oriented folks want detailed action items and they don't mind you being super specific. With these folks, have a detailed plan of what to implement, how to implement, break it down into day by day plan. Try to be aggressive w.r.t goals (don't do this, if they are already demotivated), goals that are slightly harder to reach. But ensure that even if they are 60% is done, you will get a workable soln. Ensure that each days tasks are done and checked off and you can track daily progress. Catch up for detailed meetings every 3-4 days. This would be rescheduling of tasks, addition/removal of specific tasks that are no longer valid/requires to be done, re-prioritization/reorganization of tasks etc.
2. Goal oriented folks would want you to give them the vision and overall direction. But watch out for digression that lead to long discussions during such meetings. Tell them what you want to build and why you want to build that, how will the user use it. Then they will figure it out and you can have review meetings. They would not like to you put detailed line by line plans. Ensure you have high alignment during stand-up. Have check ins every 2-3 days to ensure that they are not going in completely wrong directions and you couldn't catch it due to brevity of scrum. But these are usually shorter meetings.
- While you did not share your own technical background, you say every team member is "capable of writing logical, working, and tested code". How did you evaluate them?
- They are deemed "capable" yet you note they "deliver work that ultimately fails the QA process." Are they "capable" but refusing to write tests? Are they writing "tested code" that is actually broken? Or does the individual worker product "tests" OK in isolation but fails at the integration level?
Without meaning any offense, I think team (technical) leadership is the issue here. You may get more actionable feedback if you share how you are managing this team and what you are bringing to the table. There are only 4 of you.
It may also be necessary to have a clear incentive structure for your team. IFF team leadership is not the issue, and there are no consequences to a continued pattern of "under performance", you can expect more of the same.
Stop committing to so much.
> deliver work that ultimately fails the QA process
Stop committing to so much.
> half the team is quite junior
Stop committing to so much.
I see you tried that, and Parkinson's law got you, but it might be that the team needs several sprints to catch their breath and also change the way they work.
> people seem to indicate everything is fine until 3-4 days before the end of the sprint
Sounds like they are afraid they can't be honest. There's something going on there.
How long are these sprints? I wonder shorter sprints would help flag things earlier. Think about "velocity" as a metric to base sprint length on. How much wall clock time does it take to get a spelling fix into the release? Something that should pretty much always pass QA, peer review, etc. How often is your reworking a deliverable after QA fails it? Those two numbers should inform how you set sprint length -- long enough to get through the release process in the happy case, times enough iterations to reach that happy state.
What are the daily standup status reports like? If you want earlier warning signs, I would suggest a three tier approach: Green, Yellow, Red.
Green: deliverable is on track and expected to be completed on time.
Yellow: deliverable is at risk, but a minor amount of additional information, discussion, attention or overtime can put it back on track.
Red: deliverable is unlikely to finish on time and to spec.
The thing you as a manager/project manager want to avoid is a deliverable going directly from green to red, as it means your team is unable to assess or react. It will probably happen with juniors and new teams, but your job is to communicate displeasure at the event, and coach them privately (during weekly 1:1's) how to avoid that going forward.
Given how hard it is to estimate software dev (for oneself let alone for a team), I think the speed with which your team produces quality code is more an emperical observation reflecting your team composition and dev/QA processes rather than a commitment you make. Especially so when the team is new and young.
> or deliver work that ultimately fails the QA process
How many layers of QA/QC do you have? For example, you can think of 4 layers: 0) spec/ticket/story author 1) code author, 2) code reviewer, 3) pre-release manual integration QA (by testers).
These are very different activities (eg reviewer may not actually run code but could be able to tell by looking at code that something's wrong) with increasing cost of fixing issues at every layer. If you leave most of your QA to the last step you end up with a lot of hours spent fixing bugs while you could have avoided most of the same issues (and more) if, say, devs had clear instructions for testing their code and a solid review process.
The scope isn't your decision, it's the team's decision. They should only be committing to
Do three things:
1) Track the work committed to work completed ratio. You want to goal this towards 90%. It's a great metric because it's not easily game-able and it serves your team's interest.
2) Make sure all tasks are broken down into small chunks (no task should be a >3 day worth of work task). If you have a developer who has 1 ticket for the entire sprint then your tasks are too big and need to be broken down.
3) Get the team to commit early and often. It sounds like right now you might be doing "mini-waterfall" whereas you want something more like Scrum. There should be visible progress on Day 2, even if it is just notes on what they are thinking through to implement.
1. A good leader takes less than their fair share of the credit and more than their fair share of the blame. Your team will trust and respect you when they know you're not just trying to look out for yourself. Your perspective needs to be, when things go right, THEY did great a great job. When things go wrong WE messed up, let's learn from it and move forward.
2. Set clear expectations. I make sure my teams know that I'm ok if we mess up, I'm ok if we miss a deadline but I'm not ok if I'm the last one to know about it. Rule #1 Don't surprise me. If you see a problem, let me know. I can't have skin in the game if I don't know what's going on.
3. Stay technical. I was formerly a full time dev but now manage full time. I schedule 4 hours a week off hours for myself to code to keep my skills sharp. I see that as investing in myself and my career. Technical decisions need to be made by the team and you should have technical leadership on the team but you also need to be able to spot someone BS'ing you or people being overly optimistic. It also instills trust in the team to know that their boss can keep up in a technical conversation.
4. Invest in testing. No one likes writing tests but they pay dividends. You trade a little bit of speed up front for massive speed and scalability down the line. Don't skimp. This was the single greatest driver of predictability when I was a full time dev.
5. Lead through principles. A lot of people get hung up on particular ceremonies or particular things to try but no two teams are alike. I've managed several different teams and things that worked on one didn't work on another but through it all I maintained the same principles. They hang on my office wall: A. Do the right thing B. Be honest C. Invest in others D. Invest in yourself E. Demand quality
Start with ditching scrum. Have everyone focus on exactly one user story at a time until it is complete and passes QA. Once it does, go on to the next one. Every time I suggest this, people tell me I'm crazy, but every time I've talked a team into trying this it has increased their throughput.
There are lots of reasons why this works. It reduces time lost to queuing, reduces crosstalk and coherence penalties, tamps down on Parkinsons Law, and many more.
Junior developers struggle with estimating time so you are going to have a period where they are learning now to estimate how hard something is. Be open about with the team and your management. Explain to them why it's important that you deliver what you promise (dependability).
The other big gotcha is how much time are you spending working on features versus working on the things which enable those (such as testing, monitoring, clean APIs, refactoring, deleting dead code)? If the bias is too far towards features then you'll collapse under the weight of your own tech debt. I've had situations where I had to tell teams to stop working on features and fix the foundations.
make sure you foster intrinsic motivation, as people want to feel capable and good at their job. consult with your team on what you're all trying to broadly accomplish together, and make sure you've established that common ground first.
focus on trusting and believing in your team more, not less, as communication correlates with trust (e.g., problems manifesting late in the cycle). go for small wins first to get a cadence and trust established.
poor team dynamics are almost always about (perceived) unfairness, both internal and external. remove as much unfairness as possible. where you can't, commiserate, don't justify.
Why is "every sprint we either fail to deliver the work we commit to, or deliver work that ultimately fails the QA process"?
Is it you fail to deliver the work because of QA? It sounds like that might be the first why.
Why does it fail QA? Lack of unit testing? Are there any patterns in the bugs? Maybe that code is brittle and hard to work with?
Dig down, as the reasons for under-performing could be entirely the team, or the team actually over-performing considering the environment. Technical reasons you can fix. People issues you can fix with management, process, etc.
If you can do a blameless postmortem, go for it. Maybe you can improve morale by giving people the opportunity to fix their own problems. If you don't think that can happen, then that alone may point toward the problem.
Agile development is just a tool, not a magic incantation. For Scrum: Committing to a Sprint backlog makes no sense when the product still fails after the Sprint is finished. There should be no after . Done must be done - if it’s not you’re not doing it right. If possible I’d completely focus on fixing this point first.
(Background: Agile development, then coach since 10++ years. Now have a small startup building some niche BI software. (Interestingly coaching other people for money does not mean you’ll be doing it right yourself.))
You may also want to try and identify the weakest link(s) in the team and see if are not pulling their weights since in a team of 4, even 1 weak link means 25% impact.
Are you telling them to reduce scope or working with them to take some of the work away? Try the latter, ensure they have ownership over the reduction and that the reduction is not prescribed.
>> Daily 1:1 10 minute meetings with each seemed to be a burden on a everyone and didn't lead to productive conversations. * Creating a rigid structure for the daily standup (Usually a ~5 minute meeting) but people seem to indicate everything is fine until 3-4 days before the end of the sprint.
In the standups, you may need to probe to understand what they actually accomplished and whether they are on track to finish the sprint.
By setting the scope, you will always lead into this.
>Daily 1:1 10 minute meetings with each seemed to be a burden on a everyone and didn't lead to productive conversations.
Never works. 10 minute meeting will at best disrupt an hour of their time. You already had a problem with delivering; you just lost an hour each day * 3. The other issue is that it assumes the conversation each day goes correctly. For example I had a micromanager boss who would regularly insult people at the morning meeting. That eliminates the entire day of productivity for the insulted person.
>Creating a rigid structure for the daily standup (Usually a ~5 minute meeting) but people seem to indicate everything is fine until 3-4 days before the end of the sprint.
What they usually end up being is that everyone says everything is fine and on schedule and the 1 person who takes it seriously ends up being interrogated everyday. Which makes everyone else not want to talk.
>For a young, scrappy, startup (we're under a year old) I'm struggling to understand if it's an issue of motivation, organization, team, or there are just some fundamental things that need to be fixed.
The knowledge you need is >100 years old. Possibly older. You aren't ready for this fix.
Everyone on the team wants to contribute but it sounds like you're setting scope with this 1 other person. The not junior person. You have yourself a Brent(pheonix project). You cant have healthy competition with that team. You can't have titles. You cant have metrics. You can't set early deadlines; if you cant meet them now, you certainly cant meet them if their shorter. You're not ready for individual teams or isolation.
You must start with fixing the team by creating a team. Team building is a big field and depends on personality of the team.
Mastery, Autonomy, and Purpose.
Don’t try to create a process like scheduled meetings. That’s just surface stuff. Unless your people are incompetent there must be some deep problems that need to be uncovered. Most likely there is a problem in communication or understanding. Also solicit feedback about yourself and other managers. This may be painful but is often necessary if you really want a better team.
I'm confused. Are there 4 developers, and you only manage 3 of them, or are you managing two junior developers, one less junior developer and you are also trying to develop?
If it's the latter, you're likely expecting to be able to contribute as a developer as much as when you weren't managing. Especially for junior members, you need to be checking in frequently to see if they're making progress or getting stuck, or that their 'done' code is doing what it needs to. That will take your time, and some of theirs.
Adding more details to your question about the nature of work and business domain, along with QA issues would allow people to give more actionable insights.
Consider breaking the tasks such that this is not possible.
Sounds like your team is so junior that they don't know how to decompose a bigger task into subtasks and go about building it up. This is not their fault probably - they simply haven't learned the skill yet. So you might want to step more into helping them by showing them how.
1. Fail to deliver work: It sounds like your prediction is simply off. Aim to have smaller sprints with stretch-and-reach goals. I.e. "must haves" and "nice to haves". Really reduce the "must haves" to as much as you can get away with. The other good side to this is you can spin this towards "over delivering" a light sprint, rather than under-delivering on a heavy sprint.
Also you might need to play about with the size of your sprints, if they are too long then focus is lost and things go off track without anybody noticing. If they are not long enough then you aren't really able ever to complete anything and the temptation to just push the task into the next sprint is too high. If a task being actively worked on does run over the sprint, never copy/move a task from one sprint to another, always make sure it's rewritten and refocused based on the progress and in light of difficulties had.
Keep track of sprint planning and use some metrics to better estimate how much can be safely packed in. Track task estimated time and actual time, then look at the differences. You'll find some people have an optimism bias when calculating estimated time, ask them to factor this in.
2. Fail QA process: This seems like a failure to test the project extensively, unit tests are not enough. In the past we have implemented a code-freeze some time before the sprint-end/deliverable and then proper testing is done (sitting down with use-cases and going through them one-by-one), with only minor bug fixes allowed. NEVER allow last minute feature pushes, they WILL bite you. It's better to just over deliver in the next sprint when it's well tested.
Usually (depending on the size of the team) this would be one dedicated tester and one dedicated bug fixer, with the other two people working on stuff that won't meet the sprint deadline but will be useful towards the project's goal (a great time for evaluating a few different libraries for example).
General point: Say you get in at 8am, at ~9am (after people have looked at some emails) grab some breakfast and a coffee with your team for 20 minutes or so and plan the day. Just discuss some general points like "I'm going to keep working on X, progress is slow because I ran into Y yesterday". It just helps to keep things focused and the whole team know what's up. It's also good for morale.
Make them feel like each failure is an opportunity to learn that they need to put to good use for the next deployment.
Build a process that turns your team into an effective team
Don't insulate the team from the product owner, let them feel the pain of not delivering.
Shorten the sprints down to a week to reduce the feedback loop time.
Stop doing commitment based planning, just work through stories in order and get a feel for your capacity/velocity.
Minimise the work in flight, all work on the same story if you possibly can.
Pair more.
Then maybe take a holiday for a few weeks and see what happens.
What changes need to be made in detail.
1. Explain to management/lead/whoever is above you that things aren't going well and you're going to change stuff up for ~1 to ~2 months and productivity may not be massively improved for ~3 to ~4 months out. They have to understand things might get worse before they get better.
2. Drop the notion of a "sprint" and switch to a kanban like workflow for a little while. Work with management to find the highest priority issues and use the priority field in your ticket system to track what will have the highest impact. You should meet with your boss 1/week to update these priority so they stay current. The goal here is to stop commiting to any work because that's a skill that hasn't been developed in your team yet. If you are commiting to things and 100% of the time you fail to meet your commitments you're essentially alrady doing kanban with waaay more artificial stress.
3. Do a (~weekly) call with engineers and estimate the effort/difficulty behind each of the next N tickets in your backlog. N should be ~5*$num_engineers - 5x is used because it's small enough so people aren't overwhelmed by the work but they still know what's coming down the pipe. You should not impose anything in this discussion, just be quiet and let the engineers talk until they all agree. There's going to be a lot of bike shedding and as management your main goal is to keep everyone laser focused on what the effort things are and what the blockers are. You should also ask the engineers how to break up bigger issues into smaller work items if they are lower priority. Focus on lower priority items for this type of breakup because this is a hard to learn skill and if you need to deliver meaningful features WHILE doing this team change up you'll be having a hard time shaking up the process for critical work. This meeting is essentially going to demolish an entire work day and everyone will hate it.
4. During each of these meetings you will secretly keep notes on what you hear being brought up. I'm assuming you're not technical and if that's the case look for "we can't do that because $x isn't really able to be used like that" or "we hit another limit in $y and using it is a pain in the ass" or "after we deployed $z we found that it wasn't at all the same as our dev environment". You will then schedule a weekly catch up with every engineer (most junior -> most senior) and ask them how work has been going and bring up some of the things you've heard about. When talking to the most senior engineers ask them if they have ideas for how to fix these issues. If they do ask them to make some tickets in the backlog, if they don't add a investigation ticket into the backlog.
5. During your next meeting with the people who set priorities choose some amount of tickets (~20%) to include into the top of the backlog.
6. Have a 1/quarter meeting with all engineers and discuss what the goals are for the next quarter. Ask each engineer to take 1 thing to accomplish by the end of the next quarter that will deliver measurable business value. These goals should have accompanying tickets in the backlog. This is to help reduce bystander effects and to make it clear that "my job is to ship X by Y". 1 quarter is a long enough time that most people thing "pfft that's so far away it's not really a deadline" but short enough that you aren't going to sink or swim over that timeline (hopefully your runway is longer than 4 months).
7. Track the amount of output of the team. If you are using points to estimate how hard things are then use that as a (shitty) proxy for measurement. You want to see #-tickets/week and #-points/week rise. Once they've risen to a high enough level talk to engineers about work/life balance. If everyone is super happy then don't fix what ain't broken. If everyone is super unhappy talk about going back to a sprint-based workflow with the team and help them choose a number of tickets that makes them feel less overwhelmed.
7. If you're still not hitting quarterly business goals that you and management are setting after ~6 months and the engineers are unhappy ask them to help you invest in educating them. Interview some consulting companies as a team, look for good talks, etc. Outside eyes may be able to help spot what's going wrong.
I'd love to hear from others about how this process could be improved because I've only ever implement these processes internally at a company and no one ever gets to see/grade that work.
I think identifying and acknowledging unknowns and uncertainties are a good start, and as it happens, it's nothing unheard of. Teams can take time gaining efficiency, but if they are serious about improving, then they will. Immensely. I've gone through situations like this one many times, and despite all the uncertainty, I'm confident in the outcome of our product and of our team, so long as we stay confident and methodical about improving ourselves, our team, our processes and yes, our company. Improvements have already been massive.
Agility ohh _ The only really important aspect of agility is introspection and the spaces created to objectively and respectfully be critical of most everything. At all levels. (personal, team, project, and team or project context). It doesn't necessarily mean specific meetings, but it does mean being critical of the current me/us on regular basis ~ possibly just keep an ongoing checklist). That's the linchpin.
Communication is likely where you'll ultimately get the biggest win (knowledge transfer means level up in all sorts of dimensions) Communication is also where you potentially stand to lose most longterm... It's a long ongoing process that is pan-project. Efficient communications are on point. That's: - concise, - on topic, - structured PRs, docs, slacklike code blocks, tight dailies, (and tight deadlines :-P) are all good training grounds for efficiency. Note that those skills will help anyone facing a task needing some break down. Trust and respect mean clearer thoughts and more direct communications. Work on teambuilding. There's lots of ways to do it. Sharing a screen a and keyboard once in a while is a great way to get to know how other developers think and work. Going out for drinks and knowing a little about each other is a good way to learn how to respect each other beyond the simple coding.
Uninterrupted flow is key to good code production right? - Working on communication can bring synergy within the team, each just knows when's a good time or not a good time for the others. - Practiced com channels are also generally less disruptive. - Set aside chunks of coding time for the team?
Tests: In my experience, bad tests/testing is most caused by not enough time to write good tests. Getting better at that might be a case of devoting a sprint priority on the test process, frameworks, ease of use, and task definition. Everyone should be comfortable writing the required tests. Having an already started codebase and test backlog actually helps because you'll more easily uncover patterns that you may have missed in the stress of running late. Testing becomes a lot easier if you've actually given it enough effort to mark a significant improvement.
The project itself: Most aspects of a project are tied to the delivery itself. Hazy goals and a hazy roadmap to delivery (the deep level roadmap, tech bit by tech bit) are very disruptive to one's focus. Thankfully as you avance in the fog you will acquire visibility. Some will gain visibility faster than others (like the PM and any dev tied to the app plumbing), but on a technical standpoint you need a team that is confident in the roadmap; not in a sense of time, but in the sense of all the necessary steps that need to be taken in order to achieve the goals. Confidence in someone with that confidence can also be enough to go on.
With a bit of confidence in your pocket, each step of the way can be a lot more focused. Developers don't need to constantly be looking in the distance and face the looming deadlines, but can instead focus on the present problem, knowing (or working on accepting), that it's a necessary step, and that there will simply be another after that. Better focus. Productivity-wise, the mindset is simple: "Oh my next goal is that, and I need to take those smaller steps to reach it, well the path is clear, let's do it and simply get it done."
A simple metaphor would be the climbing of a nice big mountain. There's a point at which the effort is such that it's easier to just stare at one's feet, and just take a step at a time (ah and there's less tripping over roots). As you go up, you gain strength and stability, and you can start keeping your eyes ahead more. Remember to look at the view: wow what a beautiful sight this and that is! Look at how high we are, look at that beautifully challenging clifface we're going to be tackling :p It's the journey right? Savor it or make it so.
As a developer, we have to be able to focus enough, but there is a lot of shakeout that needs doing while we gain visibility and efficiency. At first, the confidence may need to come from the outside (from you): trust in the team's individual qualities, trust in the introspective process. As time goes, the confidence comes from the increased visibility, achievements, the increasing smoothness of communications, the increasing trust, awareness and confidence and respect of each developer for they own selves and their teammate's strengths and weaknesses (face them and improve on them eh?)
Risk. Figuring out your unknowns early is critical to correctly evaluating your deadline. Unfortunately it's also not very good for confidence building as tackling risky aspects of the projects is generally hard and not very rewarding productivity wise, though it has huge longterm benefits. During those times, acknowledge the current situation, and focus on the positive aspects of the project: typically at that stage, visibility is increasing, some team processes may be falling into place, we've identified all these pain points, etc. There's discovery going on in all sorts of directions and though it's daunting it's a good thing. Also, once those risks are better known, and perhaps dealt with, your output speed is going to increase rapidly hurray. (Note: change in velocity also might mean need for readjusting things eh?)
The deadline? You'll note that I haven't really worried about any actual deadlines. Here's the thing: knowing your team is actively working on improving itself, you should have confidence that they are working at best capacity at any one point in time. If the deadline is too short, what can you actually do? Make your team magically better? No, of course not. You can only give them your confidence in that they are doing their best. Yourself, focus on realigning goals, load, priorities, timelines and resources. Give them the time and tools they need for self-improvement and be a driver for that improvement.
Rituals and all are pretty good, but do allow flexibility and allow everyone to be critical of them. Standards can be a good skeleton, but the principle is that you need to continuously fit things to your needs. Meetings should be adding clarity, but they do take some focus away as well don't they?
My 2 cents, I hope it helps, though I realize it's all somewhat intangible and way too verbose.
I think identifying and acknowledging unknowns and uncertainties are a good start, and as it happens, it's nothing unheard of. Teams can take time gaining efficiency. Agility is introspection, so retros at each level (personal, team, project, and team or project context ~ doesn't necessarily mean specific meetings, but it does mean being critical of all of that each time ~ possibly just keep an ongoing checklist). That's the linchpin.
Communication is likely where you'll ultimately get the biggest win (knowledge transfer means level up in all sorts of dimensions) Communication is also where you potentially stand to lose most longterm... It's an long ongoing process that is pan-project.
Uninterrupted flow is key to good code production. Working on communication can bring synergy within the team, each just know when's a good time or not a good time. Practiced com channels are also generally less disruptive.
Efficient communications are: on point (concise, on topic, structured ~ PRs, docs, slacklike code blocks, tight dailies, (and tight deadlines :-P) are all good training grounds. Note that those skills apply as well to a anyone facing a task needing a break down.)
Tests: In my experience, bad tests/testing is most caused by not enough time to write good tests. Getting better at that might be a case of devoting a sprint priority on the test process, frameworks, ease of use, and task definition. Everyone should be comfortable writing tests. Having an already started codebase actually helps because you'll more easily uncover patterns that you may have missed in the stress of running late.
Most aspects of a project are tied to the delivery itself. Hazy goals and a hazy roadmap to delivery (the deep level roadmap, tech bit by tech bit) are very disruptive to focus. Thankfully as you avance in the fog you will acquire visibility. Some will gain visibility faster than others (like the PM and any dev tied to the app plumbing), but on a technical standpoint you need a team that is confident in the roadmap; not in a sense of time but in the sense of all the necessary steps that need to be taken in other to achieve your goals. Confidence in someone with that confidence can also be enough. With that confidence, each step of the way can be a lot more focused. Developers don't need to constantly be looking at the distance and looming deadlines, but can instead focus on the present problem, knowing (or working on accepting), that it's a necessary step, and that they're will simply be another after that. Better focus. The mindset is simple: oh my goal is that, and I need to take those smaller steps to reach it, well let's dive in.
A simple metaphor would be the climbing of a nice big mountain. There's a point at which the effort is such that it's easier to just stare at one's feet, and just take a step at a time (ah and there's less tripping over roots). As you go up, you gain strength and stability, and you can start keeping your eyes ahead more. Remember to look at the view: wow what a beautiful sight this and that is! Look at how high we are, look at that beautifully challenging clifface we're going to be tackling :p It's the journey right?
As a developer (I'm all over the place :p) we have to be able to focus enough, but there is a lot of shakeout that needs doing while we gain visibility and efficiency. At first, the confidence may need to come from the outside (from you): trust in the team's individual qualities, trust in the introspective process. As time goes, the confidence comes from the increased visibility, achievements, the increasing smoothness of communications, the increasing trust, awareness and confidence and respect of each developer for they own selves and they're teammates strengths and weaknesses (always more areas of improvement :))
You'll note that I haven't really worried about any actual deadlines. Here's the thing: If your team is actively working on improving itself, you should have confidence that they are working at best capacity at any point in time. If the deadline is too short, what are you going to do? Make them magically better? No. You can only realign goals, load, priorities, timelines, resources and have confidence in the fact that they are getting better. Give them the time they need and be the driver for improvement.
Rituals and all are pretty good, but do allow flexibility and allow everyone to be critical of them. Standards can be a good skeleton, but the principle is that you need to contributorily fit things to your needs. Meetings should be adding clarity, but they do take some focus away as well if they are too many.
Work on teambuilding as well. There's lots of ways to do it. Sharing a screen a and keyboard once in a while is a great way to get to know how other developers think, though it doesn't work for everyone eh?
Ok I'm done. Ways to go but our team is improving greatly btw, that is so satisfying in and of itself.
What I read between the lines is the evergreen management pattern in which someone decides objectives and everybody else is held accountable for meeting them, at two levels: you with your team, and your users and bosses with you.
"I manage a team of 3 developers": you aren't a developer. What are you doing in the team?
"Deliver the work we commit to": you commit, they deliver.
"Deliver work that ultimately fails the QA process": you are unable to test what you are writing before losing face with your internal customers, whom I mostly imagine as assholes who are much more eager to judge your work than to assist you.
"Half the team is quite junior": unlikely to be able to say no. Thinking of it, the more senior developer is likely to be more aware of likely problems but more expert at manipulating you.
"This is their first job": but you expect them to provide good estimates.
"Everyone is smart and capable of writing logical, working, and tested code": you cannot be sure, particularly if failures and difficulties are a weakness that should not be admitted. If you are threatening underperformers with consequences, they'll spend their time and energy to avoid appearing to be underperformers, not necessarily to perform better.
"Reducing the scope of the sprint to something that should be very easy to deliver": increasing micromanagement, but not productivity.
"Daily 1:1 10 minute meetings with each seemed to be a burden on a everyone and didn't lead to productive conversations": How would admitting that a task is above the developer's skill level, that delivery will be late, that work has been grossly underestimated, etc. be a good move for the developer? You need to reward openness, but you are clearly rewarding reports that everything is fine.
"Creating a rigid structure for the daily standup": you mean a more judgmental structure.
"People seem to indicate everything is fine until 3-4 days before the end of the sprint": because near deadlines lying too much is worse than admitting defeat. How far from the deadline sincerity begins is an objective measurement of your attitude.
"I'm struggling to understand if it's an issue of motivation, organization, team, or there are just some fundamental things that need to be fixed": what else do you consider fundamental for your team besides motivation and organization?
"Everyone likes working with each other": you cannot be sure, if discussing a problem with a colleague marks people as a snitch, a loner, a bullying target, etc.
Hopefully you, your team and your company are not as bad as your post might suggest, and you can simply improve productivity by improving processes. I'd try to analyze how your developers wasted time and find ways to prevent or mitigate the issues in the future, demanding justifications for being late and analyzing them in depth, which would prevent bullshit excuses that can't withstand scrutiny, encourage attention to wasted time, and demonstrate that you care about the problems of the team.
Solution: Find someone who does understand and who is interested in the team's success by giving them equity in the company.
> I would argue that everyone likes working with each other - so "starting over" isn't the first choice for anyone
Where did you get the money to enable this awesome lifestyle of prioritizing people 'liking' stuff all the while you're failing to deliver what you've set out to do? I'd like to get some of it for myself, it sounds really nice.