108

Backstory:
I have been working as part of this team for the past three years and in this time we have had three different Scrum Master who have all run things differently.

Because of this change in Scrum Masters and their way of running the show, it has left my team numb to the idea of Scrum because the principles haven't been enforced consistently and one of the Scrum Masters was a person who do not believe in agile development and just kept events and artifacts as a novice to comply with company decisions.

Now my team members are annoyed and bored when we do Scrum events and one person in particular is very verbal about this.

Present:
Two months ago the company appointed me Scrum Master of my team because of my dedication to working agile and its principles.

I'm suffering greatly under the atmospheric pressure of my team members unwillingness to do Scrum.

As mentioned they are annoyed about the entire process which makes it very difficult for me because they are not engaging in the necessary conversations needed to make Planning, Retrospective, and Daily Scrum effective.

To them, Planning is just a waste of time, because we just move overflow into the new Sprint and don't complete the work anyways, so why bother.

During Retrospective I can just feel that they want to say "Stop doing Scrum". One person does, but the others are silent and I have to deal with this every time.

Daily Scrum is again just a waste of time for them because none of them bothers to talk and plan the day. They just state "I worked on task X yesterday and will work on that again today." And most of the time they just joke around until I get more stern.

I have been very large when it comes to how they spent their time during these events. But I'm dying on the inside because I have a passion for this and they don't care anymore.

Today the person who's always against me told me to stop saying "They said this is what they committed to for this Sprint" because, in his words, "We never complete a Sprint. We just move in tasks and take in new ones in the next Sprint to fill up a quota. We do KanBan in reality. So stop saying that."

I understand why he says this, but he doesn't seem to realize that this is how it is because him and everybody else on the team don't care. They just do work instead of dealing with impediments. They complain about the impediments, but don't do anything about them. And when I try to help they just shrug it off.

They used to give a damn, but over the past two years their willingness has declined to more or less rock bottom.

How can I make them see that joking around and wasting time during these meetings costs the company a lot of money?

  • 56
    Does your team still produces quality software? Or do the problems you mentioned influence their working results as well? – Doc Brown Aug 15 '17 at 10:01
  • 97
    Look at this from the perspective of the other people in the team - for three years they've been "doing Scrum" but not completing sprints and morale has been falling, so they want to stop doing it. Now a new person comes along and wants to force them to do it anyway. How would you feel? "They complain...but don't do anything" - you are having retrospectives where people don't say what they think, because they don't see that things might change, so what's the point? Listen to your team, meet them where they are and focus on the values of agile working practices. – jonrsharpe Aug 15 '17 at 10:05
  • 27
    As an aside, if the tasks are such that someone can say "I worked on this yesterday and I will be working on it again today" with any frequency then there's a good chance that you may need to take a closer look at the granularity of your tasks. Breaking up large tasks into smaller ones makes it easier to keep track of what's going on, makes progress visible and makes it easier to divide the work up over multiple people. – Cronax Aug 15 '17 at 11:22
  • 27
    Additionally, if work keeps overflowing into new sprints, then either your team is taking on too much in the sprint, or they don't actually have the power to decide what is or isn't going to be on their sprint backlog. They don't need control over the product backlog but they should have full control over the sprint backlog if there is ever to be any hope of being able to finish all the work in a sprint... – Cronax Aug 15 '17 at 11:27
  • 43
    if the retrospective result is 'stop doing scrum' then stop doing scrum – Ewan Aug 15 '17 at 15:34

14 Answers 14

192

You may have heard a lot of statistics about failed software projects and came to the conclusion that the failure is not of a technical nature. Technological problems can be solved via hundreds of technical solutions, but solving problems in your workplace atmosphere by using Scrum is not going to work.

My suggestion here is to completely stop looking at this as a technical issue. It's not about Scrum, it's not about daily standups, sprints, retrospectives or anything else like that. You need to get in touch with your team and find an effective way of working that satisfies them as well as you and your superiors.

If they think dailies are a bad idea, you should not tell them to do dailies and try to punch your reasoning into them. Think for yourself what it is that dailies offer to you. Check with your team whether they value those advantages as well. Find out why they do not share your understanding - as in understanding their point of view, not as in convincing them of anything. Then check whether dailies actually help your team, or if you can achieve more with some other mechanism. The funny thing about Scrum masters is that they are servants to their team - you may well serve them best by abolishing Scrum altogether.

