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?

Remote agile meetings in distributed environments

After years of working in distributed environments, sometimes I forget there is anything specific about it. But each time when a new person, used to traditional office environment joins the team, it becomes evident that skills for online communication actually need to be learned.

Therefore I collected tips on what I see to be important if you are new to working in remote teams, or if you just think that your online communication needs to be improved.

Know the cultures and bring differences together. 

Distributed teams in most cases involve people from geographically distant locations, so there is a good chance there are certain cultural differences in the group which may affect communication. And with agile, more than with any other way of working practices, communication and interaction between team members is important. 

I think that doing a bit of research can be beneficial - so you can understand specifics of your own cultural context first, and then also context of your teammates. Even though stereotyping is the last thing that would benefit you or your team, not knowing basic elements about what are the possible differences can also be harmful. Different cultures may have different view on what it means to be open, engaged, positive or even on time. 

Once you define zone of the differences, you will not, off course, completely change your behaviour to match remote team members, but it may happen that moderate adaptations from both sides are needed. And off course, keep it in line with agile principles!

Plan for the meetings.

When your team is distributed, organising a meeting is most often more than sending an invite. For example, it can often involve people from different time zones. So sometimes you will need to do a bit of math to find the suitable time slot.

Due to these and other practical constraints, it is a very good practice that team makes commitment statements related to meeting practices. For example, "meeting begins no later than 3mins after start time", “organiser will distribute materials for preparation minimum 1 day in advance", or whatever is important for your team. Talk to your team and define statements together.

Limit the length.

I would not recommend online sessions longer than 3 hours. From my experience, it is hard to keep "online" team focus much longer. If you have, for example, long refinements, it is better to make a few shorter than one extensive session.

Invest in good microphone, camera and speakers.

The best advice is probably to invest in good conferencing equipment. Some non-verbal communication will inevitably be lost,  so make sure this is minimized by choosing the best equipment that fits your budget.

Use the camera appropriately :)

As funny as it may sound, I think it is always worth to repeat following two things people tend to forget:

• Turn on the camera
• Look in the camera - at least occasionally. I see quite often people turn on the camera, but then what you see during the meeting is only top of their head or similar. Camera being turned on doesn't make much sense without eye contact.

Pay attention to hand gestures.

Don't spare energy on using a bit more (controlled) hand gestures. You can make yourself more clear and it will make up for part of the non-verbal communication "lost in the cyberspace”.

Speak up.

If you use conference room and you are not sitting near the mic be sure to speak at a bit slower pace and speak up.

Send meeting minutes.

For important meetings, such as sprint planning where the goal is defined, retrospective sessions etc., it is even more important than for the non-distributed meetings to send meeting minutes. In that way, you can confirm everyone came out of the meeting with the same understanding of what was concluded.

Experiment with tools.

There are many visual and collaboration online tools available that can make your life easier. Experiment until you find the best ones for your team. Good communication tools, online boards, planning poker tools, whiteboards, etc. can make your meetings more productive.

Bring some humour in.

Working remotely introduces some limitations, so it's good to try to bridge the distance by humour and make things more personal - having same team cups for morning coffee during the daily standup or eat cake "together" to celebrate the successfully delivered release.

Make team building.

For longer project, if project budget allows, try to organise at least one in-person meeting and team building - it will boost team's performance. Ideally, this would be done for the project kick off.

With a little more planning and engagement, everything is possible. I have been working in both remote and non-remote teams for many years and we were equally successful. I've never seen the team whose issue is actually a distance. If it seems that remote meetings do not work, it is always a sign of something more essential not being ok. 

So just think carefully through it, use these tips for overcoming the distance and you'll be just fine!