Have you ever heard about the five monkeys experiment? If not, I am not going to reproduce it in here, but you can find several examples on the net already (like in this article). Bottom line of the whole thing: after a specific dynamic and lack of proper communication, it ends up with five monkeys in a cage, avoiding what they really want – to eat a bunch of bananas – but not knowing exactly why. Even though there is not enough evidence that shows that this experiment really happened, I bet you can relate with some examples at work.

I bet on this because I have to constantly remind myself why am I doing something the way I am doing. Answers like “because we always have done it like that” often hide that, back then, the context was different than nowadays but we nevertheless still pay the price. Moreover, when talking about Agile, frameworks and methodologies, it’s often that you see a weird role game – like a theater play – that wouldn’t last if we stop for 5 minutes trying to justify it.

Don’t get me wrong, I am not saying I was never part of it, or that I would never be caught in that situation again. No way! I am aware that status quo is always a danger and that I have to do recurrent self-inspections if I want to get out of it. And it’s because of those analysis that I decided to register here the three biggest pitfalls I have seen in scrum teams and why do I believe that fixing those makes your team to deliver more value, faster.

Focus on delivering value, not story points! If a late defect has been detected due to the feature, be true about it, work on fixing it and then deliver the feature. Closing the US but opening a bug just after is not the real goal here.

🐵 Pitfall 1: Delivering story points, rather than value

Picture that: developer discovers a defect on the existing codebase while developing a specific feature. Is the defect related to the code of this feature? No, not at all, it’s been siting there for ages and nobody have ever noticed it. However, with this new feature, it’s almost impossible to miss that there is something wrong going on.

The pitfall here is trying to “deliver” the feature arguing that the defect needs to be fixed into another ticket. Isn’t it clear that even though the feature is not causing the defect, it puts it into highlight? All the users and developers will be impacted by the defect the moment this new feature will be included into the product. Why this need to be delivered so fast, at all costs?

Some may say: because we have committed to, and if we don’t deliver, our velocity will decrease. Forget about velocity if you consider that this there to compare yourself with other teams. Call it cadence, capacity, whatever you want, as long you understand that is an indicator to help you forecast the value delivered in the next sprints. Nothing more than that. Forecasting the value you will deliver. What is the value of delivering the feature from the scenario above?

Focus on delivering value, not story points! If a late defect has been detected due to the feature, be true about it, work on fixing it and then deliver the feature. Closing the US but opening a bug just after is not the real goal here.

As the saying says, a bird in the hand is worth two in the bush. Transposing to our world, one could say a merged pull request is worth two under review.

🐵 Pitfall 2: Individual thinking over team effort

By focusing on delivering value, I meant team value. Pitfall number 2 on my list is the selective memory I have seen but also been part of. The scenario is clear: you take an US to tackle, you put all your effort on it. Coding, testing and validating the best you can. You may even push a little bit further, doing all you can to have the pull request merged asap. Once the US is done, what do you do?

By experience, there is a good chance that you will simply turn your attention to the very next ticket. Like when playing football, you receive the ball and you keep your head down, running toward the goal. Even if you are heavily marked and two other colleagues are there, beside you, only waiting to the pass that will surely get your team to score. The selective memory I was mentioning before is that if you get asked “Are you part of a team?” you will promptly answer: “YES!”. Nevertheless, instead of trying to to help the team deliver its goals, you think as a complete individual, a free electron.

As the saying says, a bird in the hand is worth two in the bush. Transposing to our world, one could say a merged pull request is worth two under review. The same way development is much more than coding, excelling as a team member is much more than opening pull requests. Do the effort to change this mechanical response of directly grabbing the next ticket. Start raising your head, checking if there are any US in progress that you could help to unblock. Even if it’s not necessarily your “role”, like helping to test the accessibility of an US.

🐵 Pitfall 3: Blindly following the frameworks

Perhaps, the last pitfall is an effect of the naming we use. Sprint, Velocity and Story Points give a notion of competition. Like you were competing with other scrum teams. And it’s not only about the terms, but roles and ceremonies as well. I mean, daily stand-up is not only to get out of your chair once per day 😂

How many times have you said the magical “Yesterday I did that, today I will continue doing that and I am not blocked” and immediately stop listening to the others? Or spending an hour talking about what went well and what could be improved, so that in the end, you have a list of action items that nobody follows? Without understanding why the framework is the way it is, how can’t you say you are not like the monkey in the cage? Or worse, after unpleasant experiences, simply get to the conclusion that the framework is “broken” and it doesn’t fit to your team.

Don’t get me wrong, I am not advocating to follow the framework like the Holy Gral. I am, on the other hand, advocating to be mindful about what you are doing and about what you are not doing. And for that, knowledge is your best ally. There are two things I definitely suggest you to read:

1. The Scrum Guide - by Ken Schwaber and Jeff Sutherland Scrum.org link

2. Scrum: The Art of Doing Twice the Work in Half the Time - by Jeff Sutherland Amazon link

I also suggest you read it in the order above. The first is the guide itself, excellent to figure out that you may be doing stuff in your team that is not even described in the guide (like User Stories 😮). The second, is an excellent book from Mr. Sutherland (yes, the same co-author of the Scrum Guide itself) where he describes why each ceremony has its place and what is the goal you want to achieve. More important, it even uses amazing examples from tech and non-tech worlds.

🍌 In summary

Trying to summarise how to avoid the above pitfalls:

1. Deliver value over story points
2. Favor team effort over individual one
3. Know the framework over blindly following it

And most important, be mindful about your actions, you may be part of an experiment and you don’t know 🙈

cover credits to Jamie Haughton on Unsplash