The sound of Silence (or one hand clapping)

I think it was one of the greatest philosophers of our time who said: "The face of a child can say it all, especially the mouth part of the face" .

I led a workshop a short while back where I experienced how powerful silence can be, and I’d like to share it.

But first…

.
.
Imagine this post would end at the line above; perhaps you’d scroll down, but find nothing below…

How would you feel?
.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

...

You would have either of the following reactions (I guess)

• Oouuf, that crazy bear, had’nough of him…
• Oouuf, that forgetful bear, again he forgot to save the whole post before publishing
• Hmmm… I wonder what he meant to say…

And that’s the power of silence; it forces the listener to deal with the void, to fill it with her presence, her reflections, etc.

This works in music (in its simple form, think of how your brain is trying to guess where the song continues after a pause, to the extreme, remember the John Cage piece…), in art (think of a Rothko painting) and for sure in agile-coaching.

A while back, I read a post by an agile coach who was really proud of how he solved a problem between the development (who was producing too much to be tested) and the testers who were not able to follow up, he located the problem, named it, called the teams in (mid sprint), and presented the problem he saw and the solution (VSM). I would have probably taken another way of action:
- do nothing. 
- see what happens. 

A solution to a pain is always stronger if the pain is strongly felt by the team and not by the coach... and who knows, perhaps your perception is wrong. 

So this is a segment of my response...

My response may be provocative, but I am known for this, I hope you find it interesting as well..

Seems to me you located a problem, explained it to the team, and introduced a tool to prevent it.

I’d consider a totally different approach, which is to do nothing, and let the problem happen…

I’ll explain…

Supposing your assumption is right, the sprint would have finished poorly, perhaps even failed, which may waste some work (not a lot, I’d say a few days… since dev was done) but would produce a heated retrospective perhaps some conflicts between QA dev and PO
And THIS IS GREAT! it will boost the team’s maturity and spirit enormously (if handled correctly, and remember – the retro is YOUR tool, this is where you can effect the team the most)

But what if your assumption is wrong? what if the sprint would’t have failed?
what if the QA is overbooked because they over-test? in which case there would be not so many bugs, which may lead to a change in the weight allocated to testing.

When explaining what YOU see is wrong (and you said you had a hard time to do it), and putting a tool in place, you are (IMHO) blocking the growth of the team.

And now for the hardest part for me, an apology:
- It is so easy to interpret a story when it is given to you all wrapped up and you are not involved, I remember how I was so proud with some things I did with the team, and felt so stupid when re-thinking about it months later

In the workshop last week I experienced the power of nothingness first hand. For example – the participants split into teams to gather findings, and then I asked them to present their findings to everyone.

After the first presentation they looked at us (the coaches), I waited a bit, than asked them if there are any questions to the presenter, and then started clapping (everyone joined) and invited the next presenter.

After the second one finished, they looked at me, and I did nothing… fifteen seconds of awkward silence (god – it seemed like eternity :-). 

Than someone started clapping hands, so everyone joined.

When the clapping ended, another awkward silence… people looking around – now what?! Until the next team’s speaker said “I guess now it is my turn” and got up.

For the next presentations - their 'routine' was easier, and they didn't even look at me... hence they took a step toward independence and self organisation.

I hope I made my point, just wanted to add it is not easy to be silent (certainly not for a blabber-mouth bear like me…) which makes it a great experience.

And of course - sometimes you DO have to say something... (@ least I do...)

Would love to hear your comments (silent comments are of course welcome as well :-)

Till nextime!

Yer Bear.

Oh, the Places You'll Go!

Dedicated to the late great Dennis Potter, half of this post is published in this blog (call it the left side of my brain), while the other is published in the competing blog (right side, etc.)

The two posts are independent, but inseparable.
The Corpus-Colosom part is for the you to exercise (or not).

Before I begin, I want to say something.

In a company I worked a longlong timeago, every employee (all over the world, thousands…) received one day a brown envelope with a book and a small handwritten dedication by the VP. The book was "Oh, the Places You'll Go!" by Dr. Seouss, 