In summary, stop focusing on Scrum and instead get back to the basics of agility. You may want to start right at the beginning with the agile manifesto: Value individuals and interactions over processes and tools.

  • 41
    Indeed. If the team wants to "stop doing Scrum" and feels they are "doing Kanban" anyway, why not do Kanban? I'm not necessarily saying you (Daniel Ziga) should do Kanban, but you certainly should consider it. That said, there should be specific things to do/not do in the retrospective. Nevertheless, starting the conversation with, "hey team, how should we rework our process?" may at least stimulate an interesting discussion and positions them to have interest and buy-in in whatever results from it (as long as it doesn't largely dismiss their concerns). – Derek Elkins Aug 15 '17 at 10:00
  • 98
    Remember also that Scrum is not a goal; it is a means. The goal is building quality software, with a committed team. If Scrum is not accomplishing the goal, get rid of it. – Erik Aug 15 '17 at 10:26
  • 24
    @Frank I hear you. Reflecting over myself and my point of view I will admit that I have been focusing too much on getting the team to work following Scrum guidelines rather than staying true to the agile manifesto. Thank you for your response. – user42401 Aug 15 '17 at 10:59
  • 15
    I agree with your answer and I think this blog post by Brian Knapp fits the issue perfectly: brianknapp.me/developers-dislike-agile “In fact, Scrum done “right” according to scrum isn’t agile at all. Scrum the way it is taught is a process designed not to change. That is a massive failure. It breaks the most important principle of agile.” – Michael Aug 15 '17 at 16:40
  • 3
    +1: Individuals and interactions over processes and tools. – Paul Wasilewski Aug 16 '17 at 13:21
65

In my experience, teams who are disillusioned need to start by having effective retrospectives. That's why in my opinion retrospectives are the only mandatory part of an agile process. Everything else is subject to change through the retrospectives.

In effective retrospectives, you don't just complain about your issues, you choose at least one of those issues and identify possible solutions to it, then try that solution over the next iteration. At the next retrospective, you talk about how that solution worked or didn't work, and make further adjustments if necessary, or pick another issue to work on.

When team members see they have the power to effect actual change in their process, they will become more willing to engage.

The retrospective process is why if you visit all the teams at a company that does agile well, they all do it somewhat differently. We have some teams that do Kanban, some that do XP, some that only do standups Monday Wednesday Friday.

If your team doesn't like how you deal with hangovers, brainstorm some different approaches. I have won over very reluctant developers just by consistently listening in retrospectives and trying solutions.

  • 19
    A key component of this is that the team needs to be empowered to make these kinds of changes. As long as there's a superior limiting what the team can and cannot change about their process, the agile process will be equally limited... – Cronax Aug 15 '17 at 11:25
  • 5
    @DanielZiga The way you sound, it looks like your team is past point of no return. After the years, people who care left and only people who remain are those that complain, but don't want to put effort into improving. Maybe you should think about dissolving the team and rebuilding it from scratch with different people? – Euphoric Aug 15 '17 at 11:53
  • 11
    @DanielZiga it's possible that experience has taught them that engaging doesn't help. Think about whether and how you could demonstrate to them that things will start changing - could you lead on something that doesn't need their action? – jonrsharpe Aug 15 '17 at 12:57
  • 1
    @jonrsharpe I definitely could. There are some low hanging fruits that I could take action on regarding product owners duties that would help the team when it comes to planning future sprints. – user42401 Aug 15 '17 at 13:01
  • 5
    "In my experience, teams who are disillusioned need to start by having effective retrospectives.": Sometimes group dynamics can be improved by "retrospectives" or other sorts of structured communication. On the other hand, some combination of team members just do not work, regardless whether you do retrospectives, daily stand ups, meetings or whatever. I think too many managers think that it is enough to introduce a new practice with a fancy name to allow people who cannot stand each other to work together. – Giorgio Aug 15 '17 at 14:26
47

Ok so let's start rough - big part of the problem is with you - You hear, but you don't listen. Your team is telling you clearly what the problems are. You need to address them instead of blaming your team.

Planning

To them, Planning is just a waste of time, because we just move overflow into the new Sprint and don't complete the work anyways, so why bother.

Exactly. If you consistently fail to allocate correct amount of time to tasks, and they are consistently underestimated, it has very negative effects:

  • Developers feel like they are constantly under pressure.
  • "I can't get anything done in time".
  • Since the process does not work, they rightfully see it as a waste of time.

