Epic Focus: Measure your way to a better time to market

There are several recurring wishes our clients bring to us, one of which is speed, to improve time to market. However, there is no dial that we can turn to deliver value faster. Software teams are not like cars; there’s no accelerator pedal. Even if we try to speed up by adding more resources, in many cases, the actual bottleneck will just become more apparent.

In our search for increased delivery of value, we hunt for these bottlenecks. No two contexts are the same, and for this story, we have a particular context in mind. Symptoms in different organizations are often similar, and our story might apply to your setting if you recognize the problems we encountered.

Read more →

Focus on what was “Done” during Sprint Review

As Scrum Trainer I get to meet a lot of teams and hear of many different ways to do Scrum. Most are valid ways, yet some seem more aligned with the values of Scrum or the purpose of the specific Scrum Element. In this post we’ll have a look at the Sprint Review.

The Sprint Review is generally the hardest event to get right. It’s where the Scrum Team and their stakeholders meet, thus the event with the largest number of participants. It’s also the event in which different people come with a different purpose.

  • The Development Team is present to show their work and receive feedback. They’re hopefully also there to connect to their stakeholders.
  • The Product Owner is also there for the feedback, but also to verify the longer term road-map and the state of the product backlog.
  • The Stakeholders often come to see the things they requested. We also ask them to share insights they have gathered during the sprint and to collaborate on the Product Backlog.

One thing I’ve observed is that the focus is often on What was planned and What is now “Done”. I feel this is an anti-pattern. While progress is important, I feel the focus should be on What is “Done” and What to do next.

Read more →

Multi products Scrum teams, how do you deal with that?

Multi Products Scrum teams are in reality observed often. One team serving different stakeholders and customer segments. Both would like to use the same people to work on their improvements.

In most organizations there tend to be more products than teams. While scaling frameworks give solutions on how to cope with a big Product and orchestrating value delivery among multiple teams. But how to deal with many products and a few Scrum teams?

Read more →

Five quality patterns in Agile development

In this blog series, I’ll discuss five quality patterns in Agile development to deliver the right software with great quality.

For years now companies have been adopting Agile ways of working and mostly the Scrum framework as their way to develop software. Scrum is all about working in dedicated teams on small increments of working software. Software that can potentially be released every single sprint. I’m sure you agree with me that this means that this software is therefore always tested every sprint as well. How could we otherwise release it right? This blog is about a trend I have noticed in a lot of companies that after time teams have more and more issues delivering quality software that conforms to business requirements.

Read more →

Agile Chef

Agile Chef

As a real ‘Foody’ I love to spend hours in the kitchen and experimenting. I also watch a lot of TV shows and documentaries about food. The other day I was watching an episode on Michelin star Chef’s and this one was about Richard van Oostenbrugge. He recently received his first Michelin star in his own restaurant ‘212’ in Amsterdam.

While I was watching it suddenly struck me that Chef Richard and his team were actually working quite in an Agile way. ‘We take a dish and try to improve this again and again, instead of starting some new every time’. For me this is a great example of ‘Inspect’ and ‘Adapt’. Continuously and in small steps improve your product until it is perfect and worth of a Michelin star. If you have dinner in restaurant ‘212’ you can look from all tables straight into the kitchen. All the food is prepared right in front of you. For me a perfect example of ‘Transparency’.

Scrum Values

So, what about some of the Scrum values like courage, focus, commitment, respect and openness in a restaurant kitchen?

Without courage there will never evolve a new Michelin star worthy dish. It takes a lot of commitment to put in the needed work hours day in day out. You need a sharp focus on quality, preparing methods and ingredients to get and to keep your Michelin stars. All team members in the kitchen, from the dishwasher to the chef have a lot of respect for each other and they all need each other to deliver the perfect dish. And finally, there is lots of quick feedback amongst the team members, a sure sign of openness.

I really like the extreme focus of a Michelin star restaurant on the end product and to see all teams work close together. For the perfect end result and best customer experience you also need the ‘black brigade’ and they also need to be aligned perfectly.

All in all, I think a Michelin star restaurant (and a lot of other restaurants) are a perfect example of an Agile mindset. Next time you go out to a nice restaurant put on your Agile glasses and see what elements of their way of working you can use in your team or organization.

 

