| > It's that you need to realize that the enemy of productivity has been siloing people and specialists that want to hand-off their work to others. I think you're wrong. What you should realize that there are many enemies of productivity, and different for different people. For instance, for me, having useless meetings (like standups or groomings) is mentally exhausting, and it kills a lot of motivation for the day. I was most productive under well managed waterfall - where we had one longer status meeting each week, and instead of grooming interrupting work on the problem every week or so, we had time to think about the problem complexity at the beginning of the project. In my view, the key to productivity in programming is focus. Whether you focus as a team or as a person doesn't matter. What is needed though is someone reliable who can shield you from all the distractions, and can do that without actually distracting you. In my experience with SCRUM, all the distractions are dumped onto developers (all of them in fact, via standup). I am not against Agile development (in particular, just like author, I am not against iterative development or Agile manifesto), but the SCRUM I found rather silly. It's an attempt to do one-size fits all. Not every feature requires exactly the number of people in the team. Not every feature requires one sprint of time. Some require less, some require more. If your work is managed correctly, you don't have worry about these arbitrary boundaries (which will always exist because time-boxing and standups, no matter how long the sprint or how big the team, are the key features of SCRUM). |
With Scrum, if something bugs me, I bring it up. We do standups only if required (put a signal on the board). Meetings have a single goal and having it as a ritual (culture) helps to accept it. My team is not always the exact amount of people. People get sick or have holidays or just migrate into other teams. If my team needs a specialist for something, we bring someone on board for the required time. But we also try to share knowledge and not to specialize, because that would be a risk (sickness, holidays, termination etc). We also learned to break down requirements into stories that are small enough, so we can reason about it. We understand Scrum as a foundation that we can agree on. And if we disagree, we figure out how to change the boundaries of Scrum so we can move on.