Leadership

The vast and free source of power that we often overlook

/ timmeeuwissen / Leave a comment

I am convinced that a compliment that I have for someone else, isn’t mine to keep.

We often keep our praises and compliments for someone else for ourselves. Sometimes they are shallow, like seeing that a female co-worker has made an extra effort on her hair today or someone bought new shoes. But sometimes they run deeper, like appreciating the time someone has taken to educate you on something or be thoughtful of your private situation.

It is key to express yourself. Speak up! Inner whispers cannot be heard.

Fear

We often fear that we miscommunicate, so we refrain from communicating at all. Thoughts like:

  • Does he think I try to curry favors
  • I’m afraid that she thinks I try to hit on her
  • This person always works this good, giving a compliment now is silly
  • I think it’s inappropriate for me to say this since he or she is so much higher in the chain

are quickly in mind. There’s thousands of reasons to not do it, and it takes courage to do it.

Why should you do it anyhow?

Even though it’s hard, there are some good reasons to do it anyhow. You will see that when you practice this more often, the process will become much easier after a while.

  • Positivity is infectious. A single positive word from a person you respect dearly can make you go home and tell your friends and family about it. You did well, made effort and somebody saw and valued it. Your day can be filled with an empowering feeling that makes you perform better than ever.
  • Positive reinforcement steers better than punishment. Instead of telling what shouldn’t be done, appraise what should be done and people will follow that route.
  • It’s okay to give people compliments when you feel insecure if they are appropriate, just make sure you also tell them your doubts (in not too much detail) about giving them.
  • Telling that things are bad, will make people lose their faith and lust to work. The inverse of that is also true. Telling people they are doing good will make them feel reinforced and want to become better.
  • Threat others the way you want to be treated yourself.
  • By being thoughtful, you can create a bond of trust. This bond (especially for leaders) is necessary when times are more rough and you need your influencing skills to steer the ship with the nose in to the waves.

For leaders

To put some more emphasis on the last point, remember that trust is:

Of the three factors you can influence as a leader, at least one third is controlled by intimacy which is built by honesty, respect and a watchful eye to the person and their situation and needs. A kind sincere recognition can go a long way!

Conclusion

Take the feeling that you have when you feel recognized and verbally rewarded. That power is also within you to give to someone else. Be carefull when to apply it, and don’t overdo it. But be confident that when you think it’s time to do it, it should be done without reconsidering. Bite your tongue and wait for the response. Observe and learn from what you’ve just done.

Be conscious of the power you have unleashed to shape the day of someone else

 

 

Why use Story points or Time for resource tracking

/ timmeeuwissen / Leave a comment

For: team leads and Entrepreneurs

Running a service oriented business isn’t the same as running a product oriented business.  There’s a major difference and over the course of time I’ve learnt where the differences are when it comes to resource tracking, and how that may or may not affect your business.

Resource Tracking based on Time (more service oriented)

Pros:

  • enables to have specific billing, which feature costs how much money exactly
  • prospects and invoices can be compared to see how budgets are met
  • you can track individual progress and troubleshoot on real fine level when things aren’t going well
  • works exceptionally well for time-to-time small ad-hoc services

But the cons weigh more heavy:

  • time tracking is a pitfall for managers to start micro-managing
  • it kills creativity
  • it drives quality down (you assess on time, not on result)
  • there’s large amounts of overhead and overthinking for the developer
    was I effective this 15 minutes? And, I had to google a lot for this feature, should the customer pay for this?
  • employee satisfaction but also effectivity is strengthened when the employee feels at comfort. The best idea’s come to you when you’re not actively trying to solve something. Opportunity for relaxing is in that sense just as important for the employer than the employee (mind you, there should be a good balance here. Of which part of can be obtained by having a good thorough intake). When the employee has to meet up to the set 8 hours of his job he’ll feel at discomfort when he sat down and stared out of the window for half an hour, even though this time might have solved lots of other stuff. At the end of the day he or she will start with creative bookkeeping which will result in lots of negative energy that could have been used for positivity.

Resource tracking with story points (more product oriented)

When you start resource tracking with story points:

  • all points will be relative to one another.
  • developer doesn’t have to think about the client. They just have to think about what it’s relatively costing to another task
  • tasks get easier separable, since they can now be defined without having to speak in understandable business terms.
  • story points have relative value. This eliminates that the speed of the individual developer is weighed in the estimation
  • more focus towards quality

