Monday, November 21, 2011

Tips for keeping focus

Keeping focused on an activity can be a daunting effort - you know you need to do something, you sit down to do it and you might even get started - but before you notice you get a phone call, an urgent email, you get distracted, forget what it was you were trying to do, start a different task, give someone some help and BAM! - the day is done and what was is that I was going to do today?

This is true in almost any field of life - for children that need to do their homework, for managers needing to draft a budget or prepare for a meeting, at home when we want to make a meal or clean the living room with all the kids running around... 

Even in an agile workplace where it's natural and accepted for team-members to "swarm" together on a task or keep communicating between themselves and with the PO/SM, there are always times when we need some quiet-time without distractions to get something done - be it a team-member that needs to get a technical task done, a PO needing to groom those stories, or a scrum-master needing to prepare a retrospective or go over some metrics to figure out how to help the team further.

"Mel is out of focus!"
Focus is one of the five Scrum values, but it's not just a scrum-thing - it's an everyday life skill. So what is focus all about anyway?

In the Woody Allen film "Deconstructing Harry" (1997), Mel - an actor - is literally "out of focus". He is not only blurred in film but in real life.

Sadly departing from this comic interpretation of focus, seeking a more relevant definition from Wikipedia brings up the following:

Focus (cognitive process), selectively concentrating on one aspect of the environment while ignoring other things
http://en.wikipedia.org/wiki/Focus

So focus boils down to paying attention, taking into consideration that there is a limit to how much we - as human beings - can process and keep in mind at any given moment.


  • Focus is giving full attention to only one, relevant part of the big picture, intentionally ignoring other parts.
  • Focus means keeping concentrated on the task at hand - not getting distracted.
  • Focus means staying relevant - working on only that which is needed, avoiding the unnecessary.
  • Focus means doing all this while keeping a clear mind, staying effective, avoiding fatigue and keeping fresh.



Here are some tips to help keep focus:
1. Clear your desk:
All you usually need on your desk to get a task done is a computer, a block of paper, a pen and a timer (more on this later).
The more clutter you have on your desk the more clutter you'll have on your mind, So just take everything off - even if you don't have time to start sorting all the papers and notes,
Clean desk = Clean mind.

just put them aside in a pile for now. You'll have a chance to sort them out later.

