Skip to content

Open Space – how to?

Hi

Last week I had the pleasure of helping to prepare an Open Space session together with Jorgen Hesselberg after his trip to Europe for his talk at xp2013.
I though of sharing some tips with you on how to set up an Open Space Session, and who knows?, I may be able to give new ideas :).

The Open space

Although it may not look like, an Open Space Session is very organised and needs to be prepared in advance. The risk of not doing so is that you’ll be helding a session with no objective and you may end up with a bunch of info but no real ideas, solutions or practical ideas to implement next. and that woukd be a waste of your (and everyone’s) time wouldn’t it? :)

1st Step – Basics

I would say, read this Open Space primer. So you’ll know the basic stuff and from there you can prepare a nice Open Space.

2n Step –  Mission

Define your mission. What are you trying to solve by gathering all those people?  What’s the purpose of it?

3rd Step – Invitations

You should do your list of people to invite and why.
It’s true that the more the merrier, because then you’ll have wider perspectives. On the other hand it’s also true that some people in your company  may not have anything to do with the thing you are trying to solve or improve (specially if it’s a big company) . So you might want to think whom it makes sense to invite.

4th Step – The space

Get a confortable  area, specially one where people feel ok to speak freely and to open their mind and heart.
It should be big enough for you to set up a big circle with chairs (to open the ..open space) and also big enough for people to move around the different topics while brainstorming.

5th Step –  Material

Prepare everything in advance. People should enter the room and have everything they will need ready. That may be:

– Pens and paper for people to right
– Flipcharts or other, spread around the room – preferably with the titles of what you expect people to do already written down.
– Chair disposed in circle  – circle is good cause everyone will be at same level, everyone will see the facilitator and circle provides a feeling of both closeness and safe space.

Also, put the Open Space Principles in plain sight (I’ll show you how below).

6th Step- The Principles, Rules and Roles

Open space has 4 principles:

1- Whoever comes is the right people

This means that the people that come to your open space are the ones who actually you want to have there, because they saw value in your calling and are open to share and help you out.

2- Whatever happens is the only thing that could have happened

Meaning that whatever comes out of the session is the only thing that could have happened. So this is about you turning off your expectations and just pay attention to what you are getting from the people around you, and know they are doing their best.

3- When it starts is the right time to start

As this is a brainstorm session, time is not that important. you should start when the people around you feel they are ready to do so. don’t make the Tic-Tac louder than their thoughts.

4 – When it’s over, it’s over

The session should only end  when people feel there is nothing else to talk about.

Open Space has 1 Rule (at least that I am aware off, if you know more please let me know!)

The law of 2 feet : whenever you are not learning or sharing anything, use your two feet and go away :)

Open Space Principles. I took the drawing idea from some other example in the web, worked out nicely :)

Open Space Principles. I took the drawing idea from some other example in the web, worked out nicely :)

Open Space Roles:

Butterfly – goes from one discussion to other, does not participate soa ctively, just observs and listens

Bumblebee : someone who jumps between topics but kind of cross-polinates stuff, so taking ideas of one discussion into other. (Bridging!)

Here's the drawing I did to explain the Roles. I'm not such an artist but people got the picture, specially the bear paws for my berlin community ;)

Here’s the drawing I did to explain the Roles. I’m not such an artist but people got the picture, specially the bear paws for my berlin community ;)

Details :

You should make the Rules, Roles and Principles big and visible in the room. You must also explain them to participants in the beginning of the open space. :)

Here’s how it looked on our big Wall:

wall-new

Have a nice Day! :)

Catia Oliveira

Advertisements

Creating your Scrum Cards – Free Template

Hi :)

So after writing about how I prepare my templates (Creating your own Scrum Cards) for the team to write down User Stories, Bugs, Tasks and Improvements, I got some requests to make my template available.

So here it is : US-Bugs-Task-ToPrint (excel format).
Normally I print them using the coloured paper I want (the colours I use are in the Sheet name) and then just cut them in batches using a paper cutter.

In case you you don’t have coloured paper you can just fill out the cells with the color you want and print it in a Color Printer.

Hope it makes your life easier :)

Let me know if I can help you or provide something useful for you.

Catia Oliveira

Creating your own Scrum Cards

