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.
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!
If you have - or are confronted with - such a complaint, I have some tips for you to take into consideration
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.
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:
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.
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.