COP – Community of Practice 

Recently in the company I work for, we have set up a COP. Basically a small group of employees meet up on a weekly basis to discuss a topic of choice, which can vary from project management and software development to comparisons between different tools and frameworks.


The main reason as to why I do this is quite an egoistic reason:

So that I learn and become better.

Even though the company provides us with training, usually training is specific to the type of work we do on a day to day basis. We felt the need to discuss other topics which do not necessary add value to our day-to-day work. We felt that knowing about different areas, we don’t usually work with, helps us become better developers.


The idea is to create an open, informal environment where developers with the same interest can meet up to widen their knowledge on different topics that they are interested in. From the start the idea was that these sessions had to have minimal preparation time. Since these sessions are open they are not really owned by anyone and everything is decided in a democratic manner.


The concept of Knowledge Sharing Sessions is quite easy, there are 3 main roles during the session:

  1. Owner – the selected person chosen to guide the discussion.
  2. Google-er – presents any material prepared by the owner, and makes on the spot Google searches to find any unknowns.
  3. Audience – the rest of us who are encouraged to participate in the discussion.

The session usually starts with the presentation of any material the owner might have found online or prepared. During the presentation anyone can interrupt and challenge the owner. In the cases when the owner is not too sure what the answer the google-er steps in to help find the answer online.

The session then typically ends by some closing comments, were everyone gets a chance to let the rest know what they thought of the session. We also select a topic, owner and google-er for the next session.

Why it worked?

There are a few things that I think made this a success. First of all we tried to get as many stakeholders involved as possible. From the start this didn’t have to have an owner, and in fact this was owned by several people along the way.

The next thing we did is that we started small and grew slowly. The first meeting wasn’t the best one but since we were a small group of friends no one really cared. We then put up some posters around the work place which got some other people interested. Eventually we posted on the work intranet and even more people got to know about it.

So far this has been a great success and the topics are increasing in complexity by the week. One of my beliefs is that ideas are free and should be shared. In teaching others we teach ourselves and together we achieve more. I encourage other employees in different companies to do the same.

Right things done right

We always want to do the right thing right, right? There is only one way to do that, increase the efficiency and effectiveness. First we need to understand the difference between the two, since a lot of people including my past self confuse the two. Even though these work hand in hand one does not imply the other. That is you can have a company which is effective but not efficient.

Efficiency is about functioning in the best possible manner with the least waste of time and effort. It usually can be expressed as a percentage of the input and output. Effectiveness has to do with the end product or result. Essentially being effective is about doing the right things, while being efficient is about doing things right. 


In the above diagram there is only one quadrant we want to be in: top right. It is where right things are done right. I was going to argue as to why it is more important to be effective rather than efficient, because being effective will help you survive. However life is too short for second options, your only option should be to thrive. The main question is how to make sure you get to the top right quadrant as efficient and effective as possible. Then once you get there you need to make sure you can stay there.

The answer probably lies in your processes, tools and resources. The better they are the better you are. However adding processes and tools is a double-edged sword. Adding processes and tools is anti-agile. In agile we should value individuals and interactions over processes and tools. In essence any tools and processes should enhance and enrich interactions and transform people into individuals. Adding more processes and tools will slow you down and probably make you less efficient, but not having any will result in chaos. As always this is a balance of the cost curve against the benefit curve.

I would like to close by proposing 10 guidelines to help increase your efficiency and effectiveness, whether you are a company or individual:

  1. Be honest
  2. Get feedback and stop to reflect – on things you are doing right and wrong
  3. Automate slow processes
  4. Keep it simple
  5. Buy the best tools money can buy
  6. Work with the best
  7. Plan and set targets
  8. Deal with conflict asap
  9. Have fun
  10. Invest in knowledge

Company Visions

Company visions, mission statements, values… what a load of crap right? Wrong!

Up to a few months ago I use to believe that having a vision or a mission statement was plain bullshit. But when you stop to think about it without a vision you are all over the place and not sure in which direction you should be going.

A company should be group of people with the same set of common values and beliefs. The reason for this is trust. I like to use an example by Simon Sinek. When you are abroad and meet a person from your birth place, you become immediate friends. There is immediate trust between the two of you. The reason is because you know that the people from the same country share a common set of values and beliefs. Companies should be similar.

Why do you think Melita customer service sucks? I never worked for Melita and don’t have any inside information. So I’m going to make a few guesses here. It must be really annoying to hear people complain all day long. They must feel pretty useless that they hear people complain all day long but can’t do anything about it. The reason they do this is probably because they are told to act this way. The customer service representatives have bosses who treat them like shit, because in turn they are treated like shit. It becomes immediately evident that this company is founded on bad values and immoral beliefs.

What about money?

Almost all companies are there to make money, and making money in its self is a vision. By this definition all companies have a vision: to make more money. That’s true, the problem I see with that is that it’s much harder to build a company with the right values and beliefs, if your main aim is to make money. We all like money. But money makes us greedy and short sighted.

We should think of money as a by-product or result. In your personal life in order for you to survive you need to have money. You need money to enjoy it and money helps to make you happy. But if your primary aim is to make money you’ll end up living a very boring life. If on the other hand your aim is to have fun and enjoy life you’ll probably live much better off. However in order to enjoy life you’ll need money. To this extent money is a by-product. It’s not your primary aim to make money, but you need money to live better. The same reasoning applies to companies.

Why should you care about all this?

Having a vision changes everything. Having a vision changes the way companies do things and what they do. Having a vision attracts the right customers. Having the right vision will help you come up with the right set of values and beliefs. Which in turn will make it easier for a company to shape up the right environment to attract and nurture the right employees.

Clean Code

You I recently read a book by uncle Bob, which is a must read for every developer. It’s called Clean Code and it completely revolutionised the way I think about code. In particular when coding I am now much more careful about meaningful names, numbers of parameters to pass to a function, the number of lines of code per function, use of comments, error handling and tests.

Why should code be clean?

Before we get to that I think we should start by asking the question what is code? In reality code is just documentation. Yep, that’s all we do, write documentation all day long. More than anything code is the best and most unambiguous specification document of the solution.

We have all been in this situation: It’s the start of a new project and your sprint velocity is really high, you are completing a lot of features per sprint … but then all of a sudden everything slows down. This normally happens because before you write code you need to read the written code. If the code is in a bad state, it is going to take you a lot of time to read the code.


To be honest this is something you can’t avoid. You will always need to read code to write new code. The only thing you can do is make the experience of reading code better for everyone.

What is good Code?

Let us start with an easier question. What is bad code? We can all notice bad code when we see it. Basically its code which isn’t readable. Then, by definition, good code is readable code.

In good code you can read through the code, starting from a high level and going down to the next level. Each level should introduce the next layer of abstraction. When a developer is reading the code he should say: “Yes, this is obvious … yes this is also obvious”.


In the above diagram we see the classical 3 tier architecture however notice that the higher you go the more high level the modules are. The user interface does not know that there is a reporting database, or that for some reason, the photos are not saved with the user data. The user interface just calls some classes from the user and reporting module and displays the data. Also within the actual layers you should start at a high level and to the lower level. Thus the public methods will very high level and the private classes will be at a lower level. The same thing should happen even in the classes. The public methods are at a high level while the private methods are at a lower level.

Let’s Code

Sam had to write some code to get an employee record:

public Employee getEmployeeData(string email, out string error)
  // check email
  if (!email.Contains("@"))
    error = "email is not valid";
    return null;

  // get user by email
  var employee = Employees.Where(x => x.Email == email);

  // check if user exists
  if(employee == null)
    error = "Employee with email: " + email + " was not found";
    return null;
  else if(employee.Count() > 1)
    error = "More than one employee found with email";
    return null;
    error = "";
    return employee.First();

Sam’s code isn’t too bad. However it does have some potential flaws. First of all the method is too long. Its going to take some time to read through it. I also see an example of DRY (don’t repeat yourself). The comments are a classical example. Why did Sam think that writing “get user by email” is more clear then a lambda expression? To me the lambda expression was far more descriptive and helped me understand more what is going on. There is a wrong choice of names. The variable name “employee” is too generic

Method Signature

This is where Tom comes along and sees this code. Obeying the Boy Scout Rule he starts to refactor this code. Let us start by the method name: “GetEmployeeData”. The word “data” seems to be redundant. Everything is data, so we can eliminate that word. The next thing we notice is that method name is a lie. We are not just getting employee data, we are also validating the e-mail. A more appropriate name would be “ValidateEmailAndGetEmployee”.

The next thing is the number of parameters. We should think about who is going to be calling this method. Given that this method is getting the employee by email I would expect to pass the e-mail. However I don’t expect to pass anything else. For some reason the developer is also passing in an out parameter to record errors. In object oriented we have exceptions and these make the code much cleaner.

Helper Methods

The first 6 lines of the method are just there to check the email. So in this case we should split the code into smaller functions. This also help us to eliminate the comments which just make the code longer and more ambiguous.

Final Code

public Employee validateEmailAndGetEmployee(string email)
  return getEmployeeByEmail(email);

private void validateEmail(string email)
  if (!email.Contains("@"))
    throw new EmployeeException("Email not valid");

private Employee getEmployeeByEmail(string email)
  var employeesWhichMatchEmail = Employees.Where(x => x.Email == email);


  return employeesWhichMatchEmail.First();

private void ErrorIfMoreThenOneEmployeeIsInList(IEnumerable listOfEmployee)
  if (listOfEmployee == null)
    throw new EmployeeException("More than one employee got returned");

  if (listOfEmployee.Count() > 1)
    throw new EmployeeException("More than one employee found with email");

I think you agree that this code is much cleaner. First of all the method and variable names describe better what is happening. The next thing we notice is that the first method is quite high level and just contains references to helper functions. The helper functions keep on decreasing the abstraction and going down to the implementation. Like this the developer reading the code can immediately assume what every method is doing.

Okay… I think that is too much information in one post. Basically we briefly discussed the following topics:

  1. Why we should invest in clean code
  2. What the bad code looks like
  3. Boy Scout Rule
  4. The proper use of function and variable names
  5. Using comments
  6. Helper methods
  7. Error handling

Till the next post go to Amazon and buy the book.

The Scientific method for interviews

I have been doing interviews for quite a while now and would like to share with you a method that I like to call the scientific method for technical interviewing. First of all the overall process goes as follows:

Observation > Hypotheses > Prediction > Experiment > Conclusion

I have to confess that during an interview I am not fast enough to do all the required steps so I do some work before. In any case let us go through the stages one by one.

Phase 1: Observation

Interviews are a short period of time to assess if the person in front of you could be an asset to the company. The candidate probably feels nervous, which will make the whole process harder for both of us. So the first few minutes I spend to introduce myself and to try to change the formal environment to a less formal one.

1. Hello, nice to meet you. I am Kurt and I'm a project leader.
2. You should be ... and you have applied for ... position.
3. Series of general questions.

I ask questions like: “How are you?” Or “Was it hard to find this place?”. I’m basically trying to achieve two things:

1. Relax the person

Get him in his comfort zone where he can be assessed much better. The trick in this is to act relaxed. People usually do what you do, if you are angry they will feel it and get angry, if you are relaxed then they will be relaxed.

2. Start making some observations

In reality, as an interviewer you started making observations and predictions from the moment you laid eyes on his CV. I use this time to have a look at what the person is wearing and how he is responding to the new environment. If he is confident he might have required skills to meet clients face to face. A lot could be said from the way a person looks and acts, and if you notice these a client and team mates will do to. I should stress that there is no right or wrong in this phase, I’m just making basic observations.

Phase 2: Formulate hypotheses

In this phase I need to confirm what role I think this person might fit in. Of course you already know what role he is interested in but companies might vary from the way they work, thus the role he applied for might not be the one for him. I basically try to understand what this person currently does, and what he aspires to become. Are they aware what is happening outside of his team? Are they involved in decision making processes within the company he works for?

4. What do you do on a daily basis?
5. What do you expect from your manager?

I like to use advise I got from a colleague of mine which might sound mean but it works 99% of the time: the years in experience of the person tells you a lot on their potential. If they have been working for 10 years and are still not senior developers they probably will never be.

I then use this information to formulate my hypotheses. Assuming the person is applying for a technical role, it is usually 1 of 4 categories:

  1. Candidate is a junior developer
  2. Candidate is currently a junior developer but is promising to become a senior developer
  3. Candidate is a senior developer
  4. Candidate is a senior developer and has the required soft skills to do some project management

One might argue that the position the candidate applied for already had a matching set of questions asociated with it. However should they fail to meet the required criteria you can at least still assess. The company might have other openings or there might be other openings in a few years time.

Phase 3: Predict and Experiment

Prior to starting the interview I already knew about the 4 possible hypotheses so I prepared questions for each one of these. Unfortunately I can’t share these questions with you, since I use them on a day-to-day basis. But I like to share the philosophy I use when coming up with these questions. Basically I try to cover as many technical areas as possible. I usually use Sijin Joseph’s competency matrix as a checklist to make sure I’m assessing all the important areas.

5. Series of technical questions

Before each question I like to guess if the person would answer the questions correctly or not. This will help me after the interview to make more accurate predictions in case I missed on any questions. Also if the candidate starts getting a lot of wrong answers I might change my original hypotheses and ask easier questions. Alternatively if all the questions are right I ask harder ones.

Phase 4: Conclusion

This is where you conclude the interview. I usually like to conclude by asking:

6. Do you have any questions you would like to ask me?

What ever he answers I make sure that I re-explain my position and what I do on a day-to-day basis. I do this for 2 reasons:

1. Avoid Candidates from making the wrong decision

Make sure they wont have any surprises should they be chosen. This is all about setting the right expectations and make sure that they are aware of the full picture so that should they be chosen they won’t leave the company after the first few weeks.

2. Sell the company

The candidate is still an external person and even if they are not chosen you might still work together in the future. I make sure I give the person the right impression of the company I work for.

Post Interview Work

Just after the interview I like to speak to someone, who was either present during the interview, or someone else who usually does interviews. We then come to a conclusion. This should take no longer then 5 mins. Something to keep in mind: if you are not sure then don’t hire the person.

To help me out I usually have a large excel file with different sections. It has the various questions and the scientific stages, which serve as a guide to help me out. I jot down loads of notes and mark the questions as good or bad during the interview. Should there be another opportunity within the company in a few years time, I can refer back to this sheet. This will help me remember my reasons and evaluation on the candidate.

To conclude, I am usually quite strict on who to say yes to and I like to think that this is for the candidate’s advantage. If you end up hiring a person which isn’t up to standard he will probably get fired. This will make him and the company lose money. Remember that people have loans to pay and children to feed, his salary might be essential for him. Don’t take any risks, if you are not sure its best to say no.

4 Values Of Scrum Masters

Recently I have attended a seminar which made me think of some important qualities that every scrum master should have. I would like to point out 4 important values that I think are essential characteristics of a scrum master. Why 4? Because 4 is an even number, less than 5 but greater than 3 (sorry JB is speaking). So here is the list:

Positive Attitude

Being a person who sees a glass half full does have its share of benefits. Even when things go wrong you should still find a way to motivate the team and lead them in the right direction. Having a positive attitude doesn’t mean that you are totally satisfied with the way things are going, you should always aim for better, and use positive constructive criticism along the way.


Everyone should be aware what on earth is going on. As a scrum master you are not a manager who secretly decides with the rest of the management and then forces down the decisions. Even though the scrum master can lead, the decisions should be taken as a team.


As is highlighted in several agile books the team leader or scrum master is there to be a servant for the team and facilitate any issues. The modern project leaders, or scrum master should aim to control rather than enforce rules. A scrum master’s role is there to remove any impediments and come up with solutions for the problems the team face. If developers don’t have a good sense of what each other are doing, the Scrum Master sets up a physical taskboard and shows the team how to use it. In essence the scrum master is there to solve issues and help out the team.

Aim to become redundant

Your aim should always be to find people who can do your job better than you, so that you can move on to other things. The minute you get stuck, is the moment you stop improving which will lead you to boredom and eventually death – actually you are going to die anyway so it’s not a good example. But the point is that you should aim to not be a single point of failure, the team should operate without you.

The only value required

I really like this ad from apple produced back in 1997 when Steve Jobs rejoined the company. This video probably sums up what a scrum master should be all about, basically it is about being a good leader. To be honest a leader has all the values which I mentioned above. Which makes my previous 4 values of scrum masters pretty much useless and defeats the whole purpose of this blog post.

Basically what I’m trying to say is, that as a scrum master you should be a leader. What I would like to point out is that there is a great difference between leaders and managers. Managers enforce processes while leaders always try to improve and are never happy with the status quo. They are the square pegs in the round holes or rather the round pegs in the square holes.

High Speed Mono Tasking

This should come to no surprise: humans can’t multi task. Women can do it better but overall we still suck at this. Furthermore doing things in parallel is much slower than doing things in series. With this in mind we should be focusing on a single task at a time and try to achieve high-speed mono-tasking.

Lets take a simple example to proof this theory. Let us assume that you have 2 tasks each of which take 10 mins to complete. If you do one task after the other you will get the following performance:

Time Task 1 (time left) Task 2 (time left)
0 min 10 min 10 min
2 min 8 min 10 min
4 min 6 min 10 min
6 min 4 min 10 min
8 min 2 min 10 min
10 min 0 min 10 min
12 min 0 min 8 min
14 min 0 min 6 min
16 min 0 min 4 min
18 min 0 min 2 min
20 min 0 min 0 min

If you work on one task after the other, task 1 will be finished after 10 mins, while task 2 will be finished after 20 mins. Let us assume that you will alternate between the 2 tasks every 2 minutes:

Time Task 1 (time left) Task 2 (time left)
0 min 10 min 10 min
2 min 8 min 10 min
4 min 8 min 8 min
6 min 6 min 8 min
8 min 6 min 6 min
10 min 4 min 6 min
12 min 4 min 4 min
14 min 2 min 4 min
16 min 2 min 2 min
18 min 0 min 2 min
20 min 0 min 0 min

In this case task 1 will be finished after 18 minutes – 8 minutes later when compared with the sequential method. On the other hand task 2 will still be finished after 20 minutes. 

But wait… the above working is wrong. Humans, much like CPUs, need time for context switching so we should be adding a constant every time we switch tasks. Doing tasks in series also gives us another advantage. After doing the same task for a while you will become immersed in the task and get into “the zone”, which will increase the level of productivity even more. 

A method to keep you focused on a single task at a time is to use a task list, ordered in priority order. This is exactly what the backlog in agile methodologies is designed to do.

In this case our responsibility, as scrum masters, is to make sure that everyone is getting as few interruptions as possible to keep on focusing on his task. To conclude, your quality and productivity should increase much further if you and other team members use the technique of high-speed mono tasking.


I spend around 10 minutes a day entering my timesheets and you can’t but wonder if this time could be spent any better. Based on what I have described in my previous post about MVP and the way business value relates to time and money, we can calculate how much time we should be spending on this. The value gained in timesheets is mostly data which can in turn can be used to:

  • Help determine if the project is still on target to reach its deadlines and make sure it’s delivered within budget.
  • If you are on a time and material basis, your timesheets will probably be used for billing.
  • If you are working on a product, timesheets help to determine the expenses involved to create the solution.
  • Compare how efficient developers are on their daily tasks.
  • Check how much time is spent to support the application in various parts of the product life cycle.
  • Be able to do better predictions and estimates when you do similar tasks.

From the above I hope you agree that timesheets are a vital source of information for a company and in some cases are as important as the work you do. The main question is, how detailed should they be, or to put it differently how much time should be spent on this? I think the answer depends on the quality of the data you require. The following are a few questions that people responsible for configuring timesheets should be answering:

  • Do you need to do a timesheet item per module?
  • Do you need a timesheet item per feature?
  • Do you need to enter a comment with a timesheet entry?
  • Do you need to record timesheets to the minute? (Or if you approximate to the nearest 15 minutes it’s enough?)
  • Do you need to know the exact time during the day that the task was done (e.g. from 10am – 11am were sent doing xyz) or is the total hours per day enough (e.g. 1 hr was spent doing task xyz)?

Assuming the process of entering timesheets is manual, the more “yes” you answered to the above questions the more time-consuming the process will be. Arguably, this also means that it will be harder for employees to record precise data.

“I make it a point to be accurate with my timesheet, said no employee ever.”

I would like to conclude by sharing some tips that I use when entering timesheets:

  • First of all I try to be as descriptive as possible and avoid words like “bug fixing”.
  • On the other hand I do my best to keep the description as concise as possible.
  • I always enter my timesheets directly in the program. I feel it’s a waste of time to write them down somewhere (notepad, paper etc…) then copy them over.
  • Enter time sheets daily or twice daily if possible. I tend to forget what I was doing 2 hours ago, let alone what I did the previous day or week. I personally prefer to enter my timesheets just after lunch break and before I leave the office.
  • I take advantage of idle time, for example waiting for the guy who I had a meeting with to show up, to enter my timesheets.
  • When I’m not too sure what I spent my time on, I check source control check-ins, emails sent, calendar appointments, team task list and my personal task list.
  • I use email subjects and check-in comments as a description in the timesheet comment field.

If you didn’t learn anything from this post I hope that at least I managed to convince you that the time spent entering timesheets is well spent and crucial data for the company’s survival.

Minimal Viable Product

Here is something you don’t hear that often: estimation is hard! It’s so hard that people almost never get this right, and probably they shouldn’t because after all it’s an estimate:

“An approximate calculation or judgement of the value, number, quantity, or extent of something.”

I have a suspicion that estimation is hard for most trades not just for software development, because people are generally quite reluctant to give you an estimate. So generally people tend to either:

  • Overestimate and risk losing the job to someone else OR
  • Under estimate and risk working after office hours to catch up

This of course is inconvenient for everyone and tends to create a bitter relationship between the two parties.

Is there another way?

Yes .. avoid estimating.

First of all let me start by pointing out the obvious, everything has a value, and when I say “value” I really mean a “price”. So first we need to understand how much a client is willing to pay for a product. To give you an idea on how to calculate the price, general IT provides solutions to problems which we could categorize into 4 main categories:

  • Solutions which save time. For example searching and retrieving previously saved documents more efficiently. 
  • Solutions which help mitigate risks and solve legal issues – which would avoid you fines or losing clients.
  • Solutions which entertain.
  • Solutions to record data which in turn give a business value. 

In any of these we could work out how much a product is worth paying for. For example if a company, Strawberry company LTD, doesn’t have a document management system and employees are spending 30 minutes a day searching for documents you can estimate how much time is wasted in a year. An average employee working at Strawberry happens to be Bob, who works 8 hour days and earns €30,000 per year. When you deduct the time that Bob spends on leave and sick he works for 220 days in a year, which means that almost 14 days (220 days * 0.5 hrs / 8 = 110 hours) per year are spent searching for documents. Roughly €1909 per year. Apart from Bob there are 20 other employees and assuming that generally an IT system lasts for 5-10 years, Strawberry shouldn’t spend more than €190K – €381K on this system. From this simple calculation Strawberry can get a rough idea on how much money they can spend to at least break even.

The next step is to come up with the least amount of development tasks required to make Bob’s life easier. You come up with a MVP:

“The minimum viable product (MVP) is the product with the highest return on investment versus risk.”

On the left we see products that have too little features to be used, while on the right are the products that users would like to use.

Your initial aim should be to produce a product which contains the least number of features yet is still viable. You start to remove any additional features which are not used that often, for example any ability for users to manage their account, change passwords, change lookup values. You also remove the nice to have features such as being able to search by extension or document type. You only concentrate on the basic tasks that get the job done, in this case type in a keyword and get some results. Like this Bob gets to try out a very basic version of the product and checks if its enough to get his work done. From here we can either decide that what we have is enough and thus stop development or do another iteration. The beauty of software development is that we can evolve the first release and produce a better product. This process is repeated until everyone is satisfied. I have to point out that the minimal viable product is not limited to features but should also be used as an approach for software architecture.


If I am a client asking any company to provide me with a service I would prefer paying per day rather than trusting the company to provide me with an estimate. Here is why:

  • If developers are taking too many coffee breaks instead of working I can terminate the project at any point.
  • If the developers are doing a lousy job I can terminate the project in the beginning since I’m not really committed. I only end up losing a small % of my budget.
  • I don’t have to pay for features which I’m not really sure if I need.
  • I don’t run the risk that developers cut corners since they under estimated.

Most of the time clients are strict on budget but don’t really care if the end product doesn’t have the fancy check boxes, thus we are able to prioritize between the features and get the most important tasks out-of-the-way first. I truly believe that this is the best way to mitigate risks for all parties involved and ultimately create a product which works better.

Did anyone try this approach? Any thoughts?