Solution: Fix your estimations using combination of:

  • Story Points (as a combination of Time and Risk).
  • Do not allow tasks into a sprint that are > 55 SP
  • Comparative Estimations
  • Evidence Based Scheduling

As a base for this, you absolutely need to track time it actually took to finish previous tasks, this includes testing, writing documentation, writing tests, end user training, integration efforts, deployment. etc.

Once you have a total time for a given task, you can base expected time on those previous tasks.

Ask every member if the task given to them feels more complicated or easier than the selection of previous tasks, adjust number of allocated tasks based on that.

If you haven't used SP before, my advice is to start with 1h of real honest to god work = 5SP as a guideline. Keep in mind that in usual development environment, you'll get maybe 6 of those per day, so 30SP / day max. Never ever allow for a task that takes more than 2 days to get on the board. Ideally, in my experience, you should have 2 tasks per day.

If you don't do Planning correctly, rest of your Scrum activities will look like a waste of time (including Planning).

Retrospective

During Retrospective I can just feel that they want to say "Stop doing Scrum". One person does, but the others are silent and I have to deal with this every time.

Reminds me of Daily beatings will continue until morale improves! and two of the past jobs. If you don't remove impediments, then they are correct that this is a waste of time.

Again, listen to what people are actually saying. If the complaints raised during the retrospective are not addressed, why bother doing them at all?

So:

  • Consider Six Thinking Hats techniques to improve the communication.
  • Reduce the time spent on Retrospective, 30 mins maximum.
  • Ensure that complaints raised during the Retrospective are addressed before the next one.

Daily SCRUMs

Daily Scrum is again just a waste of time for them because none of them bothers to talk and plan the day. They just state "I worked on task X yesterday and will work on that again today." And most of the time they just joke around until I get more stern.

Sounds like you have two problems here: SCRUM meetings are too long, and your planning and task creation sucks.

Both can make sound like a scrum meeting is a waste of time.

For the SCRUM length:

  • Try 15 mins maximum.
  • Try everyone standing up.
  • Fixed formula:
    • What have you been doing yesterday.
    • What are you planning today.
    • What your team members (not you!) should know about the task, how it'll affect them.
  • Don't bother with impediments if you're not going to address them.

This is a second evidence that your planning impairs your situation - if you have nothing specific to report, that means usually the task is too big and all you could say was: I was working on it.

  • Break tasks down into the bullet points.
  • Ensure tasks are small enough to take less than a day. Ideally, IMO, task should last ~3h and be equivalent of around 13 SP, so you can do 2 per day in most conditions.

Dealing with the team

Today the person who's always against me told me to stop saying "They said this is what they committed to for this Sprint" because, in his words, "We never complete a Sprint. We just move in tasks and take in new ones in the next Sprint to fill up a quota. We do KanBan in reality. So stop saying that."

He's right. You are wrong. You are doing bastardized SCRUM and/or variation on Kanban. Not their fault at all.

I understand why he says this, but he doesn't seem to realize that this is how it is because him and everybody else on the team don't care.

I don't think you understand at all. They might be caring less than they used to before, however blaming them not only will not improve anything, it might just make a situation worse. If it was rock bottom, they might actually start digging.

They just do work instead of dealing with impediments.

And here I thought doing work is what their job was all about. I wonder who was supposed to be dealing with impediments.... oh right. A Scrum Master. It's your job. They tell you what's wrong. You fix it. Not the other way around.

This is probably why you have so much problems in the Retrospective.

How can I make them see that joking around and circle jerking during these meetings costs the company a lot of money?

Stop the useless meetings and they'll instead joke around watercooler. Also see the paragraph about beatings improving morale. If they are using humor as a defense mechanism, you have some serious problems sir!

