Questioning Scrum

I have been working with Scrum for the past 4 years. I love it. It was my introduction to the Agile world and It is so much better than what I did before. Now I am in a moment where I am questioning some things. I attended a couple of conferences about Kanban (so I am far from expert), but it was enough to plant some seeds of doubt about the things I do with Scrum. Below are some examples

Cross-functionality

- Scrum states that cross functional teams are needed, but the way to enforce it usually fails. Having iterations with stories that correspond to each area of specialization 'suggests' specialists for each story. I have struggled with many teams to be more cross-functional, to pair and to spread the knowledge, but Scrum doesn't give the tools to do that per se. On the other hand, Kanban with its 'minimize work in progress' principle enforces cross-functionality in a much better way as stories are not pulled until one of the current ones is finished. This 'forces' developers to pair or just work on areas of the system where they are not so comfortable.

Attack the risks

- Previous point also applies to tacking the risk first. There's usually the case in a scrum iteration that individuals choose the tasks they are more familiar with or they feel more comfortable with (yes, I do it all the time). Scrum 'sort of' allows this. In a self-organized team, team members decide which task they want to work with. How can we be biased to choose the task where the bottleneck is or the task that is representing the highest risk?. If there is no option other than working in the bottleneck/risky task, we don't have any other choice.

Sprints:

- Having iterations of equal size forces the team to break up the functionality in chunks that fit into a Sprint and also forces closure during the iteration to be able to finish them. A cadence is created as iterations go by and there's usually a sense of urgency because there is a lot of work to finish a story end to end. This is really nice but there are things that I don't like about these sprints. Imagine, we, the team 'commit' to a certain amount of work. When we are too careful with the estimations, all work is finished either 2/3 days before, and we (usually prefer to) relax and wait until the next sprint. What happens if we over-commit? We usually works harder to try to finish (which is not that good) and if we don't finish and the story is rolled, that story stretches in the next sprint in unthinkable ways!!. No scenario seems to be perfect. Personally, I prefer more stability. Committed and motivated people working 8 hours a day to complete the work. Does this mean stories should not be estimated? Well, I think in highly exploratory projects, stories should still be estimated even if using Kanban and the team should strive for closure in the estimated time. But the sprint fixed size sometimes is an artificial constraint that creates certain dysfunctions.

Iteration Plannings:

- I have been in many iteration planning where stories are 'guesstimated' because there is not enough information at that point (in 3 week iterations, that is entirely possible). Teams are encouraged not to pad, but when there's too much uncertainty, team members fall into this. Estimating the story when it's pulled allows in many cases to have more information, to avoid assumptions and makes this meeting faster and more productive. Probably, this is a case of 'Decide as late as possible'. For example, if one story depends on the another and many of the uncertainties will be cleared when then first story is completed, why spending so much time to speculate in estimating the second? (we do this very often in Scrum, don't we?)

- Iteration Plannings tend to be to large. And sometimes boring. Scrum suggests a ratio and the meeting should be timeboxed. If there's uncertainty in some of the stories, this could get worse. Who hasn't been in endless debates that later translate into a short 2 hours research that sheds all the necessary light? I guess this point is very related to the previous. A crisis of faith in estimating things I don't understand.   

Scrum taskboards versus kanban boards

- Kanban boards provide more information that Scrum boards. They allow to visualize flow and discover bottlenecks. Many times when working with Scrum I find my self looking at both the taskboard and the burndown to give me a real sense of the progress. With scattered tasks all over the board, usually I don't understand where we are.

- Be able to spot the bottleneck and provide an impersonal way of pushing the team is great. Constraining work in progress in certain phases forces the whole team to focus on the most critical things that will make the iteration successful. And this is not intuitive. Personally, If I looked at a scrum task board, I usually pick the tasks I am more familiar with even if they are not the highest priority or the ones that minimize the risk in the iteration. I don't think I am different than the majority :-)

Daily Standups:

- Something I read recently (and I liked) is Kanban teams do the standup looking at the board instead of looking at each other. I like that idea. I believe it foster collaboration in a less personalized way. Let me explain: sometimes I think Scrum daily standups put too much pressure on the people that are going slower or are stuck. People is looking at each other and sometimes there could be managers (chicken, but managers). I believe this could cause a dysfunction: lying about the status. Or even worse. Try to finish faster, dropping quality. Focusing on the board switches the focus from a person stuck to a task stuck. It's subtle. I like it.

All in all, I think kanban brings values that would make a team better. Minimize work in progress (and thus reduce the size of the increments), defer decisions until the last reponsible moment (estimate when you have all the needed information), focus on the problems and help resolve them (as opposed to help someone resolve it). I never used Kanban in practice. But I am at a point that with what I read/hear, I can spot moments or situations where we are not doing things in the best way with Scrum. I am not saying these are reasons to justify moving from Scrum to Kanban. And I am not saying these are shortcomings of Scrum. These are just some questions that arise from knowing that there are other ways of doing things. And I believe this questions are helping me improve how we do things now.