What’s the best Planning Poker tool in Zoom? or Teams?

During the lockdown, we do Planning Poker in Zoom or Teams. Which tool can you use the best to collaboratively determine our estimates? Which facilitates the best interaction in your Scrum team?

Why you should you keep doing Planning Poker?

You’d like to keep doing this, because this Refinement practice naturally raises:

1. The team’s awareness of what work is expected and get clarification.
2. Knowledge and tactics will be shared
3. Assumptions will become clear
4. Negotiation with the Product Owner will occur to keep it small AND valuable

More about why estimates work: Read this book Agile Estimating and Planning by Mike Cohn.

Which Planning Poker tool to use online in Zoom? or Teams?

What’s the best Planning Poker tool would you use in Zoom or Teams? I had a discussion with my Agile coach colleagues within Xebia. We agree analog cards trumps any online tool. Why?

A. First, analog cards are easily made available to anyone. So, no firewall to jump over. And no licenses needed. No security compliance issue. Just create them!

B. Secondly, each team member could create the card deck themselves. As a consequence this fosters ownership. Some will introduce some fun and/or improvement. Especially, if you encourage any team member, to introduce an extra card. For example, ‘time for a break’ or ‘we try to estimate too soon’.

C. Most importantly, it will naturally enforces any team member to put the camera on. Raising opportunities to spot non-verbal signals of anyone. That’s great!

This together comes close to mirror the office situation. And as an advantage, the screen sharer doesn’t need to switch applications all the time.

See my deck of cards. Easily made of some thick paper and a fat black marker, for instance.

You can use these planning Poker cards in any Zoom or Teams meeting. A low-tech solution facilitating great interaction!

Any questions? Raise them below!

Your potential next step to increase your effectiveness in Scrum:

Would you like to become the best Scrum Master? Join our Advanced Online class

Would you like to deepen your tactics in great Refinement? Join classes like
Specification by example by Gojko Adzic It is the cornerstone of any successful requirements and testing strategy with Agile and Lean processes, like Scrum, Extreme Programming, and Kanban. This workshop teaches you how to apply SBE to bridge the communication gap between stakeholders and implementation teams, build quality into software from the start, design, develop, and deliver systems fit for purpose.

Make your team stronger. Distribute the workload of testers among time better and become better as a team? Understanding cross functional competences and needs will increase while applying Test Driven Development.

Threat Modeling – Start using evil personas

Agile teams often use the concept of personas to create more tailored user stories, so could you use evil personas to describe malicious behavior?

Personas are “synthetic biographies of fictitious users of the future product” and “a powerful technique to describe the users and customers of a product in order to make the right product decisions“. The purpose of using personas is to “understand who the beneficiaries of the product are and what the goals they pursue”.

In essence, personas help teams understand if the designed functionality actually fits the end-user desires. This makes it a powerful approach to also identify possible risks by introducing malicious users or ‘evil personas’.

Read more →

Security by design? Don’t create a YAPWAV!

Security is about making risks visible and mitigating the impact of possible incidents to an acceptable level. The ‘security by design’ philosophy aims for every application or system to be at an acceptable risk level, all the time.

When starting with a ‘secure by design’ approach, often existing security processes are simply bolted onto the development life-cycle. One of the major pitfalls of this approach is requiring teams to do a YAPWAV. YAPWAV stand for the developer’s hell called: Yet Another Process Without Added Value. A YAPWAV is an activity a team solely has to do to please a stakeholder, without noticeably improving the product they’re building.

A classic example of a YAPWAV is the mandatory risk assessment for each software deployment, just for the purpose of satisfying a documentation process. These kinds of security processes are bound to fail as they add no (visible) value to the product the team is building. In the agile philosophy, every action or activity should contribute to the value of the product. The moment an activity is introduced that doesn’t add visible value, teams will decide it’s not worth the effort and stop doing it.

Read more →

Quality pattern 2: Automate your acceptance tests

Welcome to my second blog in the series of five quality patterns in Agile development that can help you to deliver the right software with great quality. In my previous blog, I’ve introduced Example Mapping as a method to get to specific examples for scenarios or rules that your user story is made up of. The output of the refinement sessions are your requirements and thus your tests. In this blog, we will take a further look at these test cases and why it is important to automate these acceptance tests. Not just from a development team perspective, but also what they can bring to your business.

Read more →

Pre-mortems, steering clear of the rocks.

Are you worried your new project won’t be successful? Or afraid getting stuck applying these new techniques you just learned in a training? Or are you perhaps part of a very pro-active organization, but is a lack of focus crushing all new initiatives in the long run?

At Xebia we help customers as consultants, but also as facilitators or as trainers. A common pattern we see is people worry about how to move forward with their newly acquired knowledge or insights. In order to improve your chances of success, it can be very useful to do an upfront analysis of the causes of these worries. This will help you steer clear of the rocks, and prevent early ship wreckage of your new ideas. One of the formats we’ve been using over the years is the so-called Pre-mortem.

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 →

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.