Hi!

Quick Tip Today: Creating a User Story Card

You can use index cards and write on them, of if you are like me: a bit lazy but you like things pretty visible and kind of organized, you just have to do some tuned cards in a text editor (Word for 75% population), print them in different coloured paper and.. cut them :). They will them be the basis for your team to use in the
Sprint backlog.

Let me then share my experiments with my tuned Scrum cards.

Scrum Cards – Colour protocol

Red (or pink when there is no red) for BUGS
Green for improvements (of previous user stories)
Blue for tasks – (User stories are broke down into tasks)
White for User stories (US)

Scrum Cards – The templates

I create a template that I can print because I found most useful to have already in the card the following:

1- USER STORY card:
– User story number (if using a electronic Prod. backlog, you want to refer to the ticket number)
– US component- where this US fits in the big picture of our product
– Priority – we always start by working on most important US
– Estimation – the estimated Story points for this US (just for reference actually)
– UX – name of the Designer who created the concept, just in case we have a question (when having different UX people working with your team)

Looks like this:
USER STORY card
US Template

2- Task card:
– User story number (if using a electronic Prod. backlog, you want to refer to the ticket number)
– Estimation – the Estimated effort for this task
– DEV- the team member(s) coding it
– QA- the team member(s) testing it
– REV- Revision number – in which release we can test and find this task

Looks like this:
TASK card

Task template

3- Improvement card:
– Same as Task, but ..it’s a green card :)

Looks like this:
IMPROVEMENT card
improvement template

4- BUG card:
– BUG number (When using a tool to track bugs you want to refer to the ticket number in the tool)
– Component – to which component this bug belongs
– QA- the person that found the bug (important in case we have doubts how to reproduce and also to ask the person to re-test when fixed)
– DEV- the team member(s) fixing it
– REV- Revision number – in which release we can find the fix and test

Looks like this:
BUG card
Bug Template

Hope it Helps!

Older Posts that may interest you:
Creating Sprint backlogs (Scrum boards)
Dealing with Legacy Bugs- the BUGLOG

Dealing with Legacy bugs in Scrum – THE BUGLOG!

Hi!

After writing about Sprint backlogs – how you can create one and why it should be the big elephant in the room, I remembered we rarely see people talking about the nasty legacy bugs the scrum team gets during the sprint and how to fit them inside the sprint.

First a disclaimer: when I say bugs, I do NOT mean bugs from the User Story (US) currently being implemented by the team. If the bugs you find are related to the US in progress, then these bugs are part of the current work, part of the current sprint scope. So, when I say Bugs in this post I mean bugs that we have from previous User Stories, from Legacy code.. bugs that don’t fit the current Sprint Scope.

Have you asked yourself several times how to fit legacy bugs in a sprint without endangering the commitment? if yes, then this post might help you.

Scrum
Scrum framework has a very well defined rule regarding injection of “not committed” work: you don’t inject.
If you really need to do something not planned, then you abort the sprint and re-plan. This obviously makes a lot of sense, team has committed for a certain scope withing a fix period, if you add stuff and the time is still the same..well.. no can do. Abort and Re-plan a new Sprint.

Nevertheless this beautiful simplicity of Scrum, we know that life is sometimes not that easy and if a customer is complaining about a bug we should handle it and fast, so how can we do that without endangering the current sprint commitments and at the same time without aborting the sprint and re-plan everything again?

Handling Bugs in a Sprint

The way I found to handle this bugs was to create what I call the BUGLOG.

First step is both team and PO agree that one team member (or a pair if you have lots of bugs and need to keep knowledge in same level) will only be available to fix bugs during the sprint. Nothing else, just bug fixing. By one person, I mean any person, you don’t have to assign one team member in particular, the team members will assign themselves daily according to the bugs in the BUGLog.

As you break the stories into tasks and build your backlog during sprint planning (in order to find out what can you commit to), you will consider team availability equal to Team availability MINUS 1 team member.
Example, if your team has 8 people working, and decides to have 1 person for bug fixing, the team availability will be 7 people.
If you base your commitments on your velocity only, then you should commit to a bit less than your average velocity, because 1 person will be “out for bug fixing” :)… consider it has if each day the team has 1 person off for vacations.