Get in on a joke - as in work with your team, not against it. (Who the fuuuuuuck cares about the company's money? Are you a shareholder now?)

To summarize

Your bad planning is making other parts of SCRUM fail, and everyone who participates miserable. They see that nothing changes, nothing is addressed, and their complaints not heard.

Improve your planning, and you'll improve the flow and morale.

Do your job removing impediments and your team will progress faster. Ask them what they feel you should do to help them.

Most importantly: Listen to your people. They already told you (and me) what's the problem.

Good Luck!

  • 2
    You're welcome. Please try to not take this personally. I've made many similar mistakes back in a day :) It's also easier for me to see as I've been a part of a few failing SCRUM teams. Try to focus on improving the process and adressign concerns of your team, and you'll find the morale improves, then you get few successful sprints and it'll only get better from there. – Marcin Raczkowski Aug 15 '17 at 21:59
  • 2
    Sorry about that, I might have been a bit harsh, but sometimes 'suggestions' don't really reach people. Regarding adjustment: there's a saying 'Hard to be a prophet in your own country'. It's sometimes hard to see the problems from the inside, you often need some outside perspective. That's why they used to hire Scrum consultants, now you have Stack Overflow ;) Good luck, and if you have some follow up questions, let me know :) – Marcin Raczkowski Aug 15 '17 at 22:15
  • 5
    A+++++ would buy again And here I thought doing work is what their job was all about. I wonder who was suposed to be dealing with impediments.... oh right. A Scrum Master. It's your job. They tell you what's wrong. You fix it. Not the other way around. – jhocking Aug 16 '17 at 16:25
  • 1
    For example: To them, Planning is just a waste of time, because we just move overflow into the new Sprint and don't complete the work anyways, so why bother. This is afaik the exact opposite of how to do things. In your sprint planning you plan everything you are going to get done. If you don't get it all done, you don't throw everything into the next sprint. Your sprint failed. You have no deliverable for that sprint at all because you failed to manage it properly. Someone correct me if I'm wrong. – Shane Aug 17 '17 at 19:38
  • 2
    You are wrong. It's definitely not all-or-nothing. Think about it, 5 men team, everyone gets their tasks done, but one person fails one task, and now what? ... You don't ship anything? Nonsense. It's perfectly fine to create a build out of features that you've finished. This is however area where Scrum has problems IMO, keep in mind that Scrum was first introduced in Manufacturing environment, so it works best for tasks and ocmpanies with low variance (eg. Wordpress shop, that produces several websites for small businesses). That's why you have concepts like Spikes that reduce uncerteinity. – Marcin Raczkowski Aug 17 '17 at 20:40
10

One of major agile principle is to go back, and correct whatever is wrong. That doesn't only include code refactoring and bug fixes, but also fixing the development process.

So, why don't you make a meeting with your team, and see how can you improve development process? If that means, no scrum or standup meetings, then be it.

Also you are breaking one of principles in agile manifesto: "Individuals and interactions over processes and tools".

On the other hand, if your team thinks that iterative development is bad, then maybe you are doing it wrong. It doesn't matter if you do not finish everything you planed for one iteration - you can always move things to next iteration. That is also why you mark things as "has to contain", "nice to have", etc. As long as you provide new functionality, you are doing it fine.


Just a small rant: in my previous and current company we did and still do standup meetings. From my experience, they are massive waste of time, since every time they turn into 30+ minutes status report meetings, and to me provide little to no information. People talk about their problems, which honestly I do not care.
In my previous company, they were smart, recognized this problem with standups, and stopped them soon after people started complaining.


