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.

UI Tests vs Visual Layout Tests - part 1

In my post The Pyramid of Tests I introduced the different levels of testing that you should have in your application. In this post I want to focus on the UI testing phase.

UI Testing

In order to fully test your application you have to write unit tests, system tests and integration tests to fully cover you business logic and the systems workflows, however that's not enough. You also have to test the UI of your app, to verify that it displays the right output, check that the different UI elements behave as expected and so on.

In the past we used to manually test it – click some buttons, enter an input and assert that the output was as expected, nowadays we use automatic UI testing frameworks like CodedUI, selenium and protarctor. These frameworks allow us to record the actions we used to perform manually and run them automatically. Now our application is fully tested. That’s all we need right? Wrong!

Checking only the UI logic is not enough!

Even if the logic is correct it doesn’t mean that the application is ready to production.

This is a screen shot from a website where the graph width didn't match the screen size any more.

Another example is a bank website where all the letters in the site turned into gibberish. UI Logic tests will not find those errors. Obviously we cannot allow our self to have an application with these errors in production. That means that besides our UI Logic tests we also need to test the Layout.

In order to fully verify that the layout is "correct" we need to test it on all the possible browsers – Chrome, Fire Fox, IE, Opera and on all the possible screen sizes – PC, Tablet and the different mobile devices. You do it since the CSS that suites Chrome doesn't look the same in IE and the HTML tag that you've used on one platform behaves differently on another one.

Let's say that my last commit included some CSS changes, those changes didn't affect any logic however they might ruin style in some place in my application, my UI Tests will not find it since they check the logic and not the style itself.

As you can see the tests matrix is too big and it is not possible to manually test it.

We need to find something else...

Introducing Visual Layout Testing. Next post.

Kanban and McDonalds

Keep reading. The title is correct.

You wake up one day and decide to eat a burger in McDonalds (not so good to your health but who cares).

You enter the closest McDonalds branch and you stand in line. You wait for your turn to order.

You wait patiently until it is your turn.  Then you tell the nice kid with a cap the details of your order.

After that your order is displayed on the monitor above the desk where all the previous orders are displayed. You can immediately see what your order status is – is it the first order in the list and the kids in the kitchen have already started working on it or are there some orders before yours, and you need to patiently wait.

Meanwhile the kids in the kitchen receive the orders one after another. They work only on the first order in the line (not the shouting dude's order). If there are lots of orders then more kids come and join the kitchen (or the front desk) to help handle all the clients. When they finish working on an order they "send it" to the guy responsible on calling the hungry person who asked for it.  You check that the order is indeed what you asked for ("I asked for no onions!") and then sit down and enjoy your meal.

So what does McDonalds have to do with Kanban!?

Let's take a look at the roles here:

·         The client as the hungry dude (yes that's you)

·         The product owner as the kid at the desk who receives your order

·         The developers as the kitchen kids

The clients comes to the product owner (who can be the team leader) and describes him what they want. The PO adds the client's user story to the backlog according to its priority (someone is really hungry and is in a rush and a VIP might be before someone else) and here's the important part – the backlog is shown to everyone who wish to see it! The board above the desk shows all the orders and their statuses so if a client wishes to check his order all he has to do us look up.

The main purpose of this is transparency in order to calm down the clients, so that they won't bother the desk kid every second with annoying questions – "Hey remember me? What's up with my order? Why I'm I still waiting? How long does to take to make a burger?" If all the kitchen's work is displayed for everyone then the clients are calm and are patiently waiting. They understand that there's someone before them and that McDonalds actually work and not just stall time.

Meanwhile, inside the kitchen the kids work on the orders. They don't randomly choose what to work on – they have a prioritized list of orders (Backlog with user stories) and they work on the first order that the desk transferred to them (The one with the highest priority). They divide the work among them (divide user stories to tasks) and every kid can make any part of the order. So if "Moshe" is sick the team still is able to make the whole burger and even the French fries.

The manager, an older kid, can easily know what the team is currently working on without endless status meetings with the team (or the team leader), he just looks on the board, the same as the clients since all the work is displayed to everyone.

When the order is done the client is being called to the desk to take his order. He performs a quick review and happily goes to eat his burger.

Ladies and gentlemen this is pure Kanban (I didn't cover the limits part or indicators of work – that's for another post).

McDonalds is working like this for years, they called it "Great Customer Service", we - the software developers who instead of burgers make software (or develop\support hardware infrastructures) called it "A card" – in Japanese.