Now that you did your sprint planning and you know which user stories you’ve committed, it’s time to build the BUGLOG:
buglog2

The BUGLOG is a second board, placed next to the Sprint backlog, having the TOP 10 most important bugs – the one’s that need to be fixed first (I use TOP 10 or 5, but it’s actually up to your team and PO to decide… if they are all minor fast-fixing you can have more, but for the sake of simplicity and quick visualization, keep it small… you can add more at any time!).

Team Members assignment to Bug Fixing

At this moment the team has it’s Sprint Backlog, with the committed Us and it’s BUGLog with the most important/ urgent bugs.
The same way the team looks at the sprint backlog and each team member assigns himself to a task (by picking a task which the team defined as priority in the current goals) the team also looks at BUGLog and checks current priorities. According to those, someone from the team assigns himself to do bug fixing that day.
(From my experience the self- assignee is normally the person that knows more about the bug or the area where bug is).

It is really important to repeat this : Everyday the team looks at the list and agrees on who will do bug fixing. Somedays the person from previous day decides to continue doing bug fixing because it makes sense. But the rule is that we all have our share of bug fixing.

We have now the team working in the Sprint Backlog and this Special Bug-hunter-of-the-day team member fixing bugs. Starting by the one in the top of the list and having as goal to fix as many as he can during that day! (you can even propose a contest ;) for the Mightiest Bug Hunter).

Team Synchronization
The assigned Bug-fixing team member should also be present in the team daily scrum. First because the next day he will be back to Sprint backlog tasks and second because it’s important for the rest of the team to know which important bugs were fixed.
My experience: I’ve always carried on the Daily stand up as usual, team members talking about their Sprint backlog tasks, impediments and together defining what to do next (team daily planning). The Team member doing bug fix would be the first or the last to speak during daily standup, about bugs fixed and any doubts or help needed to carry on next bug. We would ask this person to be the first or last talking because that way we wouldn’t break the flow of conversation around the sprint backlog when the other team members start speaking. But nevertheless this small thing, the BUGLog is seen as part of the overall team scope, just with the slight difference of being handled only by one person each day.

Deciding Bug Priorities

As the list gets smaller, with the bugs moving to Done column, the PO will decide which are the next most important bugs.
(In one of the teams I worked with, the PO received every morning a report from an offshore quality team with all new found bugs. In this case the PO would, every morning, look at the current list of ‘Not yet being fixed bugs’ and look at the report received from quality, and decide if there was any new bug more important than those already in the BUGLog. I so, then he would re-order the bugs.)

Conclusions of my Experience

This BUGLog actually proved to be a great solution to our needs:

1- Legacy bugs are fixed
2- You can also use this BUGLog to add small improvements in older stories or deal with technical debt if/ when that is your biggest pain point
3- PO’s are happy cause they see stories being done and bugs from the past being fixed, all leading to a more stable solution for our customers
4- Team is happy cause they don’t feel interrupted from their work in US and they can still fix nasty bugs they are worried with
5- Scrum master happy too, less yelling (kidding) ;), less: “we need to replan the sprint cause if we need to fix all that, we can deliver our US” and feeling of more trust between PO and Team, cause this system allows both to do what needs to be done without anyone feeling that unplanned things can’t be handled.

For me this proved to be a win-win situation, a tradeoff between both the Team, Po, current customers and..future customers.

Hope it helps you as much as it still does help me and my teams!

Happy easter :)

About Usefulness

This one will be short. Just want sharing something I just found out.

I realised every time I get up of my desk to pick up a water, a coffee, go to the printer, whatever.. I always also find someone looking for something, and meanwhile I also found out that I always manage to help those people by providing, replacing, solving or just suggesting another way/ perspective. How do I do that? I quite don’t now.. I guess I perceive and then listen and .. Puff! Done.

Along with that, I just realised that this is what I do best and that this is exactly what I fracking love to do. Solve problems and be useful to people when they need it.

I’m glad I found that. I just solve myself a big problem.

Carpe Diem!
Cátia

Building your Sprint Backlog / Scrum Board

Hi :)

Today a practical tip for building a Sprint Backlog aka Scrum Board.

Why should we have a board?