I remember the strange looks on the faces of most of my colleagues, (one that had the air of “we would prefer a bonus…”), and I also remember my thoughts, it was clear to me this guy tries to speak American biz-lang to Israelis, that he wants us to identify with the company and this is a sincere ‘technique’ to do that.

Now looking back, I have a different view of what really happened.

• One evening, this guy read a book to his kid.
• A chord struck, he felt – hey! my company is an adventure, just like this book!, its future is open!, this book is about my company!
• Than a crazy thought emerged: I have thousands of mates on this journey, though I don’t know most of them they are what this is about, they share my vision, I have to show them this book, they will understand!
• And that’s what he did.

But he lost most of us…

(I still don’t like the book, but now I appreciate his courage)

I don’t know what the moral of the story is, but I know what I’d like to say.

• In the last few months I’ve been having life changing experiences I want to share.
• Lots of you don’t know me, of those who do, some of you don’t, of the rest, lots of you won’t understand what the heck I’m talkingbout.
• If this is the case, feel free to ignore this post. (as you always are :-)

So now, that I got this out of the way, I can start.

A vision is a motion, if we talk Agile, a vision is an everchanging beast that changes form and direction.

I had the fortune once in my life to be a friend and a coworker of a visionary, someone I would have followed blindly to the end of the world and beyond, but I am starting to realize I totally misunderstood his role and the way he perceived it.

He was no visionary, he was ‘merely’ a focal point to the team’s energy, he would come up with a grain of an idea (or would embrace one of ours) and let us toy with it, let us lead it to where it rolls.

I don’t know if he ever realized that’s what he does, he was just thankful enough we played on the same team.

His CV doesn’t mention anything about this, but he breaths agility like a fish that swims in water, not realizing the name of this stuff, or even that there is something else.

Though I didn’t speak to him in ages, he is still my best friend and zen-master, the one who taught me everything I know.

Recently, I have a feeling of a double-déjà-vu.

• I met his twin, only this guy knows formally what ‘Agile’ means, since he comes from that methodology/ state-of-mind, whatever.
• I was (and still am) lucky enough to feel the sensation myself, to form a team (see my last post), and experience the sensation of taking responsibility for a group, lead it without knowing where it is going, play with it, see it take a form that is beyond the individuals in it but that consists of every participant and her (there are more she than he there :-) interactions with the rest.

Perhaps I’ll talk about the first point another time, I’d like to keep you up to date about the second.

So where were we?

As I said last time, our weekly meetings are ‘managed’ by me, and I wanted to see what happens if I give them to someone else. Last time we chatted at a coffee after the meeting, and I asked a fellow team-member if she wants a challenge, she jumped right in with great joy and no hesitation…

Not only that, she was stupid enough to pick a subject I knew is hard and frustrating, we worked only with a pencil up to now, and she picked colors as a subject. I don’t understand the first thing about colors, and I’ve been drawing for decades (wow… I really have been…)

And not only that, she didn’t even start to realize what a big responsibility it is, I mean, we talked a bit, she was happy to get any advice, but took it over-easy.

It is so frickin hard to let go, man, I’m tellin ya, till you built the team’s confidence, you invest your soul in it, and you give it to someone who will surely break it.

And on top of all this, she had our meeting at the museum of modern art, what’s there to draw?! Where are all the realistic sculptures with the fine details whose soul we wanna capture?

At the last minute I managed to save the new-comers, I thought that veteran members can withstand a session like this, so I left them at the hall of the entrance, gave her my phone number (for when she will need me, for sure she will need me!), an went to another floor with the new ones.

Such a great team of newcomers it was, but so fragile, I was grateful I didn’t leave them with her.

And you know what happened, right?

It was THE AWSOMET meeting we had so far!

This girl was rockin! The team was flying! You could light up all of Paris with the electricity the team generated (the color session was held in the electricity hall by Duffy)

I’m so ashamed of my doubts; I know I could and should have let her have the new-comers…

I will publish some of the work we did (I had the time to participate a bit) at my other blog, but I am not talking at all about the product.

The PROCESS was awesome! The exchange and the teamwork, she made everyone work with each other, and to start from the least expected.
At the end (demo?), some members didn't know who did what...