Shut the door and listen from outside

At a certain point, you start to finish each other’s statements. Teams that have been together for a while can breed a sort of shorthand in their communication. This has a lot of upsides, but it can also cause, for example, predictable retrospectives. Retrospectives should trigger learning and improvement. When they become predictable I feel I’m missing out on something important. Is the forced recurrence a trigger for sameness, should we be doing retrospectives whenever we have an opportunity for learning? Or maybe it’s me, am I causing the predictability? Should I…

Read more →

Celebrating one year of Scrum Boosters!

History

In 2014 I started at Xebia in the business unit Agile Consultancy and Training (ACT). Colleague Nicole Belilos took me under her wings and helped me develop and grow within this group of Agile coaches. Together with Laurens Bonnema we formed a group who had experienced a lot of bad Scrum, fake Scrum, Scrum and…We wanted to do something about that, because we really believe in the power of Scrum, when done well. We started a cluster called Xcellent Scrum, a group within our business unit with a real focus on helping organizations in improving Scrum. We became certified trainers for Scrum Alliance and Scrum.org and we developed the Scrum Master Academy together with Jesse Houwing.

We encountered a new issue rising in the organizations where we were hired as Agile Coaches and part of Agile transformations. Scrum Masters who had the title or certification but were not able to facilitate Scrum to optimize its effect or who were not able to get teams and organizations further in Scrum.

Read more →

More Physical and Digital tools for Scrum Masters and their teams

A couple of months ago I blogged about some of the tools and toys that live in the trunk of my car. I take these along everywhere I teach and coach. Since posting, people have suggested additional items that just must be in my toolbox.

Time Timer Plus

Time-boxing is an important component of Scrum. It provides focus towards a goal and prevents you from over-analyzing things. We use time boxes extensively in each Professional Scrum class.

This lightweight, large timer helps visualize the time-box clearly to the class without having to juggle tools on screen.

Thanks: Evelien Roos and Just Meddens for this tip.

Logitech R800/700 and Spotlight

I’m using a trusty old Logitech Wireless presenter R800/700. It’s easy to use, has a laser pointer that works no matter what you point it at and has a built-in timer that can be used to warn you when you’ve been talking for far too long.

Read more →

Use Mob Programming to maximize your learning

In every Scrum.org Professional Scrum Development class, we touch upon both technical and collaboration practices to help improve the development teams explore new options. In a recent class, we had two teams that, after two sprints, hadn’t been able to deliver any “Done” increment to show at the Sprint Review. They were plagued by all kinds of issues, merge conflicts, refactoring gone bad, lack of automated tests and everything else that happens in real life. I decided to introduce Mob Programming to see whether that could help them.

The first experience with Mob Programming is usually total chaos and I tried to prepare the team accordingly. Trying out any new technique – anything that’s out of your comfort zone – can result in initial chaos, it requires a bit of courage to move onward. For those of you that don’t have any idea what Mob Programming is, I recommend reading our recent article in XPRT magazine which gives an overview of it or watching a recent recording of Woody Zuill’s presentation.Read more →

Scaling Scrum to the limit

You’re likely to have been asked the question: “we need to go faster, how many more people do we need?” Most people naturally understand that just adding a random number of people isn’t likely to make us any faster in the short run. So how do you scale Scrum to the limit? And what are those limits?

Meet Peter, he’s a product owner of a new team starting on the greatest invention since sliced bread. It’s going to be huge. It’s going to be the best. Peter has started on this new product with a small team, six of his best friends and it has really taken off. In order to meet demands while adding new features, Peter needs to either get more value out of his teams and if that is no longer possible, add more team members.

He and his teams have worked a number of sprints to get better at Scrum, implemented Continuous Integration even to deliver to production multiple times per day. It is amazing what you can do with a dedicated team willing to improve. But since their product was featured in the Google Play Store they’ve found themselves stretched to their limits. Peter has found himself in the classical situation in which many product owners and project managers find themselves. How do you replicate the capabilities of your existing team without destroying current high-performance teams? He contacts a good friend, Anna, who has dealt with this situation before and asks for her advice.Read more →