The board main function is to allow team to visualize remaining work (tracking) and facilitate daily synchronization (Re-plan).
Everyday the team gets together, looks at the board (which contains the committed work) and the team re-plans it’s day – What should we do today in order to accomplish our goal?

Because of this, Scrum Boards should be:

  • SIMPLE – don’t add to much columns and stuff not needed
  • BIG – Everyone sees it, knows where it is and just by looking knows where we are (regarding the team goal)
  • ACCESSIBLE – everyone can see it and update it – by everyone can update it I mean the team (it’s their plan, they own it)
  • FLEXIBLE – should be easily improved and adaptable to team needs
  • INTERACTIVE – appealing people to touch it and play with it (example, by moving cards from one column to another) – if you touch it and name it , you own it – yes, tasks are like puppies.
  • VISIBLE – the kind of : you can’t avoid it when entering the room – a good way of keeping questions answered without pressuring or interrupting the team


Paper or electronic ?



I say: something real you make with markers – so paper or whiteboards.

I can give you at least 3 reasons to stick with a physical board rather than using some electronic version:

1.  Electronic boards are accessible, but they are not visible (unless you can afford a big touch screen and display it in the middle of the room)
It’s true that everyone can access a drive or tool, but it’s not something you see just by entering the room. You have to log in, or search inside a folder, so it’s “Hidden”.

2. Electronic appeals to individuality – paper leads to collaboration

If you have a tool:

– you’ll update your tasks before the stand up for the sake of speed – with this you loose interaction

– or you’ll do it during the stand up- with this you’ll increase the time of the daily stand up (and create waste time)

If you use paper, you can speak while you move or edit it. Everyone around you, listening, will also see the task you are talking about

Just FYI, Science :), that Lovely Lady, says there are 3 learning styles:

a) Visual Learners (say around 60% people)
b) Auditory Learners (around 30% people)
c) Kinesthetic (tactile) Learners (around 10% people)

for more details check Neil Fleming’s VAK/VARK model and here .

This means that if you use a real board on the wall, people will not only listen but also SEE what you are talking about, and as you move your tasks through the board, you’ll also touch, perceive the tasks as something material, something that exists.
So with a simple board on the wall you can reach everyone’s attention.

3- There is nothing easier and simpler than paper/ boards to work with, update, improve erase, add…

By using a tool you are bound to what they have, or in case it’s your own tool, you’ll need to implement extra functionalities (and test it, and train people, and…) – while you are getting the budget or permission for this, I’ve meanwhile created zillions of boards with my team ;>.

So my advice is Stick with paper or whiteboards. Use it, improve it, reach the best possible solution. Then, if still you want your own electronic gadget, then… go for it and good luck :).

My board as an example



I made a draft of the board we use. – Sorry but I just can’t take pictures of our walls due to product confidentiality reasons. So if you like it/ find it useful you can just reproduce it in big size
(Extra Tip: don’t make it toooooooo big, else as it will look ‘empty’, everyone will feel tempted to add more tasks than those that can be handled).

backlog draft short

If you get back to the basics, Scrum boards have only 4 columns: User stories, Not started (tasks), Ongoing (tasks) and Done (done done, no buts-> done as in ready to go live).

Although I love simplicity, I’ve faced teams where QA was a bit forgotten. So we had to make this visible in order to deal with it.
These teams had no QA experts and developers would run away as much as possible from testing. When having just Ongoing column, tasks just stayed there in a kind of limbo or would go to Done without being really done.
So we split ‘”Ongoing” into DEV and QA.
Having these columns was the way we found to show exactly what was under testing and when this column grows bigger everyone knows it is time to jump in and do some testing.

You can have it or not, it’s up to you and your team. Some teams just create testing tasks and take them through the flow-> Not started->Ongoing-> Done. – Been there, done that – Works perfectly, but only if you have someone caring about QA inside the team, else, again, everyone will delay those tasks as much as possible.

My advise is: don’t get influenced by anyone, except by your team : Do what your team needs and then keep improving it. Target simplicity and transparency and all will certainly go ok.

Let me know if I can help you building your board or just share your own with me ☺ I appreciate new ideas!

Being a Coach

Hi :)

Here are some thoughts, based on my experience, about being a coach.

