Misconceptions about Scrum by the book
In every organization and in every team, I run into one or two customs that people tell me are part of "Scrum by the book", that aren’t actually in the book.
Scrum
So many meetings in Scrum!
I’m a developer and I like Scrum. Not every developer does. A complaint I sometimes hear is the following:
We spend so much time in meetings that I don’t get around to writing code!
— A frustrated developer
If you have - or are confronted with - such a complaint, I have some tips for you to take into consideration
Should we spike or should we change how we do product backlog refinement?
The Scrum guide by scrum.org doesn’t mention spikes, but it has something else: the Product Backlog Refinement. And this often gets mistaken for a Scrum Event that puts the entire Development Team in a room with the Product Owner for half a day a week. The entire team then looks at the top of the product backlog and tries to uncover all the details there. They do this until enough uncertainties are uncovered and the team feels confident it can estimate. It gets worse when there is a project manager on board who needs estimations to discuss budgets and delivery dates before deciding whether he wants a story at all. This way, you end up spending a lot of time on value you’re not delivering. At some point, somebody will say: This is taking too long; let’s make it a spike and move on. And that’s not what spikes are for.
A spike is a concept from Extreme Programming (XP) where the team does a technical examination of possible solutions before committing to one to solve a requirement. Like many concepts from XP (for example: Daily Standup vs Daily Scrum), it’s found its way into many Scrum projects. The Scrum Alliance adopts and expands the concept by saying it is a story-like backlog item that yields information rather than a working increment of software. This information can be both technical or functional and is deemed necessary before deciding on whether or not to implement a functional story. And if so, it ensures that enough information is available to know how. The Scrum Alliance warns that a spike should be used sparingly, if at all.
Bruce Lee's Top 5 Agile Coaching Tips
When I was a kid, I was a big Bruce Lee fan. I walked around the playground rubbing my nose with my thumb. When I had a piece of rope, I had to do my version of the nunchaku routine from Way of the Dragon and made cat-like noises. Looking back at Lee, I find it quite striking how many of the principles of his fighting style Jeet Kun Do apply to agile practices. Check out these descriptions of the fighting style:
- "Jeet Kune Do is not fixed or patterned, and is a philosophy with guiding thoughts."
- "Jeet Kune Do practitioners believe in minimal movements with maximum effects and extreme speed."
- "The system works by using different "tools" for different situations, where the situations are divided into ranges, which is kicking, punching, trapping, and grappling, where martial artists use techniques to flow smoothly between them. "
- "Through his studies Lee came to believe that styles had become too rigid and unrealistic. He called martial art competitions of the day "dry land swimming". He believed that combat was spontaneous, and that a martial artist cannot predict it, only react to it, and that a good martial artist should "be like water" and move fluidly without hesitation."
The Lean-Agile Connection
Most people working in professional IT-driven companies, have heard about Agile, most people in professional companies have heard about Lean. Those who are interested in the subject, have found out that these two very popular phrases are actually closely related. So what is the relation between lean and agile? I'll try to briefly answer this question and will start with a little history.
Contrary to popular belief, the origins of Lean aren't in Japan, but derive from the Ford company in America and the work of the American statistician W. Edwards Deming. The following excerpt states the heart of his philosophy:
Why Time Is No Measure For Progress
One of the questions that Project Managers always pop up during projects is: "how many days will it take to finish this work?". This is a very natural and sensible question. You want to know when a project will be finished, so people can have an expectancy of the needed budget, what functionality is in it and when it will be finished. However, answering the question is more difficult than traditionally is assumed.
Imagine you're expecting a friend from a distant city, to come over to your house for a visit. The city is 150 miles away. He's been traveling for a while and you want to know how long it will take to arrive to your house. You expected him to make the trip in three hours. You give him a call and pop him the question. "How long will it take for you to get here?". Imagine him answering "I've been traveling for two hours" What kind of conclusion can you get from this?
