Show who is pair programming on tasks in your Azure DevOps boards

Are you using pair programming to learn from your peers, write better code and save time spent on code reviews? In that case, you might want to make it visible on your digital issue board too. However, in Azure DevOps, you can only have a single assignee per task. Through customizing your process and board you can still show who are working together on a task. Here is how to do it.

Read more →

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 →

How to if?

While trying to upgrade my programming skills, I ran into a new-fangled way to do ifs.

The example below is taken from code that gets a value for a property of a class. A value may or may not be set and if it isn’t the code should use a default.

You can find the code here [on Github].

So my classic go-to solution was to use an if statement like this:

[more…]

Use Git and Markdown to Store Your Team’s Documentation and Decisions

Do you sometimes feel like Bill Murray in Groundhog Day? Reliving the same day over and over again? I sure feel like that in some discussions with my team: revisiting the same discussion multiple times, because we fail to document decisions properly. Redrawing that diagram one more time, to come to the same conclusion. Searching for that one document in your email? Sifting through several versions of the same document, not sure which version is the latest? 

Next time around you can avoid these situations, using simple tools that your team is already using: Git and Markdown. Add Architecture Decision Records into the mix to capture the important decisions and the context in which those decisions were made.

Read more →

How Do You Know Something Is A Bug? – Using Mental Models and Oracles in Testing

Did you ever find a problem of which you weren’t sure it was a bug? You probably thought it over, looked up the requirements or discussed with a team member. Perhaps you figured it out by yourself, the requirements made things clear or your team member could help you out. Either way, you needed some source of information to recognise the problem as a bug. You used your mental models and oracles.Read more →

Share This