I realized it’s not about technology, processes and frameworks.
It’s not about teaching people how to do stuff, although it helps if you can show them a new way or help them finding a solution.
But that is not at all, the most important thing about coaching people.

Coaching is about inspiring.
People are smart enough to study stuff and find better ways of doing their work, but only if they are motivated to do so. Or if they realize they have a need and that they must create their own time for personal and professional growth.

My experience says that if you want to be a good coach, you need to: inspire people

Inspire so they feel motivated and eager to come to work
Inspire so they feel worthy, useful.
Inspire so they feel eager to learn.
Inspire so they feel HAPPY and FUN.

Inspire people to do and be better, to be all they can be, because that’s all they need: inspiration. Just a little push. All the rest they can handle it pretty well. And, oh boy!, once inspired you can’t imagine the potential ahead of you!

And last, but not least: Inspire them to be empowered.

Empowerment – not given but taken
Empowered people can change the world, or at least the things they touch. But empowerment is a tricky thing.
Most people, maybe due to education or culture, think that empowerment in a business environment is something that must be given by someone having a position of power. Meaning, if you are a developer you feel like you can only be empowered if you line manager or technical lead says so in front of everyone else.
This is not true. This is not empowerment- this is task attribution or delegation.

Life in an office is not that much different from life in… well, life.
As such, empowerment is not given but rather taken (taken as in assumed not taken as in steal for someone).
Once you put your mind to solve something in your personal life, there is no one who can stop you as well there is no one who can actually give you the energy and will power to do it, except yourself.
Same in office. You should not expect to be empowered, you should take the chance to change or do something and embrace the power and greatness of doing it. Take it, don’t wait for it.

Really powerful people are not in a power position, they make it. They are the one’s you recognize as leaders, opposite to those you consider just silly bastards with illusion of power, the one’s you comply with but whom you’ll never follow wholeheartedly.

Gandhi was a powerful person. And he did not have any high position in the hierarchy of kind lawyers, he was not DR. PHD Master MBA Mr. Gandhi. He was powerful because he chose to be so, he took every single chance to make the difference and change people’s life and or mindset.

It’s up to you to be powerful. It’s up to you to be different and drive for yourself your own path. If you choose to do so, then, you might as well consider yourself a coach.

What about people who don’t want to change?

Yes, they exist. Sometimes out of fear, sometimes envy, sometimes ignorance, but yeah, they are out there. You can bring knowledge to people, but only if they want they will learn. And some, let’s face it, just don’t want to. And that is ok. If we were alike and all inspired people, life would be boring and expectations too high.

So, Know when to give up. Some people don’t want to change and they won’t let you do it. Just go and use your energy somewhere else. You deserve it, as well as all the others waiting for you to arrive and waiting for the chance to evolve with you.

Expectations

Expectations are good, they drive you. They help you aiming and they lead you there.
But, on the other side, expectation can also be a time bomb in your hands.
I’ve always had problems managing both my temper and my expectations. I’m not a patient person, so it’s really hard for me to contain my expectations to a sane level.
If, on one hand, this is good because it helps me eager and open for growth and new experiments, on the other hand it’s a big problem because I may never be satisfied with what I’ve achieved.

So, my personal advice, coming from my own pain, is: Plan your expectations.
For example: Write them down in a paper whenever you accept a new goal. Then, just track them down. Once you’re done or the time is up, you’ll know where you are and how far you are from your initial expectations.

Things will evolve and I really hope you add more and more expectations to that plan of yours, but the point here if for you (and me) to be able to look down to that plan, and know that your achievements are actually good, and although it may feel like they are not, you’ll (we’ll) know that this is only our big-mouth expectations talking and trying to trick us by overlooking what has been achieved.

I once heard a sentence from a writer I never forgot, because it makes a lot of sense on my way of living, he said: It’s extremely arrogant and hypocrite to judge the past, having the advantage of being in the present.

This is how I always managed my expectations. I would judge what I did, but having as basis my current mindset. And that is wrong. I should always fit the results into the expectations defined at the time and considering the situation when they were set.

I did that, now I won’t do it anymore. I learned and now, I know better.

Have a nice weekend, and, please… Go make the difference is this little world of ours.

%d bloggers like this: