The World's Greatest Workplace

Do you wake up in the morning with a big smile on your face? Is it because it is another day at your job? I guess not. However we all hope that someday we'll work in such a place.

This TED talk is about an amazing Malaysian company that its goal is to become "The World' Greatest Workplace".

The founder of the Mindvalley company describes why his employees jump out of their bed every morning so they can go to work.

 There are FIVE principles that the company does in order to become the "World's greatest workplace":

1.       Happiness – they built an advanced and a beautiful workspace for the employees while giving them the freedom to use it (reading a book on a hammock). They allow their employees to decide when to come to work; it doesn’t matter if you work at night or on a holiday as long as the work gets done. They also arrange parties and festivals for the company and try their best in turning their employees into friends acknowledging that friends work better than random people.

They have turned their weekly company meeting into "weekly awesomeness report" which looks more like the "Daily Show" than a company meeting.

2.       A Noble Mission - The Company has a grand mission to touch 500 million lives using their company's products and knowledge. All the employees share this goal.

3.       Quests – They use a lot of gamification principles in order to make their work day as a game.

a.       Badges for achievements as desktop icons that everybody can see like "The Flash Badge" for the employee who finished his tasks the fastest and etc.

b.      Every team submits their high score in the end of the week and they try to improve it on the next one.

c.       They have an inside website where all the employees can vote for other employees and tell them how great they are, they also can send an icon or a badge to another employee in order to thank them for something – imagine coming to work and getting a note telling you how awesome you are.

d.      "S.P.L.A.S.H" – an inside group of employees that nobody in the company knows who is a member of it. They have a secret budget to do funny things every two weeks like a "Starbucks day" when every employee gets a cup of coffee when he gets onto the office or a mustache day when all the men gets a fake mustache and they have to wear it for the entire day. The little things are what make the people happy.

4.       Personal Growth - 45/5 rule: Every employee works no longer than 45 hours a week while 5 hours from it are dedicated for personal growth. The company wants the people to invest in themselves and become greater. Another special thing is that every employee shares his top life goals that he wishes to achieve. The managers and the other employees try to help each other in achieving them. You can truly know your employees by helping them achieve their lifetime goals – that what makes a true connection.

5.       Tribal Dynamics - Become a tribe. Just watch it. It's awesome.

If you are a founder or a manager of company make the employee's happiness as your goal.  Don’t focus mainly on your revenue or the productivity of the company, is not the main issue, when you make people excited so hard that they want to jump out of the bed every morning to go to work then the people will find creative ways to improve productivity, get the work done and increase the revenue.

By the way if you are a team leader and your company is not the world's greatest workplace yet then you should imply those topics on your team where the team members happiness  is your responsibility (a festival in Paradise Islands is not needed, a nice day outside the office will do).  Maybe it won't make your company the "world's greatest workplace" but it will make your team the "world's greatest team".

"Work, play – makes no difference to me. It's all just living."

Tomorrow is work

Enjoy

Help Pages for ASP.NET Web API

Let's say that you have a web application with some web services. A user or an application that wants to use your services must know your api. In order to expose your api you can write some manual documentation or you could use ASP.NET Help Pages which is a really nice feature that allows you to automatically generate a help page that displays your whole REST api.

Enjoy.

TED: Find mentors and read books

This is a great lecture about making your dreams come true. 

We all want a good life. We all want to be great. However greatness doesn't just come to us. We have to pay for it. We have to invest in ourselves - become greater and constantly achieve new goals.

We can do it by our self the hard way but there are people who've already succeeded, people who can teach you and guide you - they should be you mentors. Find them! They could be your shortcut.

Some of the greatest mentors in the world are dead and others are unreachable (perhaps Bill Gates will answer my emails some day), that doesn't mean that you cannot learn from them. Read their books, their blogs and listen to their podcasts and interviews. If you want to be great you must learn from the great.

I want a good life. I'm not there yet, it will be hard, but I'm willing to pay for it.

.

Why should Agile NOT be destroyed

Bar, a friend of mine sent me an article with the following title: "Erik Meijer: AGILE must be destroyed, once and for all". Without reading it I instantly knew that it is about someone who obviously doesn’t understand Agile at all and probably hasn't really ever tried. It is just one of those articles with "great" titles that doesn’t have real content in it. Nevertheless since I truly adore the Agile methodology I've decided to comment.

Anyone who have heard me speak about Agile knows what I don't believe that Agile has invented something new for the software industry. Agile, Scrum and all the rituals (sprint planning, retro etc.) are just labels that we, the developers, have added to several best practices that are just the right things to do and every project should use them.

Agile and Scrum in particular makes your whole team responsible for the project and not just the managers, it brings the team members closer to the client and to his world while truly understanding the purpose of the project.

It makes you measure your work and progress allowing you always to know the project's status and if you're not going to make it to the dead line.

It makes the development process transparent for the team, for the managers and for the clients allowing you to code and not be stuck in an endless status meetings lifecycle.

It makes the whole team responsible for the whole project and be familiar with the whole project's code base.

It allows the team leader to be part of the team and code (!!!) since the whole team is self-managed using a clear and defined process of work (sprint planning - daily meetings – review - retro). It makes the TTM (time to market) shorter by developing the most important user story that the client has defined.

The most important part it forces the team to constantly improve while sharing their insights from the sprint in the Retro. 

You see, all those things are good for the project, for the team, for the client and are just right! This is how it should be! It doesn’t matter if you call a short period of time where you design, code, test and deliver a feature "a sprint". Agile has gathered all those best practices in order that your project will succeed!