But how do you sell this:

  • Measure in Complexity and Uncertainty, not Effort
    • Complexity consists of how hard it is to clear the job. E.g. it touches lots of repositories, we have to align with lots of people and the subject is very delicate. This would be a high complexity.
    • Uncertainty gets weighed in, because it is key that during grooming sessions this factor gets reduced to a minimum. The more certain something is, the smaller the task can be, the better it is estimable but also deliverable for the allocated number of story points. So if either your PO or yourself don’t have high confidence and feel uncertain how to solve the task, you should start splitting what is clear and what isn’t, to maintain deliverable stories. External dependencies are uncertainties as well.
    • Effort gets pulled out. It’s silly to do simple stuff for lots of times and your customer shouldn’t have to pay for silliness. This is where you have to play smart, and say: changing all files by hand would take me 10 hours, so I will have to write a converter that does exactly this, this and that, which will only drive up the complexity, and thus the investment in to getting this topic solved.
      By doing this, you get rid of your legacy topics. Programmers should be lazy and automate everything they can. This should be part of the routine, because your PO ‘pays’ for your routine. Just be cautionate to not over-do it.
  • Each team will start establishing a baseline of story points that they can process in a time slot. This is your so-called ‘velocity’. You can easily divide the time over the storypoints and see what the cost would be.  Because your team is focussing on what it would cost in relative terms, instead of fitting deliverance of functionality in a timeslot (which is doomed to fail), you can calculate the cost to analyse ROI versus expected delivery date. You could then also decide to buy from external sources, since you have a good idea what it would cost doing it in-house.
  • Run through the story and write down all steps that need to be done. Now everybody should have a ground level understanding of how to solve this story. Buy a set of scrum-pokercards, count down and let everybody throw down a card. No significant differences? Quickly reach consensus and take the average if no-one objects. Some super high or super low? Let them explain and let the team learn from this perception.

Conclusion

As you might see I’m in huge favor of working in a product oriented environment. This is not always a possibility given your business model and current list of clients. If you would like to go with story points, but your clients are not ready yet, try to do this:

  • find a good size client, preferably one that favors on-time delivery more than super-detailed invoices. You need one or two good sized ones, because this will work best when you allocate one (or preferably multiple) full sprint with a complete team on this.
  • build a business case, show them your intent to deliver more consistently and be willing to invest a bit yourself. You can decrease your own investment over the course of time, but all process changes suffer from inertia so give it some of your own momentum.
  • learn from your first couple of attempts. It is more key to persist in the process than to immediately have the good numbers.
  • make sure you deliver, so make sure you have small stories with almost no uncertainties.
  • Once you have a basic idea of how much the team can do, commit slightly under it and use that room for delivering quality and optimizing your process. This allows you eventually to move the baseline up

You’ve now done what a developer would do. Apply an abstraction layer over business metrics in order for the team to work with their own currency. You’ll have a more productive, more motivated and more reliable team as a result.

Any thoughts? Let me know!

Work ethics, rewards and private balance

/ timmeeuwissen / Leave a comment

I have seen many different work-ethics. Some people are working day and night, neglecting their own needs as a human being (trust me, it will bite you once you get older). I’ve also seen others that show no interest in company goals and strive for tops 3 hour efficiency and well-groomed social media profiles every day.

 

I’m writing this blog post because I think that with the right argumentation people can get on-track, become more efficient for their bosses, but also in their personal lives.

Believe in the company goal

It’s paramount that you believe in the company goal, believe in the people that wish to go there, and believe in the fact that you’re going to achieve that goal. If you are not certain of one of these things, you should vocalize your concerns.

Why? Because your and your peers future success, and joy in daily work rides on it. You will never be able to work really hard for something if you don’t believe in the thing you are working for. Don’t forget that you spend more ‘conscious time’ at your job than you do anywhere else. So don’t waste that time and optimize whatever can be done to achieve the best results.

When you join a new company, you should really investigate what the goals are and if they are in line with what you feel is best and fitting with where you personally want to go.

Career opportunities

Never settle for the job you’ve got, always work for the job you want. Opportunities don’t automatically come your way. It’s hard work, and if you follow the company’s goals whilst not neglecting your own needs, you will achieve more.

