Tag Archives: Scrum Master

Glimpse into the past

Entry 13, Day 37

That was a long break, huh. But I’m back here and now. Let’s talk about the Sprint Retrospective. Time to stop running, look back and think about stuff we have just done.  As The Scrum Guide says: the Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. Inspect and adapt in a never-ending cycle of project lifetime.

Retrospective unleashes hidden demons so that they can be ceremonially butchered for the greater good of Scrum Team. And in turn – the Product.

 Dr Who

Retrospective is for the Scrum Team (Dev Team + Product Owner). PO should take part, but if the dev team feels that some issues should be discussed without PO, they can ask him/her nicely to leave for some part of the Retro. Scrum Master may also be asked to leave, but this is not recommended as the SM has  the power of insight “out of the box” not being the part of the dev team. Of course it might happen that the SM is the problem, that needs to be addressed, in which case, we have some kind of deep pathology anyway.

Any Scrum meeting is open by default for external observers unless the Scrum Team says otherwise, but in case of retrospective it’s often better not to let external spectators in, since it may cause team members to feel threatened and restrain from sincere feedback. This means, that if there is a manager who is not part of Scrum Team, he can be kicked out if the Scrum team says so. (I’m, not talking about who has authority over who as defined in the labour code, I’m talking about rules of Scrum here).

Who should lead the Retro? The common misconception is that it should be always the Scrum Master. Actually much better idea is if each time different person takes the lead. Everyone has a different style of mastering the ceremony, and variety is the key to unleashing creativity. Of course, if the team is new and unfamiliar with Scrum, the SM should take first few Retros to give them any clue how it can be done. And provide support later anyway.

Dr When

After each sprint. On occasion, you may perform Retros covering longer period, like half a year. Perhaps a specific period like first half year after product initial release or something like that. As any Scrum meeting it should be held at stable time – perhaps Friday afternoon, last day of the sprint is best. Don’t skip it till Monday since people will forget some stuff during weekend (and this is the purpose of a weekend)

Dr Why

Simply to improve. While learning any skill if you don’t stop and think what you blew up recently, your progress will be slower. Same is true for software development, and I don’t mean just coding or technical stuff. I mean the entire process from the bird’s-eye view, coding, testing, deployment, interactions inside and outside team, soft skills usage, corporate politics etc.

Dr Where

That’s actually an interesting question. You could do the meeting in the same place every time, but the point of Retrospective is to get the most creativity, memories and insight out of people. One trick to do that, is to perform it in some different environment, even unconventional. Think about going out, sit on a grass in nearby park, or in a pub, or even in a moving tram or boat. Seems silly, but…

Dr How

The biggest doctor. There is a myriad of possibilities when it gets to organizing the Retrospective. Sure, there are teams that for five consecutive years only do the red cards and green cards each time. Probably they should get a new Scum Master. If you stick with one routine way to do the meeting, people will be bored and you won’t get much out of them. Retrospective should be interesting and fun!  There are plenty tricks, exercises or games  to get people attention, some of them might be quite unorthodox.

Dr Five Stages

You can follow the Five Stages Model, as described in “Agile Retrospectives: Making Good Teams Great”, a must read by the way. So:

Set the stage – get people’s attention, spin cogwheels of their minds and set some theme for the meeting. And make them feel safe in order to get sincere output. Example: ask them to describe the sprint in one word (and hope it’s not “disaster”) or one emoticon. Throw stuffed toys at them, tell some fun story.

Gather data – get people to create a raw output. Classic way is to have green (good things) and red (bad things) sticky notes, give people 10-15 minutes to prepare a few and put them on a table. You can add third column like “ideas”. You can further divide the table into senses – related areas “I saw”, “I heard”, “I feel”. It will boost people memory. Moving motivators is nice idea and works well.

Generate insights – get people to crunch through what they gather, analyze, discuss, think, try to find the patterns. Talk about sticky note, elaborate, group them together. Encourage everyone to speak up.

Decide what to do – get people to figure out how to improve things. Generate some to-do list, decide what’s most annoying, what should be fixed first, what can be done inside the team and what requires external actions. You can maintain a so-called Impediment Backlog to help manage that kind of stuff.

Close the Retrospective – provide some kind of summary, make people feel good about what has been done during the meeting.

An interesting idea is Retr-o-Mat. It’s a simple page that lets you generate randomly the five stage scenario for retrospective from predefined activities. For now there is over million combinations, and that number is growing.

And what are your ideas for retrospective?


Leave a comment

Posted by on September 7, 2014 in Agile


Tags: , , , ,

Dramatis Personae

Entry 3, Day 4

Before an application is created, we need people to do that. People assume different roles, and I’ll try to define them today.

I thought, I will be using SCRUM framework, but actually by definition you can’t have SCRUM if you have only one person (unless we are talking split personality or other mental disorder). As you may know, Scrum Master and Product owner cant be the same person because of conflict of interests. However lets forget about that for a moment and take a look:

Client – The guy with money, needs and usually little to no idea how exactly to fulfill those needs with proper software. He wants stuff done quickly, cheaply and with high quality and finds it hard to understand that he has to pick one of those three. Usually does nor understand technology and people creating it.

Product Owner – This is the guy that is patient enough to talk to Client without cutting himself. He is able to find out what actually Client needs, what is most important for him and translates this into prioritized User Stories. Then he comes to the Dev Team and tries to explain what needs to be done to make Client happy.

Dev Team – Bunch of guys who talk strangely, gather in circle and sacrifice coffee to summon and control software. At least that’s how it looks like from the Client point of view. Dev Team has all the skills, resources and pizza required to create an Increment – working piece of software that can be thrown at production servers and will not cause a disaster. Or at least not a big one, small to medium seems to be tolerated on most circumstances.

Scrum Master – Invisible ninja who makes sure the other three do not kill each other. Basically knows the Scrum Grimoire by heart and guards the entire process not to go bananas. Should also has a healthy amount of common sense and transfer some of it to relevant party if needed.

So, I am going to be the Client, the Product Owner, the Dev Team and the Scrum Master in one person.

Besides talking (writing) a lot I’ve done a bit of investigation in hosting department. Nothing special.




Posted by on August 5, 2014 in Agile, BookSentry


Tags: , , , ,