Agile teams and Positive psychology

Imagine a retrospective taking place, and a team member expresses gratitude towards one of the colleagues for helping out. The colleague most probably communicates back in a positive way (verbally or non-verbally). After a short silence, there is a good chance someone else will also express their own gratitude towards others. Positive emotions spread trough a team by creating chains of events that carry positive meaning for others. In psychology, this is called “upwards spiral”.

Now imagine a completely different situation, where a team member brings negativity in a discussion or work. Just as example, imagine a person finger pointing others without argumentation. This could quite easily reverberate through others and result in a series of negative events. In psychology this is “downwards spiral”.

Emotions are contagious.

Emotions are also very much related to project success. Different emotions bring different kind of action urges, and therefore lead to different project results. 

In the end, emotions create an atmosphere and culture around us.

Even though positive emotions are subtle by their nature, they are also extremely powerful. 

“Positive psychology”, also sometimes referred to as “Science of happiness”, is a pretty new domain in psychology and is basically the scientific study of positive human functioning. For all interested in this I recommend everything written by Barbara Fredrickson and her very successful coursera course on this topic https://www.coursera.org/learn/positive-psychology.

I find so much common between topics of her research and Scrum values, and I think agile teams and practices can take so much from this science.

We can learn how to recognise upwards and downwards spirals, and how individuals can influence these currents. We can learn how to build resilience in risky project situations, and how to bounce back to track even if there is a failure. We can also learn how to measure positivity and what are desired measures for flourishing teams.

Opportunities for growing positivity are there, but easy to miss, and to learn about them we need to get in the game. There are so many games available in agile community, and I think we can use many of them for positivity growth. Anyone else interested in this research?

Retrospective workshop facilitators guide

Recently I’ve held a workshop for World retrospective day http://worldretroday.com @Novi Sad location, as part of the Agile Coaching Serbia initiative to join this worldwide event.

It was the second time I held this workshop, and we are planning to organise it for the 3rd time soon. Below you can find instructions, in case you want to facilitate similar event yourself. The main purpose of the workshop is to raise awareness with the participants on how important retrospectives are, and also to teach them activities and games that can be used for different retrospectives phases.

The workshop is about retrospectives, but game that was used for simulation of the project iterations is “Ball point game” by Boris Gloger https://scrumology.com/from-the-archives-the-ball-point-game/.

The goal of this interesting and fun game is to get as many balls through the team as possible within two minutes.

Rule subset of the game that we used in this workshop is:

• Everyone is part of one big team. 
• Each ball must have air-time.
• Each ball must be touched at least once by every team member.
• Balls cannot be passed to your direct neighbour to your immediate left or right.
• Each ball must return to the same person who introduced it into the system.

We played 4 iterations, and after each of the first 3 iterations there was a retrospective, each time based on different activities and games. Most of the workshop time is retrospective time.

As you may already know from the great book "Agile retrospectives, Making good teams great" by Esther Derby and Diana Larsen, there are 5 different phases in a retrospective:

1. Set the stage - helps people focus on the work at hand
2. Gather data - creates a shared picture of what happened
3. Generate insights - creates list of potential experiments and improvements 
4. Decide what to do - time to pick top items and plan what to do
5. Close the retrospective - wrap-up and express appreciation

The stage in the workshop was set only once in the beginning, and there was one closure in the end (for the time of the workshop this was optimal). From the other side, each of 3 retrospectives had their own phases Gather data, Generate insights and Decide what to do. 

Below you can find overview of the workshop activities from the beginning to the end. For the majority of these games detailed instructions can be found in the book “Agile retrospectives, Making good teams great”. For others, http://gamestorming.com is good place to read more details. Few are adapted myself. 


Introduction - 10min:
Introduction to the goals and content of the workshop, retrospectives in general and 5 different stages of retrospectives.

Set the stage phase - 10min:

Team stands in the circle. Each person says in few words one thing that is on their mind. Facilitator holds a box. Everyone who has some concerns not related to the workshop writes it on a piece of paper and puts it in this box. In this way team shifts focus to the workshop and puts worries aside.