Especially for people in tech willing to grow, I would suggest to force yourself every once in a while to perform in an uncomfortable setting. Speech in front of 50 people, be bold (not bald, that’s another blog post) and question your PO’s or clients about choices they make. Dress for your job. Anything. Just put in more effort than is minimally required. You will see that it’s uncomfortable at first (that’s a guarantee), but will boost your communication skills, technical skills and moral. You’ll be more visible on the radar.

You can be the best programmer on the planet and create something that somehow saves the world from climate disasters, but if you don’t evolve the skills to communicate about it, no one will know nor care about it.

By setting career goals, and being willing to fall while you stumble to get there, you’ll grow.

Once you know what you want, you should fight for it. Because if you cannot fight for your own worth, then how would you be able to fight for the same thing for your boss. You should always put your own goals in the scale with more weight than the company goals. But that said, this is not a black and white world. Try to scan the horizon for every possible way you can unite these two goals in to one, and be verbal about it to your boss before you let the scale decide. When he or she cares they will pursue the exact same path (a compromise or optimum that’s in some way beneficial to both parties). If they don’t, the environment you’re in might not be the good one for you and you should consider the weight of the problem and be strong enough to draw conclusions when needed.

Be worth what you are paid for

When you’ve been an entrepreneur, you’ll know – no, let me rephrase that – you’ll feel the real value of the money that you receive each month. Money doesn’t come for free from a magic tree. It’s a hard earned currency that you and your fellow colleagues have worked hard for. There’s no guarantees that it’s there next month or the month after. That’s the stone your boss might have on the bottom of his or her stomach. The risk they take and lay awake from at least a couple of nights in the year.

Employers don’t want to make decisions you don’t like, but they need to do it anyways, or they might draw the short straw on the vow they’ve made in the beginning of your employment: I shall provide money each month so my employees are rewarded for their efforts and their families mouths fed

When you negotiate with your employer, don’t negotiate beyond that what you are really worth. Make sure you can look them in the eye when you convince them of what you are worth and believe in your words. And again, if you can’t fight for your own (fair) salary, how can you fight for the income of the company. When you feel you’ve reached your capacity, know when to stop. You don’t want to work a year with the constant feeling that you’re being less productive than paid for. There are more ways you can be rewarded than with money. Think of growth opportunities, flexibility in location an times to work from or other ways.

When you create awareness for yourself what you cost the company, you can (and should) use that knowledge when you are working. Assess if you are worth your cost every once in a while. Good bosses do the same.

Work to live, not the other way around

Work hard, play hard is a good thing to keep in mind. Charge yourself, enjoy your life and reflect on what’s happening because time flies. Nurture your home situation with the same care and awareness that you apply on work. Strive for an equilibrium. You will only succeed in one or the other if you can find a balance. Life doesn’t work in sprints, it’s a marathon.

Bottom line

It’s all about balance, honesty and positivism. One could almost say that the term ‘self fulfilling prophecy’ is a derivative of newton’s third law:

When one body exerts a force on a second body, the second body simultaneously exerts a force equal in magnitude and opposite in direction on the first body

So find your optimum. Find peace and positivity or execute on thoughts or actions that enable you to do that. Put in a lot of effort and positive energy, and the reward will eventually be as good for a long time to come.

Tips on how to conduct a retro

/ timmeeuwissen / 2 Comments

For: scrummasters and teamleads

The most important thing with retro’s is that you have them. But when you have them, there are a couple of things that you can do to optimize and get the most out of them.

When to do the retro

Try to schedule the retro after the sprint, around the moment you do your demo. Since the team will already start looking back on two weeks and see what has happened and how they can demo their achievements, this is an ideal moment.

Use sticky notes

Let everybody write down their own positive and negative points on sticky notes. Some members may come prepared with some sticky notes that they have gathered during the sprint (if you see that there’s not enough quality feedback you can suggest doing this to the team). Each note can get a + or a – in the top.

Create a board with two or maybe three lanes. A lane for things that didn’t went so well and a lane for positive things. When someone is done, let them put their notes on the board. Each member can see if one of their points was already put on the board. If so, let them stack. Big stacks, usually indicate big concerns regarding that point.