If you find your computer screen is all dusty and your keyboard is blackened with sticky remains from late-night eat-while-you-work sessions (we've all had them) - take a few moments to clean the dust and wipe the keyboard. This too can have a magical effect - clearing your mind to keep fresh and focused on the task at hand.





2. Use the Pomodoro technique:
The idea is simple - work for 25 minutes (this is called a "pomodoro") and then take a 5 minute break. There are many specialized timers and lots of articles about the technique, but basically all you need is a timer and some practice.

I use a simple cheap sports-timer that beeps 10 minutes before the time is done and again 5 minutes before - that addition is great for getting a sense of "almost there - let's start summarizing". 

My timer - Six minutes left
until I take a break..
While you are working (in the 25 minute timeframe) - keep all distractions out, close the door if you can, don't even answer the phone or look at you emails. You'll have time to look at emails and return phone-calls during the 5 minute break or if you'll find you need to dedicate more time for them - you can do it after you finish one "pomodoro" and before you start another.

During the breaks - you might want to really go out and take a short stroll, go to the toilet, get a drink of water, make some coffee, read an article in the internet, or even go help someone with another task - but be sure to take those breaks from your current task! They are really needed after a concentrated 25 minutes of focused work and sometimes they can let you "zoom out of focus", seeing the big picture again and get an important "aha" moment - realizing things you've forgotten or overlooked.

If people physically approach you during the 25 minute session - take a look at the timer and politely ask them if you could get back to them in 13, 17, or 8 minutes - whatever the timer says is left. Be sure to take a note of getting back to them - really write it down - it will be both useful for you to remember to do it without having to actualy keep the reminder in your mind, and will show the other person that you are taking him/her seriously and not just waving them away, so they will be more comfortable leaving you alone to get your work done.


Child-sized Pomodoro:
My 9 year old once had a big homework assignment and could not keep focus on it, it was just too big and he could not "see the end". I suggested he split up his work into short cycles and we decided trying 15 minutes homework, and then 10 minute breaks (including snacks of course!). This helped him keep focused on a small part at a time, as well as keep the breaks in sight - all in all reducing stress and making the homework manageable for him. 
This has been working out great ever since - except sometimes I find my timer has disappeared from my desk and I need to go looking for wherever he had left it....


3. Use a shopping list:
When going shopping at a supermarket, everyone knows it's best to use a list - that'll make you remember what's needed and avoid getting things you can do without. When working on a task this is true as well.

When you start the task - make a list of the specific things you need to "shop for" - for example if you're working on a coding task, you might write down:

- get data from the external webservice
- format the output
- handle null values
- run the acceptance tests
- check into the CVS

As you work on the task be sure to attend only one item at a time - just like in the supermarket, you can't really get both the milk and the bread at once, and trying it will just get you into trouble. Tick off the items as you complete them and go to the next one, until you're done.

Here is my shopping list for this blog post -
I guess I can tick off "picture of shopping list" now,
but I just realized I'll need to add "layout pictures" :)
Throughout working on the task you might realize new items you hadn't thought of before (like in the supermarket - "Oh, I need sugar as well!") - in that case, just add them to the list and keep focused on the item at hand, knowing that you'll get to cover all the items before you're done.

Some of the items you might realize don't really belong in your current task - for instance, you might suddenly realize some code you've written requires a redesign in the UI, and the UI guy is doing that task. Or while grooming the backlog you'll realize you need to talk to a stakeholder about a story. So write it down anyway, so at least once you're done (or in the next pomodoro break) you can go to the UI people and inform them of the required changes or schedule a talk with that stakeholder for later in the day.

Although there are many neat todo-list apps out there, try and keep it low tech - a piece of paper is best. If you absolutely must type the list - just use Notepad, and don't bother saving the file when your done. The most high-techish list I'd recommend is for programmers, where the IDE let's you put in task-comments. Visual Studio has this feature - so when you type a comment starting with "//todo" - it'll appear in the "tasks" window along with other todo's, and double clicking an item in the list will bring you directly to the line containing the comment. But at times even that will be an overkill.

All in all using a shopping list is like having a "mini DoD" - tailor made for the current task. It lets you know when the task is really done and helps stop delaying declaring it done. When you've got all the items on your shopping list - it means go to checkout and head back home.

4. Turn off those notifications:
Most email programs like MS Outlook bring up a little popup or ring a bell when a new email arrives.
Do yourself a favor and turn those notifications off. These are distractions, and unless you're expecting a really urgent mission-critical notification such as a stock buy/sell notice or a rocket crisis alert - it's most likely that any email can wait up to 25 minutes before you reply or even see it. 
Same goes for instant messaging apps - you'll be best to have those off at least until your next break.

Don't play a sound, Don't briefly change the mouse cursor,
Don't display a new mail alert.. JUST SAY NO!
I cannot stress this one enough - as simple as it sounds - so I'll just stress it again. Really turn them off.

Trust that if a real emergency comes up - people will either come to you in person or the phone will keep ringing and ringing until you pick it up. Save the distractions for only the absolutely urgent emergencies - such as if the baby cries - as mine just did..

5. Inform others of your efforts:
Rene Descartes shut himself in a room so he could focus on his existence (Meditations of First Philosophy - 1641). Most of us however don't have that  luxury - our distractions come from working and living with others.

"I don't read emails, Therefore I am"
Descartes got focus!

Picture By After Frans Hals
[Public domain],
via Wikimedia Commons
So inform others of your intentions to keep focus - share your shopping lists, show off your timer, inform others that you don't read emails while your focusing on a task and that you do take breaks. This will make it clear to others that you're not just being unsocial but are doing your best to get work done, as well as defining your boundaries as to when you can be available for both socializing and working together.

Ask for help - another team member might be willing to keep on the lookout for when you are losing focus and remind you to get back on track, or they might take on the role of intercepting external interruptions while you're focusing on your task. Take turns at this helping each other. When pair-programming, have the "navigator" take charge of the shopping list, taking responsibility to keep you both focused on only what's needed. When the task is a meeting - have someone be responsible for tracking time and keeping everyone focused on the meeting agenda. This is not being a "meeting cop" - it's helping everyone keep focused and efficient.

Especially when working in a team - if everyone agrees on using pomodoro's, have the pomodoro's synchronized so they start and end at the same time, giving everyone a chance to spend the break together, or to start a task coordinating together before splitting up. Sometimes one team-member might take the role of "time-master" - being responsible for the timer and telling everyone when it's time for a break. This helps build up good team dynamics as well, so long as it's agreed on by everyone and not imposed upon.


*** updated ***
6. Pair Programming
My colleague Inna Korochik reminded me of this one - thanks Inna for pointing it out, as well as for the other valuable feedback!


Pairing is by itself a good means of keeping focus. As the song goes - "Birds do it. Bees do it. Even educated fleas do it" - and in fact policemen do it, aircraft pilots do it, and so do students crunching for exams - working in pairs is a well known means for staying focused on the mission in hand, having someone other than yourself guard and guide you from drifting astray and letting you focus on just doing the work.

Surprisingly (or not) - this is one of the most controversial subjects in the software industry, although pairing is a well-established best practice in Agile software development. If done wrongly it can be a waste of two workers time, but if done right - it can maximize both their time and let each member amplify the other's abilities to reach a point where 1+1=3.
***************


Focus on Focusing:

Keeping focus is not always easy, and not always fully achievable - there is no "100% focus" (unless you're Descartes of course). It is however something that can be reached for, and like any other skill, the more you practice it the better you'll get at it, until it becomes a second nature.

Losing focus means losing time, and time is one of your most valuable and ultimately limited assets. Respect your own time by doing an effort to keep focused, and others will respect your time too. Respect other people's time and their focus - don't be a distraction. If you're asked to wait before interrupting someone else, ask when can you come back to them. Act upon others as you expect others to act upon you.

And in the end, remember - it's not about how much time the task took you or about how many "pomodoro's" you achieved in a workday. It's not even about making that task "perfect". It's about doing your best to keep focused on the task at hand, alleviation stress and finishing the day with a sense of  "I got done what I wanted, what I intended to, what I committed to" - no matter if it's to my team, to my manager, to my children or to myself.



Saturday, November 12, 2011

The power of shutting up

One of the roles of scrummaster is facilitatig the scrum meetings. Throughout this, the team is expected to come up with answers and solutions to various problems, but often the scrummaster might be in a situation where the team expects him/her to come up with solutions - especially in sprint planning meetings and in retrospects, where the team needs to come up with answers as to "what to do" - either technically or methodologically.

One of the hardest - but most powerful - things the scrummaster needs to do in these situations is to just shut up.


Why is this?
Providing answers can be tempting - it's very easy for a technically-experienced scrummaster to whip up a technical solution to planning a story, or to tell the team they need to pair more or to focus on automated builds to improve their performance during a retrospect.

But doing this could be devestating to the overall team's empowerment - assume that the scrummaster would introduce a technical solution to a problem. The team would be very glad (hey, they just got a free solution without needing to think about it, right?) and would go ahead and work on it. But what happens if during the sprint the solution seems to not exactly fit the problem? what if a change in plan becomes necessary? the team would probably either:
a) go back to the scrummaster saying "Hey look, your solution is giving us problems. what should we do now?"
or b) assume the scrummaster's solution was really profound and insist on doing it even if it doesn't fit. Essentially breaking the agile value of "Adapting to change over following a plan" and effectively slowing the team down.

We can see that both of these scenarios would be bad - asking the scrummaster what to do next would start a vicious circle of relying on the scrummaster to provide even more solutions, effectively turning him/her into a team lead. The team would take little to no responsibility for this solution since it was the scrummaster's idea.

On the other hand, insisting on going through with the plan even if it doesn't fit the problem would cause lots of waste for the team - and stop them from seeking a probably better solution which would be easier and more time-effective for them to implement.


Old news
We know this situation in other fields as well - in parenting, we're often asked by our kids to help them with homework. The quickest and most tempting kind of help is just giving them the solution to a homework question. (1+8*9=? oh the answer is 73). However many parents already know this is the wrong thing to do - it doesn't really help our kids find the solution themselves, and so they would have a hard time solving other homework problems and in the end we'de be doing them more damage than good.

The proper kind of help we can provide is guiding them into finding the solution themselves - "let's see, how did your teacher say you should solve this question? what happens if you break down the exercise into smaller parts? how did you solve other similar questions? How about taking a break and trying again later?". Guiding our children to find the solution themselves is much more rewarding for them and gives them the power and ability to solve other problems themselves, and in the long run is the right thing to do.

This is also a key factor in personal life/work coaching - the coachee is expected to know and have the power to solve his/her problems, whereas the coach's duty is to lead the process and light the way. This is a key difference between coaching and consulting - a consultant is expected to provide solutions, while a coach is required to refrain from it, in favor of empowering the coachee.


There's more than one way to skin a cat:
Keeping silent sound easy - but there are many subtle and creative ways to refrain from intervening.

Here are a few:

1. Redirecting the question:
If a team member asks the scrummaster what he/she thinks they should do - redirect the question to another team-member . "John, what do you think Sarah should do?", "Sarah, what do you think about the solution John just suggested?"

2. Reflecting the question back :
If the team is asking the scrummaster a question -  sometimes just repeating the question back to them provides a different perspective - when they hear the question being asked they take the role of answering.
Sometimes writing the question on a board or paper or drawing a picture of the problem can provide the team with a new perspective.
"- Mr scrum-master,  how can we make the database distinguish between 8 oranges and 8 apples?
- Let's see (writing down: "how to distinguish between 8 oranges and 8 apples?")
- Aha, we can just put the string "8 apples" or "8 oranges" in the database, that should do the trick!"

3. Pointing in the right direction:
Sometimes the scrum-master will see something the team can't see at the moment. 
For instance, the team might have had a hard sprint where in the last day of the sprint they had to redo 3 days worth of work because they found out it was breaking something else. During the retrospect the team might ask the scrum-master what they could do about this - so just pointing out the fact that the team was having a long feedback cycle might get the team an aha moment, realizing they should do regression testing earlier,  breaking down the development into smaller baby-step cycles.

4. Making it a team decision:
A team-member might come up with an idea which other team members feel uncomfortable about. Furthermore, the scrum-master might be approached as a referee - asking him/her to decide for the team.
In this case the scrum-master can immediately put it up to finger-voting - "Sarah is suggesting you all start using XUnit instead of YUnit. Does anyone have an objection?" if someone does, go ahead "Ok, John, you objected so you need to come up with an alternative suggestion. What'll it be?"
The team will quickly realize it's up to them to both decide and stand up to the decisions, and will pick up on the collective decision making techniques through this.

5. Reminding of the principles
When approached with a concrete question, the scrummaster can point at the principles and values of agile, scrum or the team's own principles and let them figure out what to do that can fit.
For instance, the team might ask the scrum-master what to do if the PO doesn't answer emails with questions they need answered. Reminding them the principle no. 6 of the agile manifesto "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" will let them realize they probably just need to go and talk to the PO in person. 


The fine line between facilitating and teaching:
No doubt there is a fine line to walk between neutral facilitating and active teaching - some of the silences mentioned above are a good teaching opportunity for the team - reminding them of the principles, getting them better at problem solving or teaching how to get a team decision.  The more opportunities the team and scrum-master have to do this the better - leading to an overall stronger and more performing team, reducing the chances the same dilemmas will reappear in the future.


Do we really need a Yoda?
Some might question why we need a scrummaster to attend the meetings if he/she "doesn't actually do anything", especially upper management that needs to pay the scrummaster to just sit there.

For highly performing and experienced teams it might be unnecessary - they will have learned and gained both skill and team dynamics of figuring out everything for themselves. However for most teams - especially teams starting out with agile and scrum - just throwing them into the water and letting them figure it out themselves can be as devastating as providing the solutions.

It's like telling your kid to "just do the homework yourself" - you might find he was getting the wrong answers, hiding it from his teacher and getting no feedback as to how to get the work done right. Or even worse - feeling unsupported and thus resentful to both the schoolwork and the neglective parent. 

In professional programming these feelings can result in an excuse to doing sloppy work, hiding away problems or just getting the team-members demotivated enough to leave the workplace and go seek a more supportive one.


When in doubt... believe.
A scrum-master is just a human being, and so can be doubtful and fall into the same traps as the team. Often or not, the scrum-master will doubt the team's ability to find the right answer themselves, or will feel tempted or pressured to just give the team a solution.

When this happens, try and re-believe in the team - recall their past achievements and unique abilities, be impressed with their insights, take pride in their achievements and celebrate their successes. Keep a positive, supportive and patient attitude. Reflect these to the team members themselves - remind them of their strengths, of what went well, of how they handled similar dilemmas in the past. And don't forget to believe in yourself too - reminding yourself of the progress you've helped the team make by letting them shine on their own.


Monday, November 7, 2011

Adding comments to Fitnesse RowFixtures - Here's how

The other day I was looking for a a way to add comments to a rowfixture in fitnesse. Googling a bit didn't get me a straight answer, so I finally found it myself:

!|MyRowFixture|
|Column1|Column2|
|1|2|this is ignored|
|3|4|this is ignored too|

Seems like if you add a columns without providing a header for it, fitnesse just ignores the column so it can be used as a comment.




Check! – you’re impeded

In the game of Chess, when a player is in Check – his game is impeded. He cannot progress any attacks, strategic maneuvers or even protect other pieces until the threat on the king is addressed.
If the player cannot address the check threat – it’s checkmate – game over.

There are 3 ways to address a check threat:
  1. Remove the threat – capture the opponent’s threatening piece.
  1. Move away – move your King away from the threat.
  1. Block the threat – put a different piece in between the opponent’s threatening piece and your king.

Ok, so what about scrum?
In Scrum, one of the ScrumMaster’s duties is to address the team’s impediments. As a ScrumMaster when I need to address an impediment I often find it useful to think in terms of removing a check threat.

So impediments can be addressed similarly by:

  1. Removing the impediment – If the team can’t work because a computer is broken, fix it. If the IDE crashes – reinstall it, etc.

  1. Moving away from the impediment – If your computer is broken – use a different computer. If you’re stuck figuring out a complicated algorithm – try a different algorithm that would give a solution, etc.

  1. Blocking the impediment – If the team gets interrupted, place someone (the PO, the Scrum-Master, a manager or even one of the team members) in charge of blocking all non sprint-related interruptions. If there is too much noise in the room, place an acoustic wall or wear earphones.

Here are some more examples I’ve encountered.
Some are obvious, some are less so:

Impediment
Removing the impediment
Moving away from the impediment
Blocking the impediment
A team-member can’t get started on coding a class since they need to get some input from the PO and the PO is unavailable
Place pressure on the PO or on the external team to provide the necessary input
Go on to a different task while you’re waiting. Or have someone else provide the feedback.

Team needs to coordinate an interface with an external team which is unavailable – so they can’t start coding
Put pressure on the external team to provide answers, coordinate a meeting or call to enable this.
Go on to a different task while your waiting

Unavailable outsourcing resources – for instance external testing or external development
Put pressure on the outsourcing provider to get the work done.
Find another outsourcing provider to get the job done

External non-sprint related requests are made to the team that cause disruptions on sprint focus

Ask the requesting parties to stop
Ignore those emails? Don’t answer the phone?
Put someone in charge of intercepting external requests – The PO, a manager or one of the team members
Team member is ill, limited or otherwise handicapped
magic potion?
Have someone else fill in for the team-member

Reject the story and don’t commit to it until the ill team-member is well again or until the team is otherwise capable of doing the task
Truck-factor – when a team member can’t do a task since only other members know how to do it
Have the members pair and teach each-other



Have only the team members that know how to do the task do it

The entire team lacks the knowledge or skill of how to do a task so they can’t do it
Have the team learn how to do it
Use a technology that the team does know, even if it’s not the best choice
Reject the story entailing this task – don’t commit to it until the team is ready

What’s you next move?
Like in chess – there is no one approach that fits all situations. Sometimes you can’t move the King, sometimes you can’t block the Check.
And likewise - as you can see from the above list – also in Scrum some impediments just can’t be blocked, some can’t be fixed - such as a team-member’s illness (usually).

Also take note that addressing impediments has a price– from either the Scrum-Master, the team, from external parties – and usually from a mix of all of the above. This is true in chess as well, since taking an action to remove a check threat takes up a precious move (not to mention sacrificing another piece at times), whereas that move might be better served progressing the game towards victory.

So the choice of actions – how to handle the impediment – should be taken with care. You don’t want to make the wrong move – placing yourself in yet another impediment or wasting all the sprint duration handling an impediment just to find you don’t have any time left to get the impeded tasks done.

Victory is a team effort
Also in chess – whereas some pieces are more powerful or are worth more than others – in the end, what matters is the final outcome – either the black or the white wins the game, regardless of how many pieces it had lost or captured. Sometimes a sacrifice is made to achieve a team goal – winning the game.

In Scrum too – sometimes you need to sacrifice a long term solution in favor of achieving a deliverable. Sometimes you won’t get all the impeding root causes fixed. Keep in mind the endgame – the team as a whole should do everything in their power to get the to the sprint goal in the short term – while keeping on learning and improving in the long term from sprint to sprint.

Becoming a master player
Finally – in chess there is a fourth way of addressing Check, which is of course the preferred one – avoiding it in the first place.

While master players know how to avoid getting into a check situation, it takes a great amount of learning, practice and skill, and is often not just up to the player but depends on other factors such as the other player’s skills and unexpected moves during the course of the game.

In Scrum – getting to a point where the team is not impeded in the first place is something we should probably strive for, but this too takes learning, skill and practice – brushing up on technical skills as well as team and organizational dynamics – bringing the team members to a situation where they (self or not) organize so as to not disrupt each other and can block out external interruptions, and where the organization gives the team the support  - technical, personal or other – that the team needs to succeed.

And like in chess, even for the best of teams impediments can not always be avoided. Luckily - there’s always another sprint coming up with a chance to practice, learn and improve our game.

Saturday, November 5, 2011

Hello World - Release 2

This  is my second take on blogging - my first attempt was back in 2007, in a small attempt which didn't take too long to diminish into oblivion.. 
So maybe I'll call that attempt a spike and this time is just release 1?

So what's different this time?
At the time I was working as a programmer, learning Agile methods and specifically TDD. 
These days I'm working as a Project Manager, am a Certified Scrum Master and am still enthusiastic about agile.
I spend half my time being a scrummaster, half being a PO, another half managing projects and half coaching other people into agile methods and practies. Hmm.. too many halves... Let's call them Ideal-Halves and settle that I must have a pretty good focus-factor.

Apart from that, I had 1 kid and now have three, I used to practice agile with my dog and now get to practice it on my family, I'm slowly heading towards finishing my coaching course and hopefully will be settling into a permenant home soon. I've cut my hair and grown a beard. I'm still learning new things and gaining new insights.

So all in all I guess I've gotten a bit older, maybe a bit wiser, and still have a burning need and enthusiasm to rant and share my thoughts and experience about agile.

So here goes.. Hello world R2 - may the Shwartz be with me!