Explanation of Ball point game - 5min:

Facilitator explains the rules and makes sure all questions about game are addressed.

Iteration 1 - 40min:

• 2min planning
• 2min iteration (ball point game)
• The rest of the iteration is retrospective (~35min):
• Gather data - Satisfaction histogram (everyone rates their satisfaction with how team played on scale 1-5). Provide visuals of the status for further discussion and analysis (same technique will be used also for the iteration 2).

• Generate insights - Brainstorming in "round robin" fashion. Pass a "talking token" around the circle. Only the person holding token can talk. It's OK to pass when your turn comes. 
• Decide what to do - Prioritise with dots. Each team member needs to put 5 dots next to whichever idea they want. Ideas with most dots win. 
  

Iteration 2 - 40min:

• 2min planning
• 2min iteration (ball point game)
• The rest of the iteration is retrospective (~35min):
• Gather data - Satisfaction histogram (same as in iteration 1). The idea here is to compare this diagram with the satisfaction diagram from previous iteration.
• Generate insights - "Free for all" brainstorming. People call out ideas at random.
• Decide what to do - NUF test. For each idea, people mark on scale 1-5 how they think idea is new, useful or feasible. All marks next to each idea are summed up to get the idea score. Ideas with the highest score win.
  

Iteration 3 - 40min:

• 2min planning
• 2min iteration (ball point game)
• The rest of the iteration is retrospective (~35min):
• Gather data - "prouds & sorries". People think about the iteration, and use stickers in one colour to note positive highlights, and in another colour to mark negative highlights. After that team has discussion about what patterns can be seen in their notes, which prepares them for generating insights. 
  
  
  
• Generate insights - "silent" brainstorming. People have up to 5mins to individually generate and write down ideas. After that "round robin" brainstorming  is used.
• Decide what to do - 100 euro test. Participants imagine situation where they have total of 100 euros to invest in different ideas from previous step. Sum of all money per idea is the idea score. Ideas with the highest score win.
  

Open discussion - 20min:

Initiate open discussion about retrospective activities and games used, pros&cons of each and their comparison. I promise this is the very valuable part :) 

Workshop closure - 10min: 

Team stands in the circle again. Team members appreciate others for helping them, contributing to the team, solving a problem, etc. Offering an appreciation is optional. 

More details for facilitators:

• Number of people - 20 max;
• Materials - Box for putting concerns aside, papers, balls, a big basket for balls, flip chart papers hanged on the wall, plenty of markers and stickers;
• Total time - Approx. 3 hours total.

In every day rush, people often forget how important it is to stop and think about what could be improved. By using 3 retrospectives, the team in this workshop succeeded to improve their results ~1200% :)

Feedback on the workshop was very positive. I hope you can use this guide to hold something similar, or that this post will help you succeed with your projects. 

How to prepare for PSM III exam?

After PSM II certification in May last year, I decided to continue my agile journey, invest additional time and energy in knowledge and practice of Scrum, and to sit for PSM III exam. I am very happy and excited to say that I got successfully certified!

Scrum.org considers PSM III certificate holders to have distinguished knowledge of Scrum, ability to apply Scrum in variety of complex team and organisational situations, and additionally that they can mentor and coach people or teams who are adopting Scrum. So I was very proud to become one of the first 500 PSM III certificate holders worldwide.

When I started with preparation, I found very few useful resources with experiences of people who actually prepared and passed this exam. So if you want to sit for PSM III, I hope this post will help you to navigate more easily.

The official information about duration, type of questions etc can be found here: https://www.scrum.org/professional-scrum-master-iii-certification.

One thing to keep in mind is that somewhere in 2006. assessment family changed from two to three levels, so it may happen that some information you find about PSM II online, now actually apply to PSM III. This is explained in details in the following post: https://www.scrum.org/resources/blog/introducing-new-psm-assessment-family 

Two links I found useful (although partially outdated) are also clarification on the format of essay questions https://www.scrum.org/forum/scrum-forum/6377/sample-essay-type-questions-psm-ii#6257, and this one https://webgate.ltd.uk/pass-professional-scrum-master-ii-psm-ii-assessment/. 

What I did for my preparation was a specific mix of activities and situations I encountered, and is not guarantee or receipt for passing the exam. But I hope it can be helpful and give some kind of hint for all of you who wonder where to start and how to organise yourself while preparing.

In the short what I did was:

• Prepared and certified for PSM II first (more about that in my post “How to pass PSM II exam?”)
• Went through Scrum Guide (https://www.scrum.org/resources/scrum-guide) and Nexus Guide (https://www.scrum.org/resources/nexus-guide) over and over and over again :) Even though they are very light-way, it is surprising that each time you read them you discover something new!
• Practiced all open assessments: Scrum Open, Nexus Open, Product Owner Open, Developer Open (https://www.scrum.org/open-assessments)
• Made sure I perfectly understand all terms from Scrum Glossary (https://www.scrum.org/resources/scrum-glossary) and Scrum Developer Glossary (https://www.scrum.org/resources/professional-scrum-developer-glossary)
• Read ALL books from the list https://www.scrum.org/resources/suggested-reading-professional-scrum-master, and any other source that seemed interesting or right.
• Followed scrum.org blog, and some other blogs I respect such as Mike Cohn’s https://www.mountaingoatsoftware.com/blog 
• Got actively involved in local agile communities, attended workshops, exchanged experiences and opinions with different people a lot, also tried to actively help everyone who asked me for an advice.
• Held advanced agile trainings at my workplace for different groups. This was a great experience and it is amazing how much you can learn by teaching others!
• Attended few high quality trainings (Advanced agile course by Alistair Cockburn and Better user stories by Mike Cohn). These specific trainings are no must at all. But my point is that things like this broaden your horizons and help develop critical thinking.
• And more than anything else I invested a lot of effort in trying to apply Scrum in the best possible way in every day work with my teams, and reflect regularly with focus and patience. 

Exam itself is indeed challenging, time is short (especially if English is not your native language) and passing score is high. But with enthusiasm, good preparation and a lot of practice you can succeed! 

For me it was a first attempt and I was successful with score 90%. And it was definitely a very exciting journey to this success :) I strongly recommend to everyone interested in the field of agile coaching to go for it!

Scrum and negotiation

If you search The Scrum Guide for “negotiation” term, you’ll get two matches, both related to negotiation of the sprint backlog between the product owner and the scrum team. Without doubts, making agreement about sprint backlog is a negotiation.

The theory of negotiation says that every time you cannot get what you want without cooperation of others you are negotiating. 

In scrum everything is about of cooperation, so I would say that pretty much all the time, while working in a scrum team, in one way or another, you are negotiating.

Regardless of whether team members are planning their responsibilities for a day, agreeing about sprint backlog content during sprint planning session, discussing the value increment added to the project, making adaptations of process during retrospective, or defining DoR and DoD, they are seated at the negotiation table. 

So how to negotiate in a scrum team?

Maybe you know the old story about couple of kids dividing a pizza. In case you don’t here is the short version:

There is one pizza. There are two kids who want to have it. 

So who will be the winner? Maybe one of the kids takes pizza and wins. Another possibility is that pizza is split half, so both kids will be equally happy.

The win-win and scrum approach would be to talk about WHY each kid wants to have pizza. Maybe one kid likes to eat only crust, and another kid likes to eat only centre of the pizza. Maybe there are no conflict of interests as initially assumed.

So we should always ask WHY while negotiating. Maybe when you know WHY, if needed, you can offer alternative for what was asked, and create a real win-win situation (getting what you want without taking away what others want). Sometimes WHY is already there but you need to listen to other team members carefully.

Recently I’ve attended Advanced agile master class with Alistair Cockburn in Belgrade. Very impressive class. One of the things that was especially striking was when Alistair mentioned that daily standup is meeting for listening, not for talking.

I think in general people can always pay more attention to listening. If you also believe this, your next retrospective may be a good moment to discuss listening and negotiation practices in your team.

How to pass PSM II exam?

Last week I’ve successfully passed Professional Scrum Master II exam. Hooray! :)

For everyone who wants to attend this exam I’ll share my impression of the assessment and the best way to prepare.

In difference to PSM I assessment which is pretty straightforward, PSM II is an advanced exam, with 30 questions, time limit of 90 minutes and 85% passing score. The majority of questions describe real world situations that you need to read through, understand and then think about possible answers. So you will most probably need all 90 minutes for the exam. The questions are multiple answer, multiple choice and true/false.

The main challenge if you prepare for PSM II is that there is no more “advanced” source for preparation than there is for PSM I. And yet, you will not be simply tested for knowledge of Scrum basis as described in Scrum and Nexus guides. The focus of this test is more on your own understanding of the underlying principles of Scrum and the way you effectively apply Scrum in complex, real-world situations.

There are of course ways you can broaden your visions, such as participate in scrum.org blog, read many books listed as additional sources on the site, but still each of these sources provides more an expert’s opinion of a particular subject area, rather than a single source of truth. So how I see it, it is more important that you develop your own critical judgment.

Assuming you already have Scrum knowledge and experience as a Scrum Master, what I think is crucial for preparation is first to continue what you are already probably doing - open your eyes and ears to everything that is going on in your environment and is related to your team(s) and the Scrum application in different complex situations. 

Also, talk to other people who have different surroundings, listen to their opinion on how different circumstances and Scrum applications influence their teams and projects, and discuss possible outcomes. 

Read different sources from scrum.org (https://www.scrum.org/resources/ways-learn-about-scrum) and from other relevant sites and blogs, and practice open assessments (https://www.scrum.org/open-assessments). Questions from open assessments are more simple that you will get on a PSM II exam, but will definitely help you in preparation.

In the end, I’d just like to add that I think that scrum.org did a really good job creating this exam. It is well designed, and it will test your opinion and reactions in a very practical way. In everyday work, Scrum Master’s judgment and reactions are way more important than anything we can memorise from books or other resources.

If you have any questions or doubts about this topic that you would like to discuss feel free to leave comment on the page.

Why I love user story mapping

User story mapping is a powerful technique for requirement gathering and project backlog management. If you were ever in a position where your team has a rough idea about what needs to be done, but the work is complex and you are not sure how to approach it and break down into activities, and also there are many questions that need to be discussed before you can do this, than user story mapping is definitely a technique to try.

The basic idea is very simple. Even though there are different theories on how you can make maps, I personally prefer to start with the most simple variant, and then gradually build up based on the project needs. 

In short, the session will look like:

1. You prepare a board and stickers (physical, virtual - whatever is team’s preference). 
2. The story is told, from user perspective, which describes flow of how software will be used.
3. The main steps of the story flow are written sequentially and separately (blue stickers on the picture). 
4. Below each step then you put all elements/activities/user stories related to this particular step (yellow stickers on the picture).

In this way, you’ll get two dimensional grid representing the backlog that will look similar like the picture below. 

User stories should be ordered top-down in accordance priorities. If this is the case, a product owner can easily slice the map by placing a horizontal line, so everything above the line represents MVP or something you need to deliver during an iteration or for a release.

You don’t need anything else but basic understanding to put user story mapping in practice. Easy to understand, a bit more complex to master. But in the same time, your team will immediately gain great benefits of using it.

One of the benefits of 2D grid, in relation to the typical flat backlog, is that visually it is much easier to grasp the project requirements, and notice open questions and dependencies. Visual thinking is common in approximately 60%–65% of the general population, so the most chances are that this type of representation will be the most suitable for your team too.

Secondly, this will definitely be a very efficient way for both the team and stakeholders to create a mutual idea about the overall picture of the project, both from the business perspective, but also from the perspective of project implementation. The common understanding of everyone involved is a precious asset to any project.

Besides that, prioritisation is becoming simpler. It is very easy to prioritise and in the same way make sure that you indeed take stories that will compose at least a minimal viable solution.

Finally, maybe the most important benefit is that this will boost communication and discussion, and reveal questions of all participants in early phases of the project, which will lead to more quality and faster product backlog creation. 

Especially interesting experience is practicing user story mapping on a back end project, and my team discovered this during a recent session we had.

In the beginning I was a bit reluctant, because the application of this technique is typical for front end projects. For front end this is natural, because everyone can easily imagine stories of end users, and project this on a map. 

Thinking about back end, the story needed to be about how two other complex software modules will use what we need to make. In other words, our “user” was pretty abstract and sounded a bit complicated for simply describing its stories by putting stickers on a wall.

Surprisingly, working on the map was even more beneficial and engaging than it would be is we would tell the stories of end users. The reason is that mapping back end algorithm was actually the perfectly natural flow of thinking for people used to programming. Therefore, the team got completely interested and involved in maps creation, many essential questions were raised and clarified, and this session resulted in a map that now represents extremely useful backlog both for product owner and development team members. 

Besides that, after user story mapping sessions were finalised, the team already had very solid idea not only about what needs to be done (as it would be the case after the typical mapping session for front end), but in the same time how they will do it. 

Thanks to the great team and this great technique!

Why the heck do we need story points? At least several reasons why every team member should care.

Imagine a development team, working on a mobile solution that was supposed to be delivered in five months. Even though deadline was clear, the decision was made that the team will not be bothered with estimations. The backlog contained five big themes, out of which four were major from the perspective of business value. In the beginning, work was progressing well. Two major themes were finalised in first two months. Third major theme, however, turned out to contain unexpected complexity in few turns, and took almost three months of development. Even though it was pretty soon clear that there is a high risk that project deadline wouldn't be met, it was too late to change the approach. The project was delivered end of fifth month, containing only features that were completed at that point. This had a huge impact on users, and majority of them gave up and switched to usage of a similar solution already available on the market. If the product owner had known that the third theme required so much effort, he would have probably prioritised list of user stories differently.

How would you feel if you were member of this team? Probably the worst feeling of anyone working on a software solution is if software is in the end not used by anyone.

What can be the possible reasons for end results not being used? There are of course many, but one of the common ones is described in the story above - prioritisation not being performed well on a project with deadline. Prioritisation is done by product owner and is influenced both by business value of an item, and its cost. The cost itself is calculated based on the estimation.

So here we are. Story points determine cost, and cost highly influences prioritisation. And prioritisation will determine if software is serving its purpose and end users, and therefore to which extent it’ll be used.

Besides that, majority of projects can never be initiated in the first place and executed later on without at least rough cost calculations. When I try to explain this to people I always compare it to over simplified example of buying a pair of shoes. No-one is usually going to buy a pair of shoes without seeing how they look, checking if they are comfortable and looking at the price (assuming we are in a physical store and can take them out of the shop immediately after payment). If customers would not be able to know these things, shoes manufacturing and market as we know it today would not exist, so as many interesting professions in this industry.

So talking about software development projects, estimations are needed just from the completely practical reason that project cost money, so as shoes and anything else in this world (except from love and friendship of course :)), and someone (for example customer) needs to know the price and to pay for it. Project costs are calculated by long term planning, and one of the most important inputs for long term planning is backlog estimation. As project progresses, backlog estimation is occasionally revisited. Over the time it becomes more and more accurate because team gets more mature, and highly valuable historical velocity data is being gained.

Furthermore, analysis and discussion about required effort for implementation of backlog items can reveal complexity or risks that were unknown before estimation was performed. Revealed dark corners of the project can lead to conclusions, valuable for in-time architectural or design decisions.

All above is related to agile estimations in general. Talking specifically about measures, the most common ones are story points, ideal hours and hours. There are so many resources where you can find out about advantages and disadvantages of each. My personal preference is story points. The main reason is that units are relative and therefore last longer. In addition, estimation process is faster. Somehow it is always easier for people to pick up the value from a scale than to estimate required effort in hours. The last but not the least, poker planning sessions and story points usage can actually be fun. I’ve been on some very valuable and at the same time fun poker planning sessions.

Sometimes it happens that people know they need to estimate stories, but reasons for this are unclear, so naturally they do not care. Understanding the background will lead to communication rise and increase of engagement. What are your thoughts on this?