ITEM conference @ Dnipro (Ukraine)

Hello there!

I hope you enjoyed The ITEM conference. I did! It was heartwarming, you Dnipro people are awesome! We had nice chats, good discussions and a great Party!  And the band SINOPTIK was great!  (https://www.facebook.com/SinoptikBand/)

You can download the slidedeck of my presentation here: Working with remote teams.

Thank you all for organising this amazing event in this great city.  Hope to meet you again & enjoy your path to happiness!

roland

I will be speaking at Agile days RIGA

On July 7 and 8, it’s time for the Agile Days in Riga. Looks like it is going to be an exciting conference. I will be having my talk “Remote team facilitation and scaled scrum: How to make it work”. I’m really looking forward to contribute to this event!

What is the Agile Days Riga conference?

Goal of this conference is to provide a clear explanation why Agile and Lean software development approaches became so important nowadays, show how these approaches help to solve problems and facilitate discussions and experience exchange between Agile practitioners and newcomers.

http://agiledayriga.lv

Speaking in Kiev at the Agileee 2017 (Diary of a rookie)

rolandflemmagileeeMonday April 10, Amsterdam

In the weekend, 7-8th of April, the Eastern European Agile convention took place. I was granted a 30-minute slot to speak on Saturday. This was the first time ever for me to speak at a convention. If you ever might consider to share your knowledge with a large group of people, these notes might be of interest for you.

2 months earlier

Somehow somebody told me about the AgilEEEC. I was not aware of its existence. I think team members in Kiev proposed me to join them going there, promising me it would be very interesting. Upon checking the program, I noticed that the program was still to be determined and that the conference was open for submission. Could I? Should I? I could, yes…. But will I have a valuable contribution?

On the way home from work in my car, I was thinking about the poor result I had from Kiev team members in that day’s retrospective. Remote teams and participation is difficult. Giving this problem a bit more thought, I realized I had taken some essential steps already to solve issues some months earlier by rearranging teams. I began to see that the path I had been following to mitigate the negative effect on productivity and effectivity of meetings might be valuable to share. Come to think of it: Kiev is a large near-shoring capital and this conference is aimed at coaches and scrum masters: I just found me a subject that might be valuable enough to share: Remote team facilitation in large scaled scrum.

That night I struggled on getting my ideas condensed in writing. The next day I shared my pitch for review with a couple of colleagues and agile-soul mates to see if I was getting my point across properly. Within 3 days after the initial idea, the conference committee received my application.

6 weeks earlier

I was waiting anxiously for a response. Nothing. Day after day. I started to doubt whether this whole thing actually was a good idea.  Should I contact them to find out what is happening? Would that look too pushy?

I convinced myself that a light and small note to ask about the process might be harmless. I got an instant reply from Lina, the conference coordinator: My pitch sucked BIG TIME. She did not put it that way, but that was what it felt like. She liked the subject very much, but it was not “sellable” enough….

Sellable?

What…

Is…

that? …

“Better take a look at what the others do”, she wrote. And so I struggled for three nights reading and re-reading the pitches of the other applicants. I started to see a pattern in how they did it. There was a clear “what’s in it for me?” message in all of them. And a brilliant one-liner. I got it, nailed it and mailed it. I paid attention not to mention the sweat it had taken me to deliver this transformed pitch and added a neutral: “Hope this is more what you’re after, cheers, ro.” to the mail. That was it.

One month earlier

“YES! I’m in!” My instant happiness was immediately chased by the realisation I did not have a clue how these things are done financially. I consulted my conference-friendly co-coaches and learned that “it all depends…” (Great help guys). Transparency would help me out I thought. So I calculated what it would cost me if I were to pay everything myself and wondered if I would be willing to spend that money for this experience: What’s in it for me?

I reckoned that being able to share my story on a stage and possibly getting a recording of my session was a very good boost for my ego and maybe for my career. I put myself in the position of “nothing to loose” and was open for any proposal that could make it better. I verified with Lina how the financial side would look like. The organisation would cover for my expenses…. Wow! I was starting to feel like a real rock ‘n roller.

I was thinking this talk of mine maybe might not be appreciated by the companies I currently work for. What if they would fear I would be sharing details that would harm the carefully designed and nourished branding these companies have been craftin for years? That was a very negative thought, I admit. But it made me realise I’d better inform them about my plans. And so I did. What I actually did, was packaging the message of my admission in a request for cooperation. Both companies wished me lots of success. That was it. I heard later that Levi9 decided to sponsor this edition of the conference.

One week earlier

So far so good. Getting the material together actually was the easy part. I was starting to film and photograph daily life to fill my presentation with. I organised my thoughts in a mind map and created a presentation in Keynote. Some day at work, Emile, a colleague scrum master who would also be attending the conference, asked me how things were going with the lecture. I replied: “It’s progressing ok-ish, and I’m sure to have it all in place within the coming two weeks.” “TWO WEEKS?!”, He replied and laughed. “the conference is this Thursday!” Oops,… this meant I had less than a week to get it all sorted. I quickly proposed to dry-run it on him the next day.

Three days earlier

The dry-run was valuable giving me good feedback. The main thing to improve was to spend less time on the first part of my slides and make my reasoning more clear. Like a TED talk… Ah yes,…Ted talks… Why didn’t I think of this before? I always want to invent everything from scratch. I have to learn to start by copying from the best for faster learning.

Thursday april 6, 17:00, Kiev

I arrive in Kiev. Welcoming party, beers, meeting participants and attendees. And to be honest: I was feeling pretty cool wearing a participant badge. That was an unexpected sensation. Some talks. More beers. Silly talks…

Friday april 7

I am still shooting information that could be of value for my talk: Problems with technicalities, partying people, our cultural outing. It allowed me to add a couple of last minute slides to give the slide-deck a here-and-now feel. I also found a couple of glitches when rehearsing the talk in front of the mirror in my hotel room. Trust me, a mirror is a harsh feedback tool.

Saturday april 8, 00:30

I’m in my hotel room. It’s after midnight and I need to sleep. But I’m a rookie-speaker among a group of well renowned conference-tigers. My mind is spinning with doubts: “My subject seems so utterly futile and unimportant compared to Dave Snowden’s or any other talk. Will there be anyone joining at all? …Hey, Anyone who shows up is the right people!”

There is a day-opening where all ‘speakers of the day’ pitch their talk to persuade people to join their talk. I need to prepare that. What do I need to do to stand out in the crowd? I consult the other activities going on during my time-slot. It looks like I’m lucky: nothing special and nothing similar to my subject. So how can I get the people to join? Maybe I can pretend the mic is failing and talk in snippets with dropouts? Maybe tell a joke? I’m not very confident how to approach this.

Saturday april 8, 11:00

“And let’s have a big hand for all speakers of today! Please come to the stage, guys, and introduce yourselves!” I have chosen my seat in the venue strategically so that I can be one of the first to get on stage. This pole position could make it easier for me to have the others group around me rather than me trying to squeeze myself in. Because like everyone else, I am trying to avoid being the first to speak.

With every participant delivering their pitch, my heartbeat increases. It increases to a point where I am wondering if I will be suffering from a blackout our will need to hold the mic with two hands not to tremble. Why did I ever decide to to this? I look at Berglind. The stunning Icelandic coach calmly delivers a relaxed pitch about the Imposter syndrome. I promise myself to be calm.  I am not an imposter! I have a good story to tell! I need them to know what they are going to get. Love the mic!

She looks up in my eyes, smiles and passes the mic. I hold it close to my mouth, breathe in and look the audience in the eye. “So why am I here?” My voice resonates through the sound system. I know it is ok. Simple sentences. Slow down. Let your voice be pleasant and make it carry. Control is everything. Don’t forget to mention the time. Applause! I pass the mic. My heart rate leaps up one last time. I feel a jerk in my cheek. Where did that come from? I don’t hear anything. He’s done with this pitch. I clap my hands. For him. To support him. But primarily for my own relief. Everybody claps their hands. I’m calm now.

Saturday april 8, 13:00

It’s my time. I’m on stage, preparing the keynote, connecting the sound and so forth. I’m just walking a bit on stage and wasting some time trying to start an mp3 to entertain the crowd. And yes, there is some crowd! Being on stage now makes me feel comfortable: They notice me, but I am not the center of attention. A few more minutes to go…

Saturday april 8, 13:10

“Hey everybody! Are you feeling allright?”

 

I will be speaking at Eastern Europe Agile Convention

im_speaking_at_AgileEE(2)

The Eastern European Agile convention will take place on april 7 and 8 in Kiev, Ukraine. 2476 International guests and 195 speakers.

Headlining this episode are:

  • Dave Snowden – Founder and Chief Scientific Officer of Cognitive Edge

  • Olaf Lewitz – Certified Enterprise Coach

  • Michael Sahota- Certified Enterprise Coach (CEC)

I am very honored and pleased that I am admitted to talk about:

Remote team facilitation and Scaled Scrum: How to make it work

Near-shoring introduces complexity in scrum teams. When we scale scrum, this complexity is amplified and drastically reduces meeting efficiency. Is there a silver bullet to make remote teams high-performant in a (scaled) scrum environment?

When facilitating agile workshops, you probably experienced the difficulties of keeping the remote participants involved. And maybe you also know how hard it is to facilitate a highly interactive session with more than 50 people? Or how much harder it gets when 10 of them are connected remotely? I learned time after time participants feel left out, not listened to or find it impossible to follow discussions. Your sessions, intended to boost productivity, demotivate your remote teams.

Join this talk if you are a facilitator working with one or more near-shore teams. I will share my day-to-day experiences and insights that will help you to involve your remote teams.

I hope you will join me in Kiev!

Read more about the event: http://kiev2017.agileee.org/

Clarifying roles

poroleUnclear or too many roles do not produce good scrum. Use this game to verify that the separation of concerns is implemented correctly or to prove the opposite.

Introduction

This game is useful when you are in a scrum environment where the separation of roles is unclear.  It might be the case that there are more roles than prescribed by scrum, or that people are unaware of the responsibilities of each role.

Unclear or too many roles do not produce good scrum. Use this game to verify that the separation of concerns is implemented correctly or to prove the opposite.

How the game goes

  • Set a time-box
  • Introduce the game tot he attendees
  • put the task cards on the table (closed)
  • Have attendants pick one task card from the closed deck and place it under the role that is responsible fort his task
  • Let them motivate why
  • Facilitate discussion

How the Game ends…

Stop when the time-box is over. If you did not discuss all task cards, that’s no problem.

Ask the attendees to formulate a conclusion:

  • Can we get rid of certain roles?
  • Does each role have sufficient autonomy?
  • How are we going to enforce a better separation of roles?

Determine further follow-up steps.

Create a report of the conclusions and communicate them to the teams.

Download a full PDF version with sample roles included.

Estimation

thumb_estimateEstimation is difficult for some and therefore a recurring theme. In this article I hope to give you some insights that will enable you to help teams to overcome their impediments for making good estimates.

Why estimation is difficult (according to some).

When new to scrum, teams and scrum masters struggle with the concept of relative estimations versus time. When they get more experienced with scrum,  they get over these growing pains but difficulties with estimating stories often reoccur. Teams can get entangled in estimation details. “Do we estimate bugs and spikes? If we do, these estimates only spoil the velocity and make it useless, because these types of user stories don’t deliver customer value. How about time boxing them? But what does that do to our projected velocity? Oh no, It will go down! Scrum Master, help us, please!” In some cases I have encountered a tenfold of different issue types like documentation tickets, refactoring tickets, questions, dev-improvements,.. you name it. I can’t blame the teams for loosing their grip on estimating that.

If you follow the team down the detail-rabbit-hole, you will get stuck. It makes more sense to take one step back and focusing on solving the real problem. Obviously this would mean reducing the crazy number of different issue types to user stories and bugs only.

Another reason for teams not being able to estimate that I encounter regularly is related to safety. Some teams fear getting “punished” for not finishing all stories they planned. Coaching management is the first priority when you observe this behaviour. I have also seen teams  trying to keep their velocity stable to ensure management satisfaction. I see this happening more in nearshore teams and teams with non-western European cultural backgrounds. Whether these teams do not understand the purpose of estimation or have bad managers is up to you to investigate. You might also want to look in the direction of Agile contracts and cultural training programs for solutions.

Anyway, the end result is that teams are optimizing for getting perfect estimations, which is not a very cool customer centric optimization goal. At least, I have never met a customer who wants to pay for a perfect estimated sprint backlog.

Why estimation is important.

I have tried a zillion of possible approaches for estimation with various teams and with very different results. I encourage you to do the same.

What you want to achieve is a team that “knows” when the sprint is full. The same kind of “fullness” for all different occurrences of sprints (i.e. that takes variations into account like holidays, sickness, bad luck, rain, etc)…, so that the sprint becomes a constant factor on which we can measure the outcome of experiments and delivery of value.

You will help your team if you can get them to fully understand WHY we want to estimate in the first place. When team members get a deeper understanding of estimation, they will automatically get better at it and put their energy into more valuable activities.