You know the funny part? at the coffee we had after the meeting, (where unfortunately she couldn’t come) they gave her complete ownership of the meeting, but they gave me complete ownership as well!

And the really funny part? I proudly accepted it!

Thank you Mari, Thanks A. Thanks K.

And a HUGE thanks to aaaall the team members (some of the things you said or wrote me almost made me cry…), I wish to god (wherever she may be) none of you reads this post…

Till nextime!

(BTW, I still took the last ten minutes of the meeting to do my crazy sh**t, otherwise I wouldn’t have been…)

The Scrum’em bear.

What's in a game?

Pssst.., I have a secret to tell you...

- I don’t really like games...

(luckily no one reads this blog, or I’ll be kicked out of the virtual Agile community I belong to.)

Yea, I know some explanation is in order, but first, what the heck am I talkinabout?

Games…

Agile games are a part of the Agile coaching toolbox, if you want the team to experience the  importance of small increments of work, give them a task of flipping coins two times, and measure different strategies (groups of 50, groups of 10, etc.), if you want to demonstrate how a spec is less effective than talking, ask someone to write textual instructions of how to draw an image, and someone else to following them from the doc.

The result is usually fun, the team laughs, gets to discuss the different approaches, and end up feeling they learned something….

So  what’s there not to like ??

First of all, it always seems (to me) superficial, and I get the impression it is too detached from the team’s reality, so in real life, they may say to themselves: yeah, but this task is much more complicated than just flipping coins. Or : this is a component the team will surely understand by just reading (and besides, I hate talking to them, they always waste my time, an they are offshore with a strange accent)

Second, I don’t like running a game who's result are expected, if this is a game, I want to be a part of it!

Third, it is often considered by the organisation as a waste of time, and though they are probably wrong, it may create hidden resistance to change.

Solution ? Gamify life (Danko’s Ducks, and more...)

In fact, the alternative was clear for me all the time, but it clicked when I read the following technique (called Danko’s Ducks*) :

Problem : In the team, people tend to cut each other off, which turns discussions to noisy debates.

Solution : Buy a bunch of cheap rubber duckies, and at the beginning of the next meeting give each participant one, with the following instructions :

1.       When you are cut off, or you see someone being cut off, squeeeeze yer Duckie.

2.       When you hear a Quack, squeeeeeeze yer Duckie.

3.       Repeat.

Result :  First meeting, you will have tons of endless quack waves (and laughs), second meeting you will have one or two, and that’s it.

See the difference ? the ‘game’ is introduced to the system, so it is much more effective.

Once I defined it to myself, I realized it was there all along, here are some more :

Vincent’s Mic (**).

Problem : At the standup, people cut each other off, and don’t know who’s turn it is.

Solution : Get a broken microphone you found in the junkpile, and ask people to speak to it.

Result : people hold the mic, do a make-belief fooo-foooo into it, pass it to the left, works like charm ! and the unexpected result: people suddenly speak clearly! and to everyone!

Nicola’s Timebox challenge.

Problem : Team doesn't jump to the water of self-management quick enough.

Solution : See below.

