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.
After the success of agile transformations that gave organisations the ability to respond to a change in the market more quickly and frequently, the last decade saw DevOps emerge as another magic wand. While valuable by itself, DevOps should actually be treated as one of many aspects of the Shift Left paradigm applied to the full software delivery life cycle. Patrick Debois, Andrew Shafer, John Allspaw and Paul Hammond coined the word DevOps around 2008. It comes down to the insight that combining the disciplines of development and IT operations by removing the thresholds between them allows for the elimination of waste and improvement of quality and speed of software delivery. The concept of Shift Left comes from the field of testing and boils down to the idea that the earlier in the software life cycle a fault is found, the cheaper it is to fix it. The accompanying model for this concept is that the process for delivering software goes from left to right as it goes from concept to cash.
Today I visited the UXDX Conf in Amsterdam.
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:
I am frequently asked by colleagues for advice on how to be a good Scrum Master. I will discuss some of the tips I share in a couple of blog posts. First of all I do like to state that I believe it's best to have a Scrum Master that is able to get his hands dirty in the activities of the team (i.e. coding, analyzing, designing, testing etc.). It will enable him/her to engage and coach at more levels than just overall process. In my opinion one of the most important things a Scrum Master has to do is to make things transparant for the whole team. Now this seems like very simple advice, and it is. However, when you are in the middle of a sprint and all kinds of (potential) impediments are making successfully reaching the sprint goal harder and harder, the danger of losing transparency always pops up. Here are three practical tips:
If you have a car, then every once in a while, you probably have your vehicle checked to see if it's still up to safety and environmental standards. So you take your car to the garage and have it checked. Now, the garage will do some tests and eventually you'll get a nice paper showing what kind of maintenance they have done.
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.