My team does not appear to benefit greatly from agile. It has four developers, a QA engineer, a project manager, and a scrum master. We never complete all of the committed points in our sprints, and we never reach our deadlines.
I’ve received scrum alliance training, as has the scrum master. 90% of scrum is being followed, with some flexibility for the daily stand-ups.
Fundamentally, our developers still don’t deliver on the promises they made for the tales they themselves estimated. They don’t seem driven or inspired.
Has anyone witnessed this? I wonder if agile is a factor in the issue. Project timeline estimation requires structure. All I know is agile.
Agile is, first and foremost a philosophy, not a technique. The phrase “flavour x of agile framework is not working for my team” is probably what you’re trying to communicate.
Great, let’s now determine the cause. There are so many questions we could ask, but I would start with the most fundamental ones and see what comes out. Be tactful and make sure they understand that your goal is to solve the issue, not find someone to blame.
I’d start by trying to understand why your team lacks inspiration and motivation. Ask them directly. What keeps them from completing the task? What are they upset about? Is it the method? which task? (Seems to be a hybrid of both.)
I believe that this is the appropriate response @RisaButler. For a moment, approach the problem like a product manager. Without first confirming the issue, you wouldn’t construct a feature or product, right? This also applies. Before you alter your procedure, ascertain why it is failing. If the issue is merely one of estimating, you should focus your attention on more accurate estimation techniques.
Why, if there is a motivation issue? Is there a connection to your present SDLC? Is it a disagreement with others? Do they merely despise the business? Or do they feel cut off from the real value your product offers?
One suggestion on this front, and something I believe many PMs underperform at, is that part of your job entails inspiring your team to embrace the product’s vision. We treat engineering far too frequently like a deli counter. We add user stories and anticipate that Engineering will complete them as quickly as if you had just ordered a pound of honey sliced ham. Is that actually the goal for your team? Is it merely a feature factory? Utilize your position to inform them about your target market, the issues they face, and how your product will improve their quality of life. You must increase that with if you want people to share your enthusiasm for the work being done.
This. I would probably ask for feedback in 1:1s vs asking the team at large. The latter makes it very challenging to avoid finger pointing games (particularly in our zoom world). Get to know the developers and everyone on the team at a level that shows you care, and in a 1:1 situation, you’ll receive some priceless input about what’s preventing people (and, consequently, the team) from feeling engaged at work. either operational, morale-related, or both
This is encouraging @KaranTrivedi. I occasionally find retrospectives to be overly courteous. They typically don’t produce open feedback. I should set up 1:1 meetings with them. Although they could be improved, the relationships I now have are positive.
I didn’t do this at first since I didn’t want to encroach on the dev manager’s domain. However, I believe the time has come to end it.
@DhirajMehta, This concept is great. I believe it is a result of both the process and the company culture. The company culture frequently encourages employees to “cruise.” The dev manager is inexperienced, ineffective, and uninterested in the developers’ professional development. She contributes more on an individual basis.
According to a senior developer, the team is less effective now that scrum has been implemented. Maybe there’s a little apathy in him.
Uninspired and unmotivated seem to be the issue rather than the procedure. How well do they understand the demands? Are there frequent roadblocks like bugs or tech debt? Are there any dependencies on the outside that breed uncertainty?
I agree that motivation rather than process is the main issue @MarcoSilva.
Some developers, nevertheless, are hesitant to participate in scrum and take their time. This is despite the fact that we engaged in 15 sprints and were quite receptive to criticism. If there is another framework that developers prefer, I wonder what it is.
The phrase “The beatings will continue until morale improves” or that dreadful Bertolt Brecht poem that every undergraduate usually repeats come to mind when listening to this.
I don’t know your team at all, but I’ve worked with a lot of teams, and it’s much more typical for there to be a process issue than for the team to have the right procedure but not have the drive to make it work.
What was your answer when they voiced scepticism, given that you claim to be highly receptive to criticism and that you are aware of their scepticism? Just reminding them that they needed to become more motivated in order for scrum to succeed would suffice? That would seem really discouraging, no?
“Drag their feet along” refers to your devs’ use of passive resistance since they disagree with the system but do not think they are being heard or that they have the authority to affect change.
This will undermine the business, induce attrition, and be detrimental to the team and eventually the product, and you will be held accountable for it. Instead of blaming others, you must personally confront this issue.
It seems like your issue is with scrum, right?
If I were in your position and had the power to make changes, I would inform the team today that I have listened to their suggestions, that this will be the final scrum sprint for the time being, and that after the current sprint concludes, we will be experimenting with a completely different agile framework (I recommend something pretty un-scrum-like, such as kanban).
Ask whether it is working after trying that for a month or three months. Try something else after that for a month or three months.
Then start incorporating the various components you enjoy from the various conventional agile approaches into your own.
However, even if you lack the power to implement real change, you can still have an impact by lightening the load of scrum’s formalities and its administrative costs. For instance, how significant is velocity tracking overall to your business?
That was very detailed and descriptive response @MichaelYoffe. Really appreciate and will definitely try to implement your suggestion of changing the scrum methodology. Thank you so much once again.
Don’t rush into the agile alternate solution space; instead, take a step back.
How are you meant to fix the problem if you don’t grasp it at all?
What connection is there between your developers’ lack of motivation and the agile methodology?
Why don’t your developers seem to be motivated?
Why can’t your developers commit to the deadlines they’ve set for themselves?
Get to the base of the issue rather than the symptom by using the five whys.
I ask that you all take a moment to breathe. Take a step back and hold a group brainstorming session to get everyone involved in coming up with a solution. Run a Double Diamond/Design Thinking workshop, delve into the problem domain, pinpoint the underlying cause rather than the apparent issue, complete the whole HMW, etc., then impose design constraints, brainstorm, plan, and execute, then iterate until you have a solution.
How can you deliver a great solution or product to the customer as a team if you can’t even produce one for yourself because you’re saying, “I don’t have time for that”? It is paradoxical. Simply said, you cannot prevent people from drowning if you are drowning yourself, just as you cannot go to work if you have neglected your health and are currently contagious.
Excellent issues to think about @NaomiNwosu. I am taking some time to reflect and formulate my strategy because I take this matter seriously. I respect Reddit PMs’ viewpoints as well. I asked you all for that reason.
One developer thinks that before we switched to scrum, when we were using waterfall, the team was more effective and efficient. He specifically complains about team planning poker, project pairing, and teamwork. Before there was a scrum master in charge of ceremonies and adding a layer of administration, he preferred it better the way it had always been. This, in my opinion, affects his drive.
Therefore, even if scrum may not be the only issue, it does cause a problem for this dev, who is our best and sets the tone for the others.
how does your team estimate stories? Do you keep in mind historical context? Something I’ve seen with very well in the past is reaching back to previous sprints to discuss stories that were the “definition of a 1/3/5 SP” and having both the devs and the QAs align on it and use it as a guide in future estimations.
how do you determine what your team capacity is? People will always overestimate their abilities if you leave them to their own devices. Is your scrum master looking back at running average velocity? Are you leaving some time at the end of the Sprint for “spikes” (research), creativity and refactoring? I found those helped with my older teams with not only getting motivated but writing more efficient code and being more innovative. Remember they’re missionaries not mercenaries!
One last thing, I just thought of:
If all else fails, have the most Junior developer(s) estimate the stories and explain their methods and reasoning. Maybe run with the “worst case scenario” sizing for a sprint or two to see if you can balance the scales. Or see if it can motivate the Senior members of the team to come in with their counterpoints/opinions if they have more effective solutions. If they don’t already, see if they can pair program on the more complex issues.
Hope this helps! I’m working on a waterfall project after 5 years of agile and I miss it.
This problem will exist regardless of which management philosophy you use. Software estimation is a whole art of its own.
If your team is unable to effectively estimate on a micro level with agile, they are going to do even worse on a macro level if you move to something like waterfall. I’m not saying that agile is necessarily the right philosophy for your team, but I am suggesting that agile isn’t the source of your problems.
@LawrenceMartin, Agree with you 100% after thinking about this more. I think what I have on my hands is (1) a motivation problem and (2) a curiosity to see if something outside of scrum or kanban would get devs more excited.
Let me tell you what I implemented that helps improve the accuracy of deliverables.
Start with a three-tiered commitment system.
Hard commits- these are deliverables that the team is convinced with a 98% confidence that they will deliver on time.
Soft commits - these are deliverables that the team is convinced they can deliver with above a 75% chance to deliver on time.
Nice to have - this is just like your typical nice to have.
You need to explain to the team, that they are operating as expected when they complete both the hard commits and the soft commits.
What will likely happen is for several sprints your team will Will miss on all three categories. And you need to make it absolutely clear that hard commits must be delivered. If a hard commit is missed then you need to have a retrospective meeting. You need to emphasize in this meeting what happened how did this happen why did this happen what can be done to fix it. This will help get the message across that you are serious about how important hard commits are.
Then you will start seeing the team improve and starting to deliver the hard commits with very high accuracy.
Then it’s time to work on the soft commits. The soft commits are still very important. (Maybe use a better name than soft commit now that I think about it). Missing a soft commit is expected, however the accuracy of their estimates needs to be Good enough that if a soft commit is missed then a nice to have is brought into replace it.
This may not be the solution to your problem but it has worked wonders for me in the past.
You (assuming you’re the PM) need to take a step back and identify what your objective is, review the requirements and steps to meet it with the team, identify what challenges are in the way and how to mitigate them, and put in place a recovery/improvement plan.
Agile is not the problem here is my guess. I suspect it’s an issue with your estimation process, perhaps they aren’t breaking down the development into small enough chunks to estimate effectively. But you may need to look at other processes/methodologies that might be a better fit for your team and product. Hey if waterfall gets your developers excited and engaged, use it for now to make incremental progress. Then slowly work in agile over time.