Some benefits of doing sticky notes instead of going sequentially through all members:

  • everybody can write down their own thoughts, and don’t have to remember them through the talks of others
  • you can monitor actual participation in the retro, instead of having a ‘what he / she said’ or ‘I have nothing’ answer
  • you get to know some sense of how big a concern actually is
  • you can take the notes with you to process them later and not have everyone waiting for you

What to put on the notes

It’s important not to narrow the scope of these points. Let people tell that they’ve had a good barbecue, a nice birthday or a dog that died. Because influences from our personal lives into our professional lives, are as real as the other way around. Being able to briefly share your joy or sadness on something, makes this meeting something to look out for, and it’s an easy way to share stuff with your team and fortify your future collaboration. When a team member feels heard and seen, he’ll tend to stick around longer.

Run through the notes

Start with the points of concern. This is because of two reasons. You don’t want to spoil a good vibe, and people seem to cling on to the vibe they left a meeting with. This way, the momentum you’ve built during the discussing of positive things will carry on after the meeting. Create piles of all + and – notes

Guiding the meeting

Rotate members to read the cards (different member per retro). This trains them in speaking and conducting meetings (even though this is a very small and safe meeting), which will help them in the future. Also, you’ll prevent biassing the meetings with the tone of one person that always reads the cards.

Let someone take notes, but only on the action points. So when the team discusses the cards, only write down how they think they can do better. When the meeting is over, create a page with a retro template in Confluence (or any other tool you use). Take the stack of + cards and write them on the column ‘what we did well’. Take the stack of – cards and write them on ‘what should we have done better’, and take the notes of the discussions and put them on ‘actions’.

Revisit the list of previous action points at the end of each meeting and compare them with the list of actions from the previous time. Don’t add unsolved actions to the new action list. When an action didn’t get recurrence, it fell out of grace and might have not been a thing for an action point after all. Do ask which of the actions have been done, and update your previous actions so they get marked done. You can look over-time if actions get recurrence. This enables you to detect inefficiencies within your way of working.

DoD: Distribution of Development

/ timmeeuwissen

For: tech entrepreneurs that are considering the options on where to source their development power from

It’s not an uncommon question. Should I outsource, should I create a distributed environment or should I keep everything (literally) in-house. There comes a time in nearly every company when these options will be (re) considered.

This blog post should shed some light at some possibilities and some of their pros and cons.

The candidates

Local-only

This is when you hire from your own county.

Pros

  • One language that everybody understands
  • You can easily walk up to someone
  • Trust can be established by seeing someone at their spot
  • It’s easy to bond
  • Pair programming and doing coding dojo’s are easy to do
  • You can facilitate a nice entourage and a real sense of being part of something big

Cons

  • You’ll have to reimburse travel cost
  • Hard to find competent or top-class people
  • Because you can easily walk up to someone, you basically disturb them and a lot of effective time can go to waste
  • Being at a spot, doesn’t say you are working or doing that efficiently
  • When you find someone very competent from another country, you’ll have to relocate them

Verdict

It’s easiest to start a company with local people. You can establish a brand, have short (but probably more inefficient) communication and reporting lines and you won’t have to take cultural differences in to account. Because you will have to set-up a facilitating environment anyway, it’s also a good base on which you can start working with interns and juniors so you can really supervise and even micro-manage every now and then (you shouldn’t but we all know it happens when you are still small).

 

Outsourcing

This is where you completely carry over all development to an off-site company.

Pros

  • It’s well known that some outsourced development is cheap as pennies in some countries.
  • You can prototype and work in parallel
  • You can hire for what you need. It’s scalable in that sense.

Cons

  • You might get the features you’ve asked for, but who guarantees the quality and the longevity of the code
  • You will have to meticulously write down every possible expectation of the product you wish for. Don’t assume it will be done for you.
  • There is no intrinsic motivation or personal attachment to the quality of the product
  • You will have to overcome cultural differences and stand firm when someone that works by different rules, laws and ethics disputes your requests or assumed rights.

Verdict

I’ve tried this for a part of an application, but this backfired horribly. It’s hard to gain trust and monitor the quality. You could do this if the product is in example a tool that you just wanted as a prototype to get a better grip on your value proposition. One-time, never look back applications (e.g. apps) get developed like this all the time with good results. Working on a SaaS? Don’t do it, I would say.

 

Truly Distributed