If you like to see a really good video about scrum, see "Robert C. Martin - The Land that Scrum Forgot".

  • 3
    @confusedandamused Actually, abandoning standups was the best thing we did. It is not only interruption, but also waste of time. Specially when people do not work on the same thing. I understand that you have to have meetings from time to time. – BЈовић Aug 15 '17 at 15:56
  • 4
    @Baldrickk Even short standups are interruption in work. When you have to stop something, you do not only loose 15 minutes (how long a meeting lasts), but you lose lots more, since you lost the concentration. – BЈовић Aug 15 '17 at 15:58
  • 4
    I've come to find that any break in concentration or flow really takes a lot of effort to get back to where you were mentally. – confusedandamused Aug 15 '17 at 16:04
  • 4
    @BЈовић a lack of interest in what your team is doing seems to indicate to me that you are not really a team. – Baldrickk Aug 16 '17 at 10:26
  • 3
    Instead of "what you did yesterday" it would be "what you did since the last standup". Anyway if your team works better without them then fine don't have them, but I do worry based on your complaints that your team isn't actually cohesive (eg. baldrickk's last comment). – jhocking Aug 16 '17 at 16:46
9

As I priority, I'd look at tasks which keep getting carried over. Not meeting targets is hugely demoralizing. Are you committing to too much? Are there fatlogs that should be broken down? Are there bottlenecks outside your control? Do you have a clear definition of "done"? Are the requirements clear? Are the hours per developer reasonable (i.e. takes into account admin, standups, planning, retrospectives, keyboard breaks, non-project work).

Next, ditch whatever isn't working. Process without value is just a time thief. Standups can consume vast amounts of time if it isn't focused and doesn't provide value to the team. The hours might be better spent elsewhere. Maybe also consider splitting the team up if it is too big.

Try to get a handle on what is demotivating the team. Have retrospectives and more importantly, act on the output. It is equally important to celebrate successes as well as looking at failures.

Finally, you may want to assess the approaches of scrum masters who have gone before who may have damaged the brand so to speak. I've worked under a toxic scrum master before where every problem that was raised got added to your workload whether you knew about it or not. End result: problems got ignored and everyone worked on their own little area with very little teamwork.

5

Getting your team to close your sprint effectively (like at least close 80% of stories) sprint over sprint is in my opinion the single most important thing you can do. If your team is consistently missing, then that's a clear indication that you need to adjust your estimates.

The team should be receptive to this, though it can be very hard to get developers to be more realistic about estimates - I worked on a team that didn't close a sprint for a year (consistently closing less than 50% of the sprint), always under estimated and in every planning/retrospective I was a lone voice telling them your estimates suck, you're being foolishly over-confident, stop making excuses for what prevented you from making the estimate and instead adjust the estimate to reflect reality (perhaps more diplomatically than that but that was the basic sentiment) - When you're in that position, I would fully agree with the curmudgeon on your team who says the process is a waste of time because you are in fact doing KonBon, regardless of what you call it. At a certain point, his opinion becomes validated by the circumstances. It's hard to overcome that inertia but if you can't do that then I don't think the team will ever be very successful.

At some point you have to reset things, you have to get the team to drastically over compensate on their estimates just to get the system in motion. Once a team begins closing stories consistently, they should realize that the Agile process is mainly common sense and failing to materialize it in some fashion is harmful to your productivity. But so long as the 'commitment' and 'sprint goals' aren't taken seriously, which happens when they aren't achieved consistently, then the whole thing is a sham and becomes a drain on the teams productivity.

Getting people to buy in on a significantly different sprint (in terms of estimates, planning, the commitment ect) is difficult, on that team I eventually accomplished that due to two factors. One was just collecting the data from JIRA and saying "there is no excuse for this, the numbers are way off, they're always off in one direction, we need to correct it, I don't want excuses in retro, I want the numbers to add up" - and the other was pressure from higher up in management which I eventually explained to them like... "The point of this process is to make our development timeline predictable. If we complete a constant amount of work every sprint that's fine, independent of that, our board needs to accurately reflect what we do get done. Management is more aware of our success relative to the commitment than it is to our actual output, for your own sake, make the projection line up with the output so it looks like you're getting your work done rather than spending half of every sprint doing nothing. The further removed people are from this time, the more they just see you failing, the excuses you make in retro aren't even something in their purview, they just see you failing."

Eventually our team got traction and things started going a lot smoother and low and behold, we even started to have higher output once the process actually started working. So tl;dr - do whatever is necessary to start closing sprints with a relatively high degree of success. If you're not doing that the curmudgeon on your team will continue to have his resistance to Scrum validated by the results and ultimately will be right that your process is in fact just a sham and waste of everyones time.

4

As a Scrum Master you coach and guide the team to become more productive. The Scrum framework is a powerful tool to get there, but the Scrum framework absolutely must not ever become the goal by itself - otherwise you're doing Cargo Cult.

It seems you've been doing Cargo Cult for 3 years now and people realized that's a horrible project management methodology. The good news is you've got smart people, they got it right. Unfortunately, some people in your company are calling it Scrum, but again you've got smart people, they even told you what the team's doing isn't called Scrum.

Planning is just a waste of time, because we just move overflow into the new Sprint and don't complete the work anyways, so why bother.

Exactly. Why bother? You need to find an answer, or rather you need to change the planning and the sprint itself so there is a point to planning. Either that, or stop wasting everybody's time with a pointless Sprint Planning. You may want to ask the company to send you on a Scrum Master training, because running a great Sprint Planning is not trivial.

During Retrospective [...] the others are silent and I have to deal with this every time.

If you're dealing with the same issue every Retrospective, an people don't even bother (anymore?) to speak up during the Retrospective, that's just a waste of time. Unless you or the team can somehow address the issues raised in the Retrospective, the meeting is just a demoralizing the team. Issues raised in the Retrospective must be addressed, and there should be progress by the next Retrospective.

Daily Scrum is again just a waste of time for them because none of them bothers to talk and plan the day. They just state "I worked on task X yesterday and will work on that again today."

Indeed, why bother wasting everybody's time if they just work on the same tasks multiple days? They are absolutely correct, that Daily Standup is indeed pointless. The Standup facilitates close collaboration on many tasks which can each be completed in half a day or less. If your tasks can't be broken down that way (due to broken Sprint Planning, or because your tasks actually don't fit well with Scrum), there's not much of a point to holding the 5-minute Daily Standup meeting (it is no longer than 5 minutes, right?).

"We never complete a Sprint. We just move in tasks and take in new ones in the next Sprint to fill up a quota. We do KanBan in reality. So stop saying that."

I understand why he says this, but he doesn't seem to realize that this is how it is because him and everybody else on the team don't care.

No, you absolutely do not understand why he says this. You got the root cause of the impediment - which you need to resolve - wrong. They don't care because the team's project management practices suck. Caring about doing Cargo Cult and doing Cargo Cult harder doesn't stop it from being Cargo Cult, one of the worst project management methodologies in existence (in your defense: also the most widely used).


What can you do about this?

  1. Listen to their concerns. Again, you're blessed in that you've got smart people.

  2. Help them resolve the impediments.

And that's it, really. You'll need to experiment with how to change Sprint Planning, Daily Scrum and Retrospectives to make them valuable to the team - even if you wanted to drop the Scrum label, you still have these 3 meetings with similar frequency and similar purpose in every other project management methodology out there. As for how you're going to experiment (frequency, content, who hosts the meeting, time, duration, etc), that's surprisingly easy: Ask the team. Don't force your ideas on them, if anything you should let them to force their ideas on you (assuming they can agree on some).

If you're afraid you'll lose control, set some boundaries beforehand, e.g:

  • The labels of the meetings stay the same.
  • The meetings still take place and frequency of the meetings cannot change by more than a factor of 2.
  • You're currently experimenting, so any change only lasts for 2 sprints, after which you revert to the old pattern (best give the time in weeks to avoid ambiguity when they want to double the sprint duration).
3

I think everyone is quoting the same line from the Agile Manifesto. I will do the same: "Individuals and interactions over processes and tools."

If you as the SCRUM master want then to use SCRUM to do the job, you must approach them as one individual interacting with another. Start brainstorming how to make the process better. Maybe you can convince them to like SCRUM. Maybe they can convince you to use a different process. Let's find out!

It sounds like the team already recognizes that the current system is not doing the job. Can you encourage them to believe it can do the job? You mention a few examples. If you're overfilling the Sprint so that it always leaks over... stop. It's your SCRUM team. Help them stop over-committing. Push back on management to get some breathing room. Use SCRUM for what it's good for. Use it to present the data to management that they are pushing hard enough that they are losing the value from their process. If management wants SCRUM as a process, get them to help build the space and energy you need to fix it. As SCRUM master, your job is to solve problems so that the team can be productive.

Another useful approach can be to spawn a new process within the old. Keep running the SCRUM in the same useless way, but cordon off a small part of the schedule and say "in this part of our schedule, we're going to figure out how to use the tools properly." Don't overcommit there. Use your metrics. Focus on all your meetings there. Just the remaining part of your "SCRUM" project as a shield to keep management happy while you and your team "[uncover] better ways of developing software by doing it and helping others do it." Over time, you'll want to put more and more of your valued tasks in this bucket, and the old bucket will slowly die. Soon, you have a vibrant software development environment and no one is the wiser.

Or mix and match them. I worked on a program which was anti-scrum. The clients wanted to be able to add new tasks at any point during the process and have us act on them immediately. (This was actually a sane request: their work was highly volatile and they often needed rapid support... it's what we were paid for). Of course, we had to figure out how to deal with their "why isn't X done when you promised it in the sprint" issues. Our solution was actually to build a two step process. Long term tasks were put into SCRUM for proper prioritization. The short term tasks were put in a homebrewed process which focused on tight interaction between client and developer. It was understood that the clients were welcome to push on us using this short term process, but that they understood that doing so pushed on the Sprint's timeline, and they were forbidden from adding requests without simultaneously hearing and addressing the scheduling issues they caused. Result? It worked. Most tasks were put in the SCRUM process, like they should be, and the emergencies interacted seamlessly with them. The attitude was "If you want to be a customer, stand in line for a SCRUM story. If you want to be a partner, feel free to come down and work with us on the day-to-day level and make this product work!"

3

I say this because I truly know. You have a problem in upper management with overscheduling, unable to set priorities, and a willingness to add more items but not push the release dates back.

I used to say that there is no methodology that can function like this, but now that I've seen Kanban I say it can, but only because Kanban doesn't have to care. It continues to function when overcommitted. It's not going to bring results any faster but the backup in the queues is not allowed to be laid at any individual and so the management problem rests with management. The feedback reports show overload, which is correct.

  • 2
    98% this. But the Scrum Master and Development Team need to push back and set priorities, too. They also need to stop auto-carrying work forward. – CodeGnome Aug 18 '17 at 0:41
2

Because of this change in Scrum Masters and their way of running the show

Oh well, this may be your problem. A Scrum master is not there to run a show, he is not a project leader. He is there to make sure all stakeholders are communicating and the operation is transparent.

I am wondering where the team is coming from. Could it be they were more or less autonomous before Scrum (including the inevitable Scrum master) was dropped upon them? Why was Scrum introduced in the first place? What was it supposed to solve?

Scrum is supposed to provide guidance and your team is making it clear they do not experience it as helpful in any way. They don't care for guidance, they consider it an inappropriate waste of time. Apparently at least one decision maker thinks they need to be guided anyway. Who? Why? Do they have a point?

1

This is a problem not limited to software.

In any work environment, there will be different people with different personalities and abilities. Even if Scrum was a perfect method, there would still be people against it due to their personalities and abilities.

Developers handle difficult tasks in a rational way. To be able to do this, each developer will have his way to handle such things which may show up as aversion to things like Scrum. If all the developers were trained from scratch in exactly the same way then it may be a lot easier to use one pattern, but otherwise adaption on the developer side or management side is needed.

In addition, independent thinkers(developers and other specialists) often do not like being told how to do things because that is their job and it is easy for clashes in opinion to happen. Scrum can seem like some pointless ritual to a logical thinker who would usually analyze and act accordingly to each issue at hand.

The below seems to suggest where the problem is but not what it is. There is definitely more than this. I can only assume(out of experience) that the developers tried but was prevented. I have seen it many times where developers want to fix something but something systematic(management, company policy, etc.) makes it near impossible so they give up. Do they really not care or do they not care only about doing something that they believe will not help(possibly out of experience).

I understand why he says this, but he doesn't seem to realize that this is how it is because him and everybody else on the team don't care. They just do work instead of dealing with impediments. They complain about the impediments, but don't do anything about them. And when I try to help they just shrug it off.

They used to give a damn, but over the past two years their willingness has declined to more or less rock bottom.

How can I make them see that joking around and circle jerking during these meetings costs the company a lot of money?

If something is being forced onto other people, it is up to the people forcing the method to convince them of the benefits. Although, I don't really believe in forcing people to do things, I suggest like in any situation, listen to everyone and develop a method that works for the current environment.

0

Scrum is not without its weaknesses. I can speak for myself of course, but I think developers hate it for good reason. It is my honest opinion that it must not be attempted.

To understand why, read what every scrum master should know about scrum. It is not written by me, yet everything there is representative of my experience, which I can only sum up as sheer terror.

In my case, I especially suffered under point 5. Basically, scrum treated me as a child and a loser. Now, I am a resourceful co-developer helping my colleagues … no wonder what I would prefer!

I have a new (non-scrum) boss now, that just walks around and talks to people, and I'm so so thankful for that! Part of why this works is that we also have a chat room (we use mattermost) for inter-developer communication. If anyone is having an agenda, we take it there. Meetings are only for ad-hoc developer discussions, not for imposing artificial daily deadlines on oneself.

  • 1
    To explain my downvote: You do have a point. But what you and the article link is not what I understand to be Scrum at all, not even close, that's why I downvoted (I'm a former Scrum Master (even certified, as if that matters)). It's plain bad project management, with a Scrum label. You can have bad project management with any label. You do have a point because what the OP describes also isn't a functional Scrum implementation. – Peter Aug 18 '17 at 10:47
  • 1
    @Peter to explain my upvote: If a process is potentially good but most of the time intelligent and well-meaning people screw it up then it is not a good process. – Jared Smith Aug 18 '17 at 13:44
  • The attached article is passionately written, I'll give you that. Nevermind that it describes conditions that are NOT "agile", but are actually antithetical to the objectives of agile. Much of what it states is not even Scrum, but misunderstandings or purposeful misrepresentations of Scrum. And it exhibits a profoundly arrogant perspective that business should be run by engineers, rather than being focused on the business. The objective of business is to sell product. The argument that engineers are somehow as good at this as business leaders is insanely arrogant. – Curtis Reed Feb 19 '18 at 21:23
0

You've gotten a lot of excellent answers. Here's a few more points that might be helpful:

Changing Methodology Is Hard

It's a huge challenge in a workspace, because you're working under the inertia of "this is how we do things", and against the pressure of deadlines and business needs.

You're quite correct to conclude that your team needs to spend more time on planning, not less; that planning is something your time currently is not great at, and needs to improve. The problem is, you don't get there simply by dictating new rules. New rules are a new burden before they become a big help. And if they don't provide great value immediately, you're going to get avoidance rather than cooperation.

I highly recommend Roy Osherove on this topic. He's got a brief summary of how to plan and effect change at your company, and he goes into the topic at much greater depth in this video.

Osherove's basic observation is that all the following challenges need to be met:

Personal Motivation: Why should someone care to behave a specific way?
Personal Ability: Can they literally do it?
Social Motivation: Is there peer pressure push for this behavior?
Social Ability: Do people around me support my behavior and help me out with it when I need help?
Structural Motivation: Are there rewards\punishments for good\bad behavior?
Structural Ability: Does the physical environment support this behavior?

You Need To Learn To Break Tasks Down

Your team feels that "I worked on task X yesterday and will work on that again today," and they seem to be right, in the sense that tasks keep being pushed back a week.

What's really helpful here is learning how to break tasks down into small components. What you're looking for is the answer to the question "OK, you're working on task X, but what specifically in task X are you working on today?"

Some answers might be:

  • I'm learning this class of legacy code.
  • I'm fixing a bug, whose symptoms are (SYMPTOMS).
    • If this is some ongoing bug that's taking a while: "Today what I'm going to try is... (PLAN)"
  • I need to change this interface.
  • I'm writing tests.
  • I'm integrating untested code.

... and so on, and so forth. Being able to observe what you can actually get done in a day, or in a week, is one of Agile's great benefits. But that means you actually need to look at resolution of individual days, not some monolithic Task X that will Be Ready Whenever It's Ready.

Done vs. Delivered

One common problem (with Agile, and workplace planning in general) is that deadlines tend to come from management, not from the developers. That deadline might be divorced from the actual work to be done -- and particularly, it's likely to want things delivered as quickly as possible.

The problem is, "delivered ASAP" is a very chaotic process. It encourages cutting corners; coding "quick and dirty"; ignoring guidelines; not cleaning up after yourself. It encourages a mentality of "try it, see if it works. if yes, deliver. if no, try something else" -- and, phrased like that, you can see why nobody can predict how long anything will take.

Whereas if you are working methodically, if you're rigorous about planning and testing and so on, then you've set up a bunch of signposts and safety nets. It might take longer -- you're devoting a lot of time to things that aren't furthering immediate delivery, and, you might just not be very good at this kind of workflow yet -- but it will be much less volatile.

So one thing to ask yourself is: Is it the developers setting the sprint goals, according to the needs and necessities they actually see? Or is it management setting the deadlines, leaving developers to try and slot their commitments into a sprint-like schedule?

If developers aren't being afforded the time to plan things out, or work according to a reliable plan, then it's no wonder that they can't make helpful estimates. :)

-6

This might be an unpopular opinion, but you might not be able to do anything about it.

I can imagine that over the years of team's existence and flux of leaders, people who were truly dissatisfied with the team, left. What you have are remains of people who might complain, but aren't interested in actually putting effort into improving the situation. They just want to spend their 8 hours of hacking code, not interrupted by anyone and just go home at end of the day. What you have here seems to be serious motivation problem. And it is not job of scrum master to solve that problem. It is problem of whoever is paying those people.

If this truly is the case, then only real option is getting rid of the current team and start over from scratch. Maybe leave one or two people who you think are best in the team and either fire or move the rest to different teams. You should at least discuss this possibility with your superiors.

  • 13
    Saying that people who get their job done but don't willingly conform to a business process that is nothing but an impediment to doing said job should be fired is about as wrong as wrong can possibly be. – Jared Smith Aug 15 '17 at 14:02
  • 5
    I've seen such things. Getting rid of the team won't help. Getting rid of the manager might. – Joshua Aug 16 '17 at 20:21

protected by gnat Aug 16 '17 at 11:02

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?