3 mistakes your young scrum team needs to overcome

Yesterday I gave a small workshop on agility and scrum to a group of around 20 people. After a quick introduction to the Scrum roles, the artifacts and the Scrum events, we went into the pitfalls. I wanted to share with the group the common mistakes/pitfalls that affect young Scrum teams, but because of time I only shared the standard ones. Like for example :

  • PO is not the owner of the backlog.
  • SM doesn’t have the support from the organization, and
  • Doing Water-Scrum-Fall, by using the old waterfall methodology to create an extensive backlog for months before the team ever picks up a story.

It is both good and bad that we didn’t have enough time to touch upon most of them. Good because it gave the group more time for a practical exercise that they had a lot of fun with. Bad because I couldn’t share it then, and I feel it is a really important topic. So I decided to write this post.

So what are the 3 mistakes (or pitfalls like we like to call) your young scrum team needs to overcome?

#1 PBI’s contain how to do, not what to achieve

Questions, Font, Who, What, How, Why, Where, Polaroid

This is more common than not. There is a reason why the most used PBI type is a user story. Unlike most things in life, this one is about the end goal, not the journey.

You never want to lock down a solution to a problem, especially during refinement. Why? Simply put, we don’t know what tomorrow will bring. We need to be able to respond to change over following a plan. If tomorrow’s technology changes, why should we implement an old one? If we learned a better way to do it, why should we do it like it is written in the PBI?

The end goal never changes. For example, “As a reader of this blog I want to learn new things”. Now the ball is in my court to help you learn new things, how I am going to do it you don’t care, as long as you learn new things.

Can I create a podcast and share it with you via audio? Sure. Can I do a Youtube video? Why not. Can I write another post and put it on medium, my blog, Linkedin or whatever platform you have access to? Yes, all of them reach the same goal.

A said it many times before and I will say it again.

We don’t know what we don’t know.

Don’t try and lock tomorrow’s knowledge before learning what tomorrow will bring.

#2 sub teams in the scrum team

Hand, Keep, Puzzle, Finger, Match, Insert, Handle

It’s very common when we have back-end and front-end developers. You usually see sub teams start appearing based on your technical skills. Small little backlogs start appearing in the sprint backlog. Common to hear during the planning “do we have enough work for the back-end/front-end team?”.

The scrum team is cross-functional and should contain all the knowledge necessary to tackle any PBI in their sprint. This is usually a symptom of poorly written user stories. Again, like the item above, they are focused on the how instead of the what.

There are no sub-teams in the scrum team, the same way there is no I in team. The Scrum team needs to work together as a whole and not as small competencies.

#3 Scrum is just a framework and we need to adapt it, if you don’t you are not agile

Ok, fair enough. The manifesto does say Individuals and Interactions over processes and tools. There is why I put over in bold, because it doesn’t mean instead.

This is a normal statement that I’ve seen managers, scrum masters, product owners and even members of the development team do. It reminds me of a kid that doesn’t know how to walk yet, but wants to run a marathon the next day.

The scrum guide in this sense is very explicit :

Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Don’t try to hack the system before understanding the system. There is a reason why martial arts follow the model Shu Ha Ri. Before transcending the framework, first obey the framework. After that you can digress from it, and way way after that, you can separate and transcend it.


Are there any other Pitfalls you see young teams do?
I bet you have your own list and it looks a bit different from mine.

Cheers,

signature

1 thought on “3 mistakes your young scrum team needs to overcome

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

search previous next tag category expand menu location phone mail time cart zoom edit close