The address is a formality, this is when there is no such thing as an office. Lots of pros and cons on working distributed have been mentioned above, so I’ll try to limit the pros and cons to only that what’s important and different if you work truly distributed

Pros

  • There’s no overhead of physical buildings involved. This money can go directly in your company and its employees
  • you will start judging people on their performance. “Did they do the thing I asked of them” will be more relevant than, “did he work 6 hours or 8, and did he work in the morning or evening”.  This actually ties more in to the nature of people. Attendance is something less relevant than focus.
  • You can work from EVERYWHERE. This is true for the developer, but also for the entrepreneur. Want to travel the world, but still get payed? This is the company to join!

Cons

  • depending on how big the range of time difference is, it can be truly a madhouse to orchestrate everybody in to one virtual room.
  • it’s harder to bond with the team.
  • it’s harder to create a hierarchy or other form of ladder on which the developer can grow. Personal growth must be attended to, it is one of the prime concerns of any developer

Verdict

I have seen and heard companies succeed in this setup. It brings its set of challenges but also benefits. I think that going truly distributed is not something for the fainthearted.  Especially the entrepreneur will have to be the link between all developers. Every part of the process has to be looked at, cleaned, oiled and put back in. Is the documentation there. Is it in proper language. Are all code standards applied. Did he communicate nicely to his peers. etc etc. These are normally things you pass on to your leads and managers, but (especially when you start) should be done by the owner to ensure his company still sails the charted course. I would say that it’s not a natural first choice. You have to have the experience, and maybe it’s easiest to come there by progressively hire more external and bleed out local.

 

Externally integrated

This is when you have the majority of your employees locally, but you also hire dedicated people abroad.

Pros

  • dedicated workers for your company mean they (could or should) feel in line with the company’s goals
  • working with different cultures really broadens your horizon. You’ll become more creative in work and this will reflect to your personal lives. It’s an absolute joy.
  • no cost of commute
  • having this division, enables you to not have all your eggs in one basket. (e.g. internet goes down at HQ, or everybody resents recent management changes and strike or find different jobs)
  • When you hire through an agency, you are able to scale your external development faster.
  • The infrastructure that you should get in place (think of cameras, digital boards, good documentation, communication pipelines etc) is also beneficial for your on-site employees. All of the sudden they can also efficiently work from home
  • All communication should be in a language that everyone understands (most common is English). This future-proofs all documentation, code, etc and prepares your company for being true to serving the World Wide Web (distribute for everyone to read, all over the world).
  • You still have a place to go to, a brand that can be visited

Cons

  • once per X time you will have to gather, take the plane and meet each other for some time and do bonding. This is an expensive undertaking. I have heard from someone who actually has a fully distributed team that the cost is generically about the same as the cost of commute for local people (for a mid-sized company hiring in the same country).
  • Initial setup can be demanding on people and budget.
  • You will have to oblige to the law from wherever you hire. Some laws are really strict and can discourage experimenting with this way of working.

Verdict

When you have the time and means to orchestrate this, I’d most definitely do this. It’s a perfect hybrid form that – even if it fails to work remotely – also greatly benefits your local team.

This will only succeed if you will have someone on the other side willing to understand and work with your company. Be critical about who to hire, especially the first one. But this will also only work if people on the local side bring this person in to all relevant discussions and support whenever this is needed.

Having the mindset and the infrastructure in place, you also create a nice environment for your local employees. They can work from home whenever needed, you remove ‘knowledge lock-ins’ in your team and individual and team performance will go up.

Offshore

(in different time zones)

Extra pros

  • able to run support and development 24/7
  • the world truly is a bigger place than a specific timezone

Extra cons

  • It becomes increasingly harder to communicate when someone lives further
    • daily routines
    • planning deadlines
    • evaluations
    • establishing unity within the company

Nearshore

(in the same timezone)

Extra pros

  • Time of communicating is no issue
  • The locations are generally ‘near’, so cost and time of traveling every once in a while shouldn’t become the main reason to do or not to do it

 

Conclusion

So you’ve probably read it well. The definition of how it’s properly done (DoD), resides in the distribution of development. It might not be low hanging fruit, but the stuff that hangs higher get’s more sun you know ;-). Striving for it might already make the difference. It’s up to you to decide how to implement it for your scenario.