So what does this Erik guy actually say?

Stand-up meetings in Scrum are an annoying interruption at best, or at worst one of the mechanisms of “subtle control”, where managers drive a team while giving the illusion of shared leadership. “We should end Scrum and Agile,” he says. “We are developers. We write code.

What will happen if we'll "just write code"? We will not know what the other team members are doing, we will not share our problems with the team and more important we will not commit to the team or to ourselves on a daily basis. The daily standup meeting (DSM) is a commitment of every team member to the rest of the team and to himself. Furthermore the DSM is the place to check the "Burndown" chart and verify that our planning matches the reality and truly be notified that we are not going to reach our goals.

 Let's examine more Scrum aspects:

The Sprint planning

People like Erik will say that it is a waste of time, tell the developer what to do and he will do it. Sounds good right? The developer will finish the feature and that’s it. But what about the other team members who didn’t see a single line of code from this feature? How do they supposed to fix the bugs or improve something there? Do you count only on a single developer? What happens when he leaves? And what about the estimations? How do you estimate the time developing a feature will take? I'll tell you – you make an assumption that is probably wrong. It is impossible to estimate how much time precisely a huge feature will take. So if you know in advance that you'll be wrong and you keep on doing it you are simply lying to your client. By the way an assumption means that you make an Ass of yoU and Me (Asume).

The sprint planning makes all your team members truly understand the feature and the task and it allows you to realize in advance that someone didn’t understand the task and so to avoid failure. All the team members have the chance to tell their estimation and to explain themselves. This way all the developers are on the right page. If someone doesn’t understand the task you can immediately see that since his estimation is be different from the other team members. You will invest all the time that is necessary in order that this team member will understand the task, you will even let him take the task and sometimes you will pair him with your best developer so that this team member will become better. And since the sprints are only up to 2 weeks long you will seriously reduce the amount of "unexpected events" that might fail you estimation – your commitment to the client is backed up by all your team members.

The review

You know why there are a lot of developers who hate their job? It's because they are not getting any recognition or since they don’t understand why they do what they do. The review gives them both. The client and all the managers can come to the review meeting and congratulate the team or that junior developer on the great job that the team has done this sprint and more importantly – why this this feature is so important to them. That means the world to them. That what’s keeps them going even when the time gets rough. 

My mom works in a bank and every month or so the county manager arrives to their branch and congratulates the whole staff for the great job they did. She always gets so excited. By the way – they didn’t give it a label – this is just the right thing to do.

 

The retro

Erik says that the meetings in Scrum "are an annoying interruption at best, just let the developers code". 

This is wrong. If you keep on coding and not stop sometimes and just talk you will never get better. Your team will never increase performance, improve the estimation accuracy, delete all the distractions and preserve the good things that they do. You have to stop and ask yourself and all your team members: what was good and what should we improve. You have to let all your team members speak since you cannot know all the things that bother them. A team that shares the faults along with their successes is a team that improves. And a team that constantly improves will deliver a better product and will make its client satisfied.

 

I hope that I've showed you some of the "secret" benefits of Agile and Scrum and I truly hope that you agree with my belief that this is how you should manage a software project and this is how you should develop a project that you want to be successful. Even if you won't do "Scrum" you will make a lot of errors that could have been avoided if you did.

Internalize that you don’t see the whole picture and that you need all your team members to be responsible for the success of the project. You need to work differently.

You need Agile.
You need Scrum. But don’t just use the label – use what it stands for!

RavenDb 3.0 Wow features

The last time I wrote about RavenDb was two years ago, RavenDb is a great documentDb that has changed a lot since then and now has clients for C#, Java, Python and Node.js. In this lecture Ayende Rahien demonstrates some of the "Wow feature" from the new RavenDb 3.0 version.

Enjoy

TED: Your body language shapes who you are

Great TED lecture that shows how our body language affects the way we think about ourselves, the impression we create on others and basically how it shapes who we are.

So next time you will be facing a job interview, a presentation you are giving or anything you want to be awesome at remember: a couple of minutes before that job interview  stand in a "victory position"

and not in a "I'm afraid" position.

Think about it ;)

UI Tests vs Visual Layout Tests - part 2

In the previous post we understood that testing only the UI logic is not enough and that manually testing the layout across all the platforms that our application supports is impossible. We need to automat it and add it to our continuous integration process.

What is Automated Visual Layout Testing?

*Later I will introduce a platform that automates the whole process, but first some basic concepts.

Baseline

In order to verify that our layout is correct we need a "baseline" – pictures of our different website/application pages/windows. Those picture are "print screens" of the layout as it supposed to be presented. After we manually verify that the layout is correct we set them as "baseline".

Image Comparison

From now on each commit will trigger a comparison between the new pictures of the application and the baseline in order to check whether the commit's changes changed the layout. The comparison is not as simple as it sounds, if you try to compare "pixel to pixel" you will see that a pair of identical pictures are not really identical.

Take a look on these 2 pictures:

This pair of pictures is a close up to the "the" word in the sentence. The pictures look almost the same but if you look closely then you will see that not all the pixels have the same color or the same brightness. However then you zoom out and look at the "the" word in the sentence it will look absolutely the same. Those differences accrue since the browser/the operation system doesn't render the pictures the same way, it depends on different parameters that I don't want to talk about them in this post.

More examples:

Conclusion: Two identical pictures to the human eye are not really pixel to pixel identical.

That makes image comparison a lot harder. Luckily there are enough "smart" image comparison algorithms and tools out there, one of them is a platform called "Applitools eyes". More about it in the next post.