At the end of a long Friday, after a long demo, we scheduled a retro meeting, I ask the team what’s the timebox, and someone (let's call him Nicolas...) smiled with tired eyes and says –« five minutes ?! »

Everybody smiled, so I timed five minutes...

It was finished in four (followup, high/low points and action items)  (***)

Result: the timebox setter role was gladly passed to the team.

Conclusions/ call for action

I have lots of other examples, the thing is this :

I know sometimes things are not that easy, some radical principles take more energy and effort, but...

We are so used to the work/ play separation, that we are either in a work mode or a play mode (and sometimes it is even worst since when we learn we often are not allowed to play and are not considered qualified to work, 

A game you find inside the work-space may be a great tool to examine and change behavior, enhance creativity, break barriers and lighten things up...

Look for it! I am sure it is just around the corner!

And once you do, spend two minutes searching for a catchy game-name.

And if you have great game@work stories, comment below.

Notes

(*) I won’t tell you who invented this technique, since he specifically gives up any rights or credits in the preface, I’ll just hint that his funny and imaginative book (titled advanScrum) can be downloaded freely here, but fortunately for some, only a Hebrew version is available thus-far.

(**) This one is by a good friend and colleague, I don’t know if he invented it, since he is often too modest to take credit for stuff he comes up with.

(***) you can find in the book above a section about Blitz-meetings, but since I've done em first, (including a red-alert-all-project-management-post-mortem-timeboxed-ten-minute one (with conclusions, action items, and some angry-birds) no credit is given.

Till we meet again.

The Scrum'em Bear.

Oh my...  (giving credit when it's due)
I just realized the grain of this idea was instilled in me when seening this video by Dan Mezick   
So many Dans in one post...
I'm done.

Agile drawing

This time, a personal story.

a few months back, I started a group whose goal is to learn creativity through drawing. (I don't tell them that, I tell them it is to learn drawing through creativity :)

After some sessions, I want to share some observations and thought I had thus far, I'll share just facts, any connection to Scrum/ Agile is purely coincidental.

(BTW - For some details on the group itself, see here )

Creating & maintaining the group

• When I created the group, I didn't know what to expect, I had some vision but didn't know if I can manage a team, who will show up, if I have the authority and knowledge to pass my vision on, etc. the only thing I was certain of is that I adored my old teacher and his ways, and I want to pass what I learned on (since life taught me teaching is the best way to learn...).
• I've set a location, a date, wrote a draft for the agenda, and (as they say here) Voila.
• Once started, it just worked. we set up a regular rhythm (weekly Sundays), a regular duration (3.5 hours) and the team's life is formed.
• My preparation before a meeting consists currently of writing a loose agenda, deciding on the location, and arriving on time.

Content

• The team's goal was not really clear for me at the beginning, nor were my motives, they are becoming clearer (and changing) from session to session.
• My role in the team is mainly to mediate, I spend considerable attention every meeting with newcomers, but after one of two sessions people are independent, even though each meeting has new exercises and challenges.
• During the meeting, I seldom draw. the main thing I do is watch the team members to detect whether they are bored, confused/ threatened or challenged/engulfed, and try to see what (if anything) I do with the first two, and how I stay the heck out of the third one.

Session structure

• Planning: every session has a place (a free museum in Paris, since it is warm and free, and there is always something to draw) and a theme (lines, textures, etc.), which is published and discussed with the members when we start.
• Drawing: People just draw, within (or without) the themes defined, some alone, some in groups, they peek a bit at each other's work, discuss, and encouraged to mainly produce a lot and not be afraid of failure. One rule I strongly insist on (mainly with beginners) is that no erasers are allowed. 
• Demo: This is THE fun part, we find a corner in the museum, sit in a circle, and show and discuss the group's work, hence - everyone takes all the stuff the person to the left did, and picks up to two works that he likes or is intrigued by, and than shows them to the group, explains what he likes and lets the others say what they think.
• My role is to make sure everyone sees the drawings, everyone can hear what the person is saying, and that the speaker talks to everyone.
• People select and talk about other people's drawings because most people feel they draw much worst than the rest :) .
• When people discuss someone else's work, they really look, they don't just say "I like it", but stuff like "I like how the movement start from here..." or "The horse looks like it is scared" 
• The people who made the drawing are often amazed about what other people say about their work, not only that someone likes it, but why. what others see. that their work is viewed seriously, and they look at the discussed drawing differently after it was discussed. (I see this as the biggest gift people receive and get during the whole session)
• I sometimes ask someone (who is too quiet:) to say what he thinks, most of the time (s)he has interesting insight.
• If there is time left, everyone gets to pick one work he did that was no chosen, show it and say what he thinks on it, people are encouraged to show works they are unsure about.
• Retrospective: people talk a bit about their experience, was it too hard, too easy, what did they learn, if someone did an exercise that may interest the group, I ask them to explain what it was, ask people what they thought of the place, the structure, and if anyone wants to discuss or ask the group anything. 
• Celebration: go to a café and have hot chocolate.

Some particular points I wanted to mention:

• Pair programming: At today's session I tried to pair two people, and have them switch drawings mid-way, starting with two more experienced members, and when it worked invited more members, conclusions:
• Had this idea for some time, but was afraid to do it since I though people would like to hold on to what they did, or feel uncomfortable when they 'ruin' someone else's work.
• Actually, worked great!, people laughed, were happy to have the right to mess with someone else's work, and said they learned a lot both by letting go, and by seeing how the other person adds qualities they didn't.
• Inventions: people invent their own games, drawing on top of an existing drawing, switching medium, etc.
• Participation: the group is open, and anyone can join. some people register and don't show up, some show up but don't step up (don't play the game..), I try to focus on the rest.
• Watching: not all participants have the same visibility, I ask myself who is less visible and try to pay them more attention.
• Freedom: the main feedback from members is that the group frees them, that it is a place with no judgement. where anything is allowed. 
• Challenge to step up: today I invited someone in the group to take my role next time, and she accepted! I am curious what will happen next, how much will I be able to let go?

To get the answer to the last question, you'd have to wait for next time!

Hope you found the relevance to Scrum and Agility, 

BTW - I just counted, this blog contains more than 30 times the word 'I', I know, it is my blog ;)

Till nextime!

The Scrum'em Bear.

Oh, and for the hebrew readers among you, forget everything I write and read this post from my absolutely favorute blogger

Backlog to Planning with minimal risk

Warning: a serious post, beware!

This time, I'd like to share with you the (what I find) effective technique of choosing sprint candidates, estimating as a team, and choosing the tasks to implement on a daily basis.

Intro:
The sprint planning main goal is to plan well the tasks we can do, not waste time on tasks we won't do, and understand their complexity as a team, right?

So let's split it up:
Before planning:
- Find the right sprint candidates
During planning:
- Estimate tasks until sprint planned capacity is reached.

Finding the right sprint candidates:
Before the sprint we try to sort the backlog so the quicker wins will be on top.

- Assuming the backlog is detailed enough to work with, the Product team attaches to each requirement a business value (1: lowest, and in the good old Fibonacci progression)
- The team's most senior developer assigns an out-of-the-cuff estimation (allowing a 400% margin of error, a really quick pass)
- we divide the Business-value by the Estimates, and receive a new ROI value.
- all items are sorted by it, and the PO picks the ones that he wants done, but takes into account (with a grain of salt...) the ROI value.

This way, we don't waste time estimating (let alone developing) things with lower value, unless PO insists (which probably means the Business value is higher that was noted...)

Estimates during Sprint-planning:
- Take the backlog items (chosen by the PM) one by one (sorted by initial ROI) and estimate them.
- When you finished the sprint's capacity, you are done.

However...
Time and time again we ran into a problem which we all know too well...
- Estimates are varying, and often the shy estimators lose
- Tasks sometimes take longer than expected.

Why?
So we though hard about it, and realize some tasks are riskier than others, causing both great amount of variance, and depassing initial estimates.

Solution:
Aha! - this is where we found the trick that shortens our estimates, and makes them more accurate than before...
During evaluation, a lot of time is spent because:
1. It is unclear how a requirement should be implemented.
2. Sometimes it is in the domain of expertise of one developer, and another doesn't know how to estimate.

So one estimates the task as a day's work, another as four days, there are some discussions, re evaluations, and sometimes someone just gives up to move on...

This is why we came up with the risk evaluation of a task:
- By default a task has no risk (hence we commit to its value)
- however, if estimate divergence is too high, or if all the team agrees there is a risk, we agree on the estimate, (a team member that doesn't know the code well enough can accept the expert's opinion...) but than ask everybody to define the risk (1: 25%, 2: 50%, etc.) and write down the highest one.

Now we commit only to the tasks with the risk included in the estimate, but try to implement at the initial estimate. hence the PO knows what is the minimum to expect, but also that we will probably produce more.

A few comments
- For each task, we record the two values - with and without risk, so the developer knows to aim at the no-risk planning, but feels safe to depass it for a risky task.
- Every task has the ROI recorded as well, so a developer would rather start during the sprint a higher ROI task, hence if not all task were finished for the sprint, still the effective ones were.
- And of course, the process is never automatic, ROI helps us choose, Risk helps us estimate better, but common sense always rules! (or at least should...).

Till nextime!

Bad hair day

I think it was the Dalai Lama who said - if you lose, don't lose the lesson,

My last post (real life, not blogging) was an effort to manage a project the scrum way, and I admit (to myself, at least) I failed miserably...

So, in tribute to the Dalai, what lessons did I learn about Scrum implementation?

Or: subtitled, warning signs in scrum implementation.
Before starting, two comments:

1. This post's sole purpose (except entertain ya) is to serve as a postmortem checklist for the health of your process.
2. A small disclaimer, as all of my posts, this is just about me, highly subjective, take it all with at least one grain of salt,

Or in other words:

And now for the list, bottm-up:

Development team side:

1. A team member refers to the sprint as your sprint (example phrase: "this is the last time I stay late for your sprint").
2. A team member states he knows what scrum is, and that you don't (example phrase: "this is not how scrum is done, in my previous company we did scrum and there was a full spec for the whole version before we started the first sprint").
3. A developer does stuff that is not required for the sprint, but that he believes is required in the 'final' version, and than complains he didn't get enough time to deliver his task. (example phrase: "no need for a code review, I know my code sucks, but I had to implement two servers that communicate between them, since otherwise the solution is not scalable and the final product will not support high load, and that's why the two day task is not finished though I am working on it 6 days already", sometimes followed by "I need just one more day")
4. Team bonding: when the only glue the team has is the the consensus about failure/ how the product sucks/ how the QA or Product manager or whoever doesn't know his job.

Product management:

1. No vision: the question where do you want the product to be in 1 year? two? five? meets a blank stare.
2. Constant panic: new urgent customer needs bypass the sprint, one product is stopped mid way to start a second one, which is stopped midway to start a third one.
3. 'User story', sounds like a strange concept, and the delivered spec has redundancy, contradictions, and outdated sections.
4. Everything is top priority.
5. PM located on a different floor than dev (higher).
6. There are several PMs, each with his own priorities.

Organisation:

1. No space is dedicated for the team (no wall can be dedicated for the daily standup, no whiteboards in any meeting room since all walls are made entirely of glass (on which you are not allowed to write on with a marker), except for one with a plasma TV.
2. Your manager (the one that hired you to propagate scrum to the system) calls all the project managers one day to a meeting where he announces that today is his last day on the job, and wishes you all luck..
3. Management doesn't know team members by name, and presents yearly plans without consulting the team.

(last but not least...) You:

1. The days you come to work optimistic/ happy/ motivated get rarer and rarer.
2. You start a blog-post with everybody else's symptoms and put yours in last place.
3. You stop doing Scrum, (and no one asks you why)
4. You stop publishing the Blog you started on scrum, since you have no positive experience to share.
5. You start looking for another workplace.

Here's lookin' at ya, Lama!

- Till nextime!

Time (is on my side)

Sometime you realize how disconnected you are from someone else's reality only when it hits you in the face.
Following is a word for word transcript of a totally fictitious conversation...

- I don't understand, why should we start the standup at 10:00 sharp?
- Because it is the time everyone is already in, why is it a problem?, we can make it 10:15 if it is too early.
- No, if it is exactly on time, than if I start something before that, I have to cut whatever I am doing for the standup
- Yes, but you can plan your time, don't start anything big before it, and just prepare for the three standup questions one minute in advance.
- But why can't we have the standup when I am finished with what I'm doing?
- Because this way everyone else would have to wait for you.
- Hmm..., OK, so let's start the meeting everyday when the last person of the team shows up!
- Don't you see it is worst for you? this way you will cut your work unexpectedly, and what if when the last team members arrives, one of the existing ones take a coffee-break?
- So let's do it everyday when everyone can.
- RRRR... OK, It is at 10:00  because I reserved a meeting room for this hour, and it won't be available later!!!
- OK, OK, dear lord..., why are you shouting?