112

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?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • 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
  • 4
    ... and another question: you wrote *"the company appointed me Scrum Master"* - sounds to me like your superiors want Scrum and nothing else? – Doc Brown Aug 15 '17 at 10:42
  • 6
    @jonrsharpe I agree. I admit that I have focused too much on getting them to work following Scrum guidelines rather than listening to them. I will make an effort to do so. Thank you. –  Aug 15 '17 at 11:01
  • @DocBrown That is true, my superiors want Scrum because that is what they have, for a lack of a better word, been "sold". I have together with the other Scrum Masters focused a lot on getting Scrum implemented in each our teams, rather than staying true to the agile manifesto and actually listen to and learn from our team and help adapting them into a cycle they are comfortable with. –  Aug 15 '17 at 11:06
  • 11
    @DanielZiga: I think you are on the right track. Maybe it helps if you tell your team "let us adapt our process so it works better for us, but I have to call it literally 'Scrum' when I talk to our superiors because that is what they expect to hear". – Doc Brown Aug 15 '17 at 11:19
  • 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
  • 1
    @Cronax We do this already during our plannings. I get the sense that it's not the size of the tasks but rather the persons understanding of what needs to be shared and discussed that pulls down in this regard. –  Aug 15 '17 at 11:28
  • 5
    @DanielZiga In that case, why not ask them what they think the goal of the daily stand-up is? Often, people will do a better job during stand-ups if they understand *why* it's important to tell people what they're doing and what problems they're running into. If they think it's just a daily ritual where they have to justify their actions of the previous day then you're never going to get them motivated. – Cronax Aug 15 '17 at 11:34
  • 2
    @DanielZiga the thing I'm missing in your question is what is the biggest problem *of the team* at the moment? – Kos Aug 15 '17 at 12:08
  • 7
    "[...] I admit that I have focused too much on getting them to work following Scrum guidelines" - Keep in mind that one of the most important guidelines of Scrum, and any other Agile process, is that you should focus on your team instead of the process. – T. Sar Aug 15 '17 at 12:23
  • 1
    I marked @Frank's answer as it best sums up what most of you suggest. I will take all your very good feedback and suggestions to heart and do my best to try them out and see if me and my team improve our understanding of agile and way of working. –  Aug 15 '17 at 13:22
  • 9
    @DanielZiga I'm astounded by the phrase "How can I make them see that joking around and circle jerking during these meetings costs the company a lot of money?" Not because you're wrong but because this has never had any relevance to me as a developer. Most developers I know of are driven by much more intrinsic motivation than that. Do you think your people would cheer if you said "Thanks to following scrum principles closely we've raised our quarterly profits by 4.2%"? I was also expecting someone to have recommended it already; read Peopleware. – Robzor Aug 15 '17 at 13:32
  • 1
    @Robzor Thanks for the book suggestion. I get where you come from with this comment. In the end it brings no value to anyone wasting time. So I would rather have them tell me "we don't want to do this. it's not working for us" than have me facilitate these events to then have them not take it seriously - if you can feel me? The problem is they don't say anything and just do as they are told, even though they know they can actually change things. –  Aug 15 '17 at 13:49
  • 44
    if the retrospective result is 'stop doing scrum' then stop doing scrum – Ewan Aug 15 '17 at 15:34
  • 1
    @Ewan We actually did it once (before I was appointed Scrum Master) but our superiors implored us to give it an extra chance. However I'm considering it at this point. Everyone here has given some valid and good feedback that I would like to try out first before I 100% get behind that decision and follow through. –  Aug 15 '17 at 15:59
  • 2
    i guess what getting at is it doesn't really matter what you want to do. The team is supposed to be empowered to change its working practices – Ewan Aug 15 '17 at 16:15
  • 11
    @DanielZiga The value in joking around is in stress reduction, teambuilding, etc. It helps to keep it a nice place to work, and probably boosts long-term productivity by preventing them from hating their job as much as they otherwise would. – Izkata Aug 15 '17 at 18:08
  • 4
    This team is burned out on the continuous flow of change to the process over the time period since Scrum was forced onto them. They probably will not willingly accept your Scrum direction now, nor do I really blame them. Revert to Kanban if they like it, and just tell management that you're doing "almost Scrum". – Graham Aug 15 '17 at 20:46
  • 2
    Nowhere in your question do I say support for your final words *costs the company a lot of money*. You seem to want to use that as an argument (at least with us), but then you'd better back that up with facts. This ties in with DocBrown's comment *Does your team still produce quality software?*, to which I see no answer from you (but that comment may have been deleted). – Jan Doggen Aug 16 '17 at 12:16
  • 2
    Why not do Kanban? `Individuals and interactions over processes and tools`. If they'd prefer a Kanban approach then *do it*. – Wayne Werner Aug 16 '17 at 12:23
  • 2
    @Graham OP could probably just tell management that they *are* doing Scrum and nobody would care, or even know the difference. Especially if they said something like, "We're doing Agile development" – Wayne Werner Aug 16 '17 at 12:25
  • 1
    Deadlines are arbitrary and stressful. Scrum produces more deadlines. QED – Bradley Thomas Aug 17 '17 at 21:35
  • 1
    ...Could it be that you're working on bullshit projects that just aren't that interesting? Hmmm? – theDoctor Aug 18 '17 at 06:46
  • Obligatory Dilbert: http://dilbert.com/strip/2017-02-06 – Andrea Lazzarotto Aug 18 '17 at 23:11
  • 1
    @DanielZiga: million-dollar question: do your management want Scrum because it will actually deliver higher productivity with this team's culture, or just because are they technically clueless buzzword-jumpers? I suspect the latter. Challenge your team to define their preferred methodology for being managed, reporting progress, frequency, duration, purpose and format of meetings. Then bring recommendations to management. If they won't improve anything, then you have no influence. – smci Aug 20 '17 at 21:47

