A cross-functional team isn’t a bunch of generalists

A cross-functional team isn’t a bunch of generalists

For the first few years of my Scrum Master career, I had a fundamentally incorrect understanding of what the term “cross-functional team” means. I thought it meant that everyone on the team could do everything. There was no room for specialised testers, database administrators or business analysts on a Scrum team. And just because someone is a JavaScript guru, that didn’t mean that they could expect to be writing JavaScript code. Fair enough, I thought. Somehow, though, the team members were less…

Read More Read More

Why your eyes and ears are the most important tools you have as a Scrum Master

Why your eyes and ears are the most important tools you have as a Scrum Master

What are your most important tool as a Scrum Master? Here are some ideas: A task board. Helps the team coordinate their work and keep track of the progress. Some sticky notes and sharpies. Quick and easy tools to make everything visible! A burn-up or burn-down chart. Is the team and project on track? A team barometer. Is the team happy? A Scrum checklist. Are we following the rules of Scrum or are we taking shortcuts? All of these can…

Read More Read More

The two most important things about feedback loops in Scrum

The two most important things about feedback loops in Scrum

Building complex products is unpredictable. We are forced to make a lot of assumptions (guesses). This is the why we use an agile framework like Scrum, as it allows us to verify our assumptions as early as possible, before we go too far down the wrong track. At our service, we have feedback loops. These help us create a better product (are we building the right thing?) and increase our productivity, quality etc (are we building it right?). A feedback…

Read More Read More

5 reasons why forecasting is hard and 6 things to do about it

5 reasons why forecasting is hard and 6 things to do about it

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…

Read More Read More

Can we break the rules of Scrum?

Can we break the rules of Scrum?

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…

Read More Read More

Creating an environment that enables self-managing teams

Creating an environment that enables self-managing teams

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…

Read More Read More

Continuous improvement is never finished

Continuous improvement is never finished

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…

Read More Read More

Root cause analysis using cause effect diagrams

Root cause analysis using cause effect diagrams

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…

Read More Read More

#noestimates is just story points done right

#noestimates is just story points done right

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…

Read More Read More

Don’t leave the sprint planning meeting without a plan

Don’t leave the sprint planning meeting without a plan

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…

Read More Read More