Technical Debt - from Owing to Owning

The term "Technical Debt" is used often in Scrum and otherwise Agile discussions. We know - or at least assume - it's a bad thing to have. Some best practices concerning definition of done for a story is to not leave any technical debt laying around. But what exactly is this technical debt all about? How does a team manage it? is it necessarily bad and should it always be avoided - at all costs?

Defining Technical Debt
Technical debt is any engineering activity that a Scrum or Agile team //should have done// but for whatever reason hadn't yet.

Some common examples might include:

• Smelly code that needs refactoring
• A broken automated build-server which while broken forces the team to do manual builds
• An automated acceptance test which is constantly and falsely red - not because there is a bug but because the test itself isn't properly testing the right outcome (a.k.a False Negative)
• A piece of code which doesn't have any tests at all

It's obvious from these examples that the team needs to do some work to get the debt "paid" - refactor the smelly code, fix the build-server, fix the test or write the missing test.

Work to do or Debt? What's the difference?
When I go to a store to buy groceries, I will take into account that whatever I'll buy will cost me money. - everything has a cost to it. Before I buy anything I don't owe anything, but once I collect my groceries and go to the cashier, I'm expected by mutual agreement and law to pay for what I've taken. But sometimes I find I forgot my wallet at home - and the shop owner might agree to give me the groceries and have me owe him money - that turns the cost into debt.

So back to software - when the Product Owner requests a story to be coded, during sprint planning the team will estimate and plan the total cost of the work - they will write down all the technical tasks that need to be done in order for the story to be considered "Done", and throughout the sprint will do everything in their power to complete all those tasks.
At this point the team has agreed - and committed - to do all the tasks. However sometimes (and sometimes more often than not) the team might find in the end of the sprint or even way after the sprint had ended that there are some "undone" tasks - things than still need to be done even though they should have been done before. This is where we view these tasks as not only "TODO Tasks" but as "Debt". The team owes the tasks to the PO or to themselves by power of their previous agreement and commitment.

Who do we Owe this to?
In Scrum the agreement on what tasks should be done for completing a given story are derived from the "Definition Of Done" (DoD). The DoD is an agreed upon list of criteria defining what it means for a story to be done - for instance it might include "there must be automated tests for all functionality", "all code should be refactored so there are no code smells left" and "All bugs should be fixed".
So if a team has "Technical Debt" - it's likely to be a violation of the DoD.
But the DoD itself is formulated through mutual agreement between the PO and the team, and will likely include both items that are important to the PO (like not having any bugs) and items that are important to the team itself (like having clean code or automated tests, since these will help the team move forward faster and make life easier for them down the road).
So any violation of the DoD is not a violation of a commitment to the PO, but in fact a violation of commitment to the team as well.
Owing technical debt is owing something to both the PO and to the team itself.

Don't get into debt in the first place? I wish...
One of the most common pieces of advice concerning technical debt is to not have it in the first place - I've heard consultants say that the PO should not accept stories for which all tasks have not been done yet, or that the team should not "claim points" for undone work. At some point the Scrum Guide included some pages dealing with "Undone Work" in it (I recall they have been removed in the latest edition, but don't take my word for it).

But in the end - there will always be "undone work" discovered somewhere - maybe at the end of the sprint the PO really needed that feature delivered to gain a business advantage and the team came to agreement with the PO that the code would not be fully refactored.
Maybe the team could get away with manual builds or manual tests for a sprint or two and investing in automation wasn't justifiable at the time, although now they realize they would be better off automating things.

Either way - technical debt (like financial debt) is usually brought to being through some agreement, done in good faith and for good reasoning at the time it was agreed upon.

Types of Technical Debt
I find most "Technical Debt" can be categorized in to one of three types:

1. Debt:
This is the work that we knew we needed to do but for some reason decided not to.

For instance, if I gave a dinner party at my home and decided not to wash the dishes - obviously I'll have to wash them the next morning.

In software, this might include:

• If a team had committed to writing automated tests but decided with the PO to not invest in them for the current sprint - they will probably need to catch up at some later time.

We call this Debt because the team had initially committed to do it but has later decided to postpone.

2. Discovered Deficit:
This is work we discover needs to be done only afterwards.

In my kitchen I might some day discover I have leaky plumbing. I didn't know of this ahead of time and had no way of foreseeing it, and will now have to take care of the situation before my next dinner party.

In software we often discover "Technical Debt" in hindsight - for example:

• While working on one part of the system we did refactor the code the best we could, but now - several sprints later - we have learned new coding patterns and realize that what was previously considered good code might be better if a new pattern was applied, and we want to refactor that code.
• We might realize we've been writing automated acceptance tests but in a form which is now very hard to maintain, and would be better off reorganizing those tests so they will be easier to maintain and evolve further.
• As the system runs throughout time in production (with real users) a database table might fill up beyond our initial expectations, and we realize that in order to meet our performance needs we should normalize it separating it into two separate tables (this is is fact a form of refactoring).

We call this Discovered Deficit because even though the team did everything they had committed to at the time, only with their newly gained knowledge, insights and perspectives can they now see and plan what they might have done better.

3. Technical Investment
Back in my kitchen - I wash the dishes, I have no plumbing problems, and the dinner parties are a great success - so I decide to buy a dish-washer to make my life easier.

In software, we might see opportunities to make the engineering work easier or better:

• We might want to install, learn and use a new testing framework, or better build-server 
• We might want to learn new techniques of working. 

These will presumably be good investments and although they will take some time (and maybe money) - they are assumed to pay off by improving quality or team velocity and so are good for business. Hence the term Technical Investment.


Is it bad?
Debt has a bad connotation - nobody likes being in debt, and if we are - we probably did something wrong. Once we realize that the technical debt was in fact agreed upon and taken into account - we can stop seeing it as a negative thing and start viewing it objectively - as mere "work to do".
Even calling this "undone work" smells bad - if it's "undone" it means somebody should have done it but didn't.
Looking at the categories mentioned above - we can see that much of the "Technical Debt" might in fact be the fruit of new insights or simply a worthwhile investment opportunity - not debt at all.

Seeking a more objective term - we might call these "Technical Tasks", or "Technical Stories", although these terms have their own baggage among Agile circles.

However we name it - this work differs from normal story tasks in that "normal" tasks (planned upon in the sprint planning meeting) are commissioned by the Product Owner ahead of time and are expected to create immediate value to the product - the PO realizes the tasks will need to take place in order to fulfill a story he/she wants done. The PO takes responsibility for the cost of these tasks as part of the responsibility for the product backlog.

The "Technical Stories" on the other hand are not going to be commissioned by the Product Owner anymore - the PO won't take responsibility for them, and won't prioritize them for upcoming sprints, since they don't drive immediate value to either user or customer. This means someone else needs to take responsibility for them - probably the team itself. They should be the ones wanting it to be done and pushing for it to be included in a sprint.

Responsibility and Ownership
Responsibility is a key factor to Agile software development - we want self organizing, responsible teams and individuals acting proactively and with respect to each other.
In Scrum the responsibilities are clearly divided - the Product Owner is responsible for the product while the Team is responsible for delivering it. This means the team is indirectly responsible for the quality of the code, and as a self-organizing and constantly improving team also responsible for it's own quality of work, it's pace, focus and capabilities.

Seeing that the team is responsible for their quality and performance, combined with the above-mentioned insight that the team in fact owes the "Debt" to themselves, turns the team into yet another stakeholder for the PO - a stakeholder that pushes to include "paying off technical debt" into each sprint.

So if the Product Owner //owns// the product, who //owns// the technical debt?
The team of course. They are owners of these "Technical Stories" just as the PO owns the "user stories". They own the list of "Technical Stories" (or "Technical Backlog") just like the PO owns the product backlog.

This puts a whole new perspective on what technical debt is - almost like the saying goes "it's not a bug - it's a feature", but in this case "it's not technical debt - it's a technical story".

From "Team" to "Code Owner"
Ownership of the product by a single responsible PO is what drives the Scrum process into creating working software that creates value to the business. Strong product ownership is based on drive, vision, a clear understanding of the product and business needs and the authority and capability to make decisions concerning prioritization and return on investment (ROI) of each feature or story.

Likewise, strong ownership of the "Technical Stories" should be driven by the same traits - a team should have firm belief in the need and in the gained value of completing each "Technical Story", should be capable of decision-making concerning which "Technical Stories" to do and when they should be done, and should be empowered to make those decisions - by mutual agreement and respect from the PO.

In this perspective the team is not only responsible for delivering working high quality software, but becomes the "Code Owner", equivalent to the "Product Owner" in the essence of ownership, while differing from the PO in the subject matter that is owned.

Viewing "Technical Stories" from this perspective enables a much more responsible, strong, proactive and positive approach to dealing with the tasks in hand than with the negative perspective of "Technical Debt". And this is the main motivator - not dealing with "why it happened", but rather with "how can we make things better".


Coming next.. "It's ours! Now what do we do with it?"
Once the team realizes that technical debt is not a bad thing but in fact something they own and are responsible for - they need tools and techniques for managing it.

I'll be covering that in an upcoming post. It's next in my backlog...

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:

(see http://www.pomodorotechnique.com)

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.

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.

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.

2. Move away – move your King away from the threat.

3. 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.

2. 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.

3. 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.

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!