14 Answers14

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Frank
  • 14,407
  • 3
  • 41
  • 66
  • 42
    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 left SE 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
  • @DerekElkins I will definitely try out your suggestion about asking them how we should rework our process. –  Aug 15 '17 at 10:57
  • 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. –  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: http://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
  • Frankly, I would be interested in why the OP accepted this answer (quite quickly, too). While it is no wrong in any way, I (if I were the OP) would not see any concrete help. For example, compare the next answer which mentions the importance of retrospectives, and concrete advice on what to do in a retrospective. How about adding something along those lines to this accepted answer? – AnoE Aug 18 '17 at 14:32
  • Sometimes morning scrum is "enforced" by manager, director (the person responsible for the delivery), and thus scrum masters are "forced" to have a morning scrum no matter what. This is a way managers (and directors) use the meeting to acquire information from the team. Before you hurry to judge, I know that the morning scrums are for the team, and the team only, but in reality, often managers use it because they're too afraid of letting go of the team's control, and have the feeling that they still control delivery. This holds for other meetings as well, in the name of "we do scrum". – dqm Nov 12 '17 at 14:21
  • It was very informative to read the article by Brian Knapp. It's misguided, full of misconceptions and erroneous conclusions, but it is also clarifying. Because if I had such a poor understanding of Agile, and the various frameworks in agile, I might say I hate it too. – Curtis Reed Feb 19 '18 at 20:56
66

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.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • 20
    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
  • What I have observed during our retrospectives is that even though I give them every opportunity to choose an issue and talk about possible solutions, most of them remain silent. And when we finally discuss things and make some action plans, those plans are rarely acted upon. At this point I'm unsure whether it is my lack of drive and follow-up that makes them neglect this or if it is them holding back because something at the workplace doesn't enable/allow them to do these things. –  Aug 15 '17 at 11:34
  • 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. –  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
  • 1
    @Giorgio, emphasis on the *effective*. That means centered on the needs of the team, not just on holding a "structured" meeting with a specific name. The structure and format of the retrospective is as much up for change as the rest of the process. The important thing is you regularly solicit feedback, and you **actually make real changes** based on that feedback. – Karl Bielefeldt Aug 15 '17 at 14:58
  • 1
    @KarlBielefeldt: I agree with you that retrospectives can be a good tool to identify problems, but then the team has to solve them and it is not always possible. Sometimes the only possible change is to reorganize teams so that they are composed by people who are more compatible with each other. Unfortunately, I have experienced teams in which retrospectives reveal problems that are afterwards ... just ignored. So retrospectives are just a ritual that gives the illusion that something is being done. – Giorgio Aug 15 '17 at 15:18
  • 1
    @DanielZiga-So most of the people remain silent despite giving every opportunity to talk. You do realize that you are working with software people? While there are certainly exceptions most software people prefer not to talk all that much. That's why they chose a career where they perceived they'd mostly get to deal with machines and not people. Instead of asking them to "talk" maybe it would be better for them to "write" their suggestions. Some people don't like to be critical, so maybe ask them to compile a list of lessons learned and then you can infer from that what might need to change. – Dunk Aug 15 '17 at 19:27
  • 1
    IME, it is the people that like to talk and dominate meetings that come up with the worst ideas but somehow seem to convince the "decision makers" that's the way to go while everyone else cringes as one stupid idea after another is imposed on them. Once you've had enough of that then you learn to speak up, but for many people that takes quite a few years and the right environment to get there. – Dunk Aug 15 '17 at 19:29
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!

Pang
  • 313
  • 4
  • 7
Marcin Raczkowski
  • 754
  • 4
  • 6
  • 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
  • It's a little hard not to take personally ;-) But I get what you're saying. I have been part of this team for 3 years now (working agile for 6), and I feel the same way as they do on most areas. It's my first time in the role as Scrum Master, so it's a steap learning curve to figure out how to deal with all of this. –  Aug 15 '17 at 22:08
  • 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 a useful practical answer. OP is doing basically everything about scrum wrong. When one member says this, they are ignored and nothing changes -- basically you are telling them to f-off. Then other team members see that and don't bother to volunteer anything more. Then you wonder why morale is low and why the process isn't getting better? – Shane Aug 17 '17 at 19:34
  • 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
  • Then you have _astounding_ successes - someone finds an open source library that does exactly what you allocated 2 weeks sprint for, and what? 2 week vacations? - I wish! To deal with sprint failure you generally have following options: **a)** Adjust items in sprint (replanning). **b)** End Sprint and restart. But your comment really warrants a full question/answer to explain properly :) – Marcin Raczkowski Aug 17 '17 at 20:47
  • 1
    "Who the ... cares about the company's money?" I do, and I'm not a shareholder. But in some respects, it's because I care about *me*. Time wasted on poor development decisions is usually time that I have to spend redoing stuff. It's clients who are unhappy with me just as much as the rest of my team. And to some degree, it's my job. =x – jpmc26 Aug 18 '17 at 03:07
  • @jpmc26 You should really read a whole line ... and get in on a joke. – Marcin Raczkowski Aug 18 '17 at 05:06
  • 15 minutes is too long. What value does it add? Everytime i've done SCRUM the standups have been the most pointless waste of time ever. People just say 99% of the time 'working on x yesterday, same today'. – sashang Aug 18 '17 at 05:45
  • @sashang why even bother commenting if you've obviously not read my whole post? – Marcin Raczkowski Aug 18 '17 at 13:35
  • One handy thing my team did during standups was a quick triage of bugs that appeared since the previous day. That helped improve our response times tremendously. Easy things could be fixed right that day, critical brought to attention of PM, rest queued for the next full triage. The team would congregate around a big screen which had a display of the status all our builds and tests, progress status of the sprint, and important monitoring charts for all our systems. – Dan Mašek Aug 18 '17 at 17:03
  • I gotta say that if that's your idea of a joke, I can understand why people might have trouble getting in on it. =p – jpmc26 Aug 20 '17 at 19:07
  • @Shane: but the team feels they did work pretty effectively, after all they got quite a lot done. Just not exactly what was in the sprint planning, which they already feel is useless. What is your goal when telling them they failed the entire sprint? – RemcoGerlich Aug 20 '17 at 19:35
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".

BЈовић
  • 13,981
  • 8
  • 61
  • 81
  • > If that means, no scrum or standup meetings, then be it. – confusedandamused Aug 15 '17 at 15:30
  • Well I messed up my last comment Updated below....`If that means, no scrum or standup meetings, then be it.` I feel that daily standups and meeting are a _very_ hard thing for managers or a team to give up. – confusedandamused Aug 15 '17 at 15:37
  • 2
    The standup meetings should be short, and the Scrum master should enforce this. If they go on, then they do become a waste of time. If someone does have a problem, instead of letting them discuss it there and then, suggest that they report that there is an issue, and then have them shelve it until after the meeting, at which point the appropriate team members can work on resolving it. Raise it but don't try to solve it in the standup. It's to keep the team appraised of the state of things. – Baldrickk Aug 15 '17 at 15:41
  • 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
  • I wish my team operated in this fashion. I have had 4-5 separate standup times in the last two months...It is now moved into a more permanent time slot, but still it seems wasteful. – confusedandamused Aug 15 '17 at 15:58
  • 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
  • 2
    @BЈовић _Specially when people do not work on the same thing_ That's kind of the point though, isn't it? A team should be working on an area of the code-base, even if not on the same tasks. The idea is to keep people in the loop with changes that could affect their tasks, or keep them up to date if they need to help out their teammates etc. If it really interrups your work, choose a time that suits you. If you work a standard 9-5, then have it at 09:00 before anyone gets down to work. Maybe have it at 11:45, people will keep it short and you have a break from work anyway at that time. – Baldrickk Aug 16 '17 at 09:47
  • @Baldrickk I start to work at 7:00, one of colleagues at 8:30, other 2 at 9:30, and our remote team has 3:30 hours difference. So when do we do it that it doesn't interrupt someone? Doing every day is just too much. And as I said, I do not really care what my colleagues are doing, since I have my own problems. – BЈовић Aug 16 '17 at 10:09
  • 2
    @BЈовић the idea is that you find a time that suits you. A remote team sounds like a seperate team - maybe they should be holding their own standups, with a SoS done to update the teams on anything that will affect them. I suggested before lunch as a (usually) common time for people to take a break anyway, regardless of their start time. – Baldrickk Aug 16 '17 at 10:25
  • 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
  • @Baldrickk In standup meetings, you should tell what you did yesterday, and what you plan to do today. Makes no sense to have them at 11:45, because half day already passed. Regarding lack of interest - it is because of deadlines. If I am pushed to finish something, I don't want to be interrupted and don't want to hear what others are doing. – BЈовић Aug 16 '17 at 11:23
  • 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
  • Thinking more, what's pointless isn't so much the standups as the including people who aren't working on the same project; I suppose it's possible that your company is structured such that every single developer is working on a different unrelated project, in which case yeah you shouldn't be wasting everyone's time. – jhocking Aug 16 '17 at 16:49
  • @jhocking No, we work on one product, but different things. I do programming in c++, other mainitaining yocto, 3rd testing, 4th QML, etc. Unrelated in such way – BЈовић Aug 17 '17 at 06:15
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.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
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.

evanmcdonnal
  • 179
  • 4
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).
Peter
  • 3,718
  • 1
  • 12
  • 20
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!"

Cort Ammon
  • 10,840
  • 3
  • 23
  • 32
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.

Joshua
  • 1,438
  • 11
  • 11
  • 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 00: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?

Martin Maat
  • 18,218
  • 3
  • 30
  • 57
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.

Damien Golding
  • 141
  • 4
1

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.

user2394284
  • 127
  • 3
  • 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
  • 2
    @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
  • 1
    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. :)

Standback
  • 1,310
  • 2
  • 9
  • 14
-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.

Euphoric
  • 36,735
  • 6
  • 78
  • 110
  • 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