> The biggest gripe I have with daily stand-ups and I am sure there are others (including the author) who agree with me on this: they often run over and turn into meetings/debates.
In my last job we rotated scrummasters every iteration. Daily meetings were not starting on time and running long.
My first turn I closed the door and said: "Ok, I want to keep this under 5 minutes so lets go around quickly". A couple of the guys who usually showed up late came in when we were almost done. I completed the meeting with a friendly reminder the meeting starts at the agreed time, sharp. After that, everybody showed up on time and meetings ran less than 5 minutes average.
> More often than most, the question of what did you do yesterday usually results in: I don't remember. And you know what, if you have a lot on your plate, that is a fair statement to make.
Someone having "a lot on their plate" is a symptom of poor iteration planning: no team member should be working in more than one thing at a time. Also, tasks should be sized between half a day to 2 days of work (around 3 to 12 ideal hours)
If your scrum board shows a bunch of small tasks less than half-day work, then your team went too far micromanaging and should combine them into single tasks that take no less than half a day to complete.
> no team member should be working in more than one thing at a time
How do you do that? My company has many small products/projects. Can't staff them all full time, and can't schedule them to be independent (project A is worked on Jan 1-15, B on 16-31, etc). It is inevitable that you will be working part time on several things at once.
> If your scrum board shows a bunch of small tasks less than half-day work
Some tasks are half day. Get Windows installed on this server. And so on. Oh, you can make a task "get windows installed on the server, and update the FooBar documentation" but that is just artificial.
Let me clarify: no team member should be working more than ONE TASK at a time.
You can manage multiple small projects just fine this way. I just left a place where the team was doing just that.
> Not everything fits into scrum.
You are absolutely right. SCRUM is great for processes which are empirical in nature (same inputs, different results).
Software development is empirical: give 2 teams of devs the same requirements and deadline, both teams might return code that essentially does the same but the code bases will be different.
IT support stuff such as installing Windows is better managed with a defined process (same inputs, identical output every time).
In my experience rarely is Scrum/Agile implemented into an organisation in its pure and intended form. I think companies start out with the best intentions, but the nature of modern software/web development is things are sometimes difficult to plan for. In the beginning it can be great, but once again, things start to derail. Sometimes companies want to implement process, but they realise the amount of organisational work that goes into adhering to Scrum & Agile, they get half of the way there and half-implement it.
If a debilitating bug is preventing your users from using your app, you're going to make the team go out of their way to fix it (even if it was not planned). If "higher ups" want to implement a last minute feature because an investor meeting is coming up and a competitor just launched said feature, no manager is going to firmly say "no, you can't have it unless we plan for it" to the very person(s) that pay their salary. Sprint planning meetings and poker are great for estimating new features most definitely, but they fail to really and realistically take into account that sometimes SHTF and no amount of planning can accommodate for that.
In the real world developers don't get to go into sprint planning meetings, get a set amount of work and no that's all they'll be working on. I mean, that's how Scrum is supposed to work, right? But how many developers can honestly say it stays that way? Scrum/Agile does not stop people going outside of the framework (and in my experience there are always people that do) and assigning you work or asking you to do what they think are "small tweaks" and "quick changes" which usually blow out into one or two day tasks that take you out of the sprint workflow, then the burndown graphs start looking bad and your manager starts wondering why the graph is not looking so good.
The issue with Scrum/Agile is not the fault of the methodology itself, it is the implementation. On paper it looks great, but in the real world and this I need it now society we have created, it becomes increasingly hard to stick to set fixed processes when things need to be done right now. I don't doubt that some places are doing Scrum/Agile right, but from what I have discovered and again this might just be on account of bad luck, most places are not doing Scrum/Agile correctly and it only takes a little imbalance from the methodology to throw everything into disarray.
In my experience sprint planning does not equate to less work or more balance, it doesn't reduce the stress. Yeah, you know how much time you have in your sprint period, but usually there are tasks that only specific members of the team can work on. Meaning someone is usually doing more than someone else. Once again though, maybe I have just been unfortunate in the places I have worked which haven't implemented the pure and originally intended form of Scrum/Agile.
> In my experience rarely is Scrum/Agile implemented into an organisation in its pure and intended form.
Well, Scrum/Agile isn't a thing, its two very different things, and if you implement either of them in its "pure and intended form", you are absolutely not implementing the other in its "pure and intended form", since Agile is an approach that disfavors rigid externally defined methodologies in preference to adaptation to the needs of the team, and Scrum is a rigid, externally defined methodology with a rulebook of specific practices which, if you aren't following, you aren't doing Scrum.
An organization taking an Agile approach may adopt Scrum as a starting point for its internal processes as it evaluates what works for the teams it has on the problems it is working on, and adjust the details from that baseline. But if you are working within the defined bounds of Scrum you aren't Agile, and if you are Agile you are not committed the rules of Scrum.
Confusing Scrum for Agile or vice versa is a sign that someone doesn't understand either Agile, Scrum, or both.
What you describe here is what usually happens when a manager thinks he "knows Scrum" but really doesn't.
It just takes one higher up MBA who thinks he can do Scrum/Agile better to try take over and screw the whole thing. When that happens I usually turn my 2-weeks notice. You can't run Agile properly without management backing.
In my last job we rotated scrummasters every iteration. Daily meetings were not starting on time and running long.
My first turn I closed the door and said: "Ok, I want to keep this under 5 minutes so lets go around quickly". A couple of the guys who usually showed up late came in when we were almost done. I completed the meeting with a friendly reminder the meeting starts at the agreed time, sharp. After that, everybody showed up on time and meetings ran less than 5 minutes average.
> More often than most, the question of what did you do yesterday usually results in: I don't remember. And you know what, if you have a lot on your plate, that is a fair statement to make.
Someone having "a lot on their plate" is a symptom of poor iteration planning: no team member should be working in more than one thing at a time. Also, tasks should be sized between half a day to 2 days of work (around 3 to 12 ideal hours)
If your scrum board shows a bunch of small tasks less than half-day work, then your team went too far micromanaging and should combine them into single tasks that take no less than half a day to complete.