I once interviewed a project manager whose CV claimed that she consistently delivered projects ahead of time and under budget. That is certainly no small achievement, so I asked her what her secret was. She answered, “I take the estimates from the developers and multiply by 5”. I used that story as a funny anecdote for a long time. In “real life”, who would ever manage to sell something if they charged that much? However, I have since been working on some projects that have…Continue Reading “5 reasons why forecasting is hard and 6 things to do about it”

One of the most common complaints I hear and read about Scrum is about Scrum being very strict and inflexible. Is that true? Well, the Scrum Guide, which lists the rules of Scrum does say: Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety That is pretty clear, isn’t it? Follow the rules or you’re not doing Scrum! Scrum seems to be out of line if…Continue Reading “Can we break the rules of Scrum?”

Only one out of every seven Scrum teams is self-organising, according to the State of Scrum survey. That is a shockingly low number as it means a lot of organisations miss out on a significant part of the benefits of agile! “The best architectures, requirements, and designs emerge from self-organizing teams”. So says the Agile Manifesto. In this blog post, I will look at what this “self-organisation” is about and how to get it going. Different degrees of self-organisation Self-organising teams is a fairly wide term and…Continue Reading “Creating an environment that enables self-managing teams”

Perhaps surprising to some, there are no “best practices” in agile. If there was, there would be no way we could get any better. What a horrible, defeatist thought that would be! Since things can always get better, there will always be a way to deliver more, quicker, without compromising on quality. We keep finding ways to make it easier and cheaper to make changes as we find out more about the problem our product is solving. That’s why we strive for continuous improvement, always…Continue Reading “Continuous improvement is never finished”

Cause effect diagram

A guaranteed way to waste our efforts when trying to fix a problem is to attempt to fix the symptoms rather than the root cause. Sure, we may be able to make the problem go away but as the root cause still is there, the problem is likely to come back. Either, we will encounter the same issue again or some different problem will pop up. The most well-known method for root cause analysis is the simple but surprisingly effective “5 Whys” method. This method…Continue Reading “Root cause analysis using cause effect diagrams”

No estimates

Estimation has long been a natural part of software development. Therefore, an approach like #noestimates, which gets rid of estimation can seem quite suspicious. After all, there are good reasons why we estimate. We need to know how long something will take, so that we can decide whether it’s worth doing or how much the customer should be paying. We also want to know whether we are on track to deliver by our deadline, so we need to know how much work is left. What…Continue Reading “#noestimates is just story points done right”

A sprint planning meeting has two purposes: Agreeing a sprint goal Creating a sprint backlog I have seen some teams where both these artefacts have been one and the same. The sprint goal is to complete a list of stories. The sprint backlog is that list of stories. This is certainly one way to do it but not a good one. I touched on what constitutes a good sprint goal in my previous blog post about preparing for the sprint planning meeting. Today, I will…Continue Reading “Don’t leave the sprint planning meeting without a plan”

Have you ever been in a sprint planning meeting that sucked? I have. Admittedly, I have found myself running a few too! The worst sprint planning meetings I’ve experienced have all been down to a lack of preparation. In this blog post I will look at how the right amount of preparation makes sprint planning much less painful. Give the backlog sufficient attention before the sprint planning The product backlog needs a bit of tender love and care before the sprint planning. Not only will…Continue Reading “A successful sprint planning meeting is down to the preparation”

Using Cost of Delay to determine value

This short blog post is the last one of three this week in which I explore methods for determining which features are valuable. In the previous parts, we covered the following: Value Poker – a technique for estimating the relative value between features Impact Mapping – a visual planning technique that helps us prioritise based on how each feature contributes to our objective Arguably, both these techniques are largely subjective. We make assumptions based on intuition, saying “this is more valuable than that”. Hopefully, we…Continue Reading “Determining value using Cost of Delay”

Impact mapping

This short blog post is the second of three this week where I describe methods for determining the value of features. In the previous part, we looked at Value Poker, a method for working out the relative value of features. In this part, we’ll be looking at impact mapping. What is impact mapping? Impact mapping is a visual method that helps us take a step back from the features and think about what we’re actually trying to achieve. Starting from the big goal, we create what is…Continue Reading “Determining value using impact mapping”