Tip:
Highlight text to annotate it
X
...I'm a kind of shield for the team, as I like to call it.
The product owner will have many questions and demands.
They have to be presented to the team through me.
I'm a Scrum Master and interaction designer. I often combine it.
Then I work as a Scrum Master but I also do part of the interaction design.
Two things. One, I'm a facilitator.
That entails making sure the Scrum board is in place...
and the Poker Planning goes well.
I push the team to do their daily standup.
In addition, I'm a kind of shield for the team, as I like to call it.
The product owner will have many questions and demands.
They have to be presented to the team through me.
What I like about Scrum is that everyone is in the same room.
It always leads to better quality.
Another great advantage of Scrum, linked to the first one...
is that things simply get done properly.
Instead of being forced to hand over a great design to another party...
having to sit tight only to get a result that you didn't expect to get.
In a Scrum, you're always there. You supply what you want to supply.
People are the most important. People who are proactive.
Who don't sit and wait for instructions, but act independently.
Who are specialists, good at what they do.
Not necessarily experienced, but they should be open to the method.
And you need a good balance of junior and senior staff on your team.
You also need a product owner who really understands how Scrum works.
Someone who can make decisions.
If you don't have that, this will happen:
A product manager says one thing, you go for it...
and it turns out it wasn't a good choice...
or that you failed to take certain things into account.
Finding a balance is a Scrum Master's greatest challenge.
On the one hand, you want a team that works well.
A team that enjoys their work, getting enough satisfaction from it.
On the other hand, you have to keep the product owner happy.
He wants value for his money, he's got a whole list of user stories.
The best thing for me is finding a flow...
in which the team gets better, as you need to keep challenging yourself...
and in which the product owner gets the quality he expects.
As Scrum Master, you don't really have any.
Scrum Master is a role, it's not a specialism.
If I had to choose, I'd say the whole sprint is a deliverable.
When a demo goes smoothly...
when we've ticked off every item we'd agreed to do...
when we've tested everything and get a good end result...
that's a Scrum Master's deliverable.
The whole team's, but especially the Scrum Master's.
One Scrum principle I fervently believe in is Eliminate Waste.
With Timeboxing, you can limit a Scrum planning to three hours.
Get something workable within three hours.
If you can't, start anyway.
Another way to eliminate waste is by minimising documentation.
Design documentation, meant to let other people know...
how the design should be built, that's not necessary anymore.
And Eliminate Waste also applies to the end product.
What do I include in the product, what do I leave out, or add later?
If you do this right, you'll get a focused product...
that includes only those features that are relevant to business and user.
A Scrum Master has a unifying role.
And a Scrum Master should know what every single discipline is doing.
What the visual designer is working on, what his choices were.
You should know about the technical aspects.
So you can advise the product owner when he has to make a certain decision.
Scrumming will become more and more popular.
To me, a Scrum represents the way you should handle projects today.
So I expect more of my projects to be done in an agile way, or with Scrum.
But there's an interesting tension...
because another trend is towards flex-working, at home, or remotely.
To me that clashes with Scrum. Scrum means working closely together...
which produces much of the synergy.
I'm really interested to see whether it's possible to Scrum remotely.
I hope I'll be able to try it out soon.
And who knows, it might work just as well as Scrumming together.