How I became a certified scrum developer

Introduction

Some weeks ago I attended a week long training session with the title “Certified scrum developer” (a.k.a LeSS in action), organized by the company Odd-e.

I regularly attend technical trainings in different fields, but I never wrote a blog post about them. Well, I wrote one with the title “How to do a proper technical training for developers”, but that post was the result of attending several trainings which I did not like.

This time the situation is different. I found this training really helpful and motivating. It had a clear effect on the way I'm thinking about agile software development, however there are still some points where I’m not absolutely convinced.

I’d like to summarize here what were the most important messages for me from this training.

And just to be honest: since the training I attended was not certified (even if its title was “Certified scrum developer”), I don’t have such a certificate, but it does not reduce the value of this training in my view.

The training

The training itself was very different from the trainings I attended before. The attendees have been split into four teams and each team had a workstation with huge monitors and computers (2-3 of such stations per team, each team had 5-6 members). Then during the week we simulated a sprint of working on a real product - an online game. We really worked day by day as teams in a large scaled scrum organization, and during these working days we had several sessions where we talked about dedicated topics. These sections were also reflecting on the situation in our sprint.

The first day was focusing on the refinement of the items. We did a nice refinement workshop, and we got a nice introduction into the methodology of specification by example and its connection to acceptance tests. We also did the sprint planning 1 where we decided on the items to be done by each team.

From the second day the teams really focused on the development. There was a CI system, which verified every new commit and notified all teams when something was broken. In this case one team  take over the “fix the build” responsibility. We were doing mob-programming, so usually 3 people were sitting in front of the same computer. There was a navigator of the mob session (who had the keyboard) and others who gave the instructions. The lead of the session has been changed regularly. We started every morning with a daily stand up and we evaluated the results of the day at the end of the day.

In case of any questions we were free to ask the product owner or even the customer. We also had to sync regularly with the other teams, since we had to touch the same code and implement similar functionality.

It was really exhausting, because the training was every day between 9 and 6 and it was really intensive. After the first day I almost lost my voice from speaking too much.

Although I've been working in a LeSS team for about a year (you can find my post about my first experiences and my later experiences part 1 and part 2), but this level of team work with continuous mob-programming was still something new for me.

The main topics of the sessions were: how to work in team and in pairs, how to do proper TDD, how to write good quality code, refactoring and how to do it, how does an agile organization look like, software architecture and design in agile development etc.

None of these topics were absolutely new for me, but they showed me these topics from a totally different perspective with very good practical examples, so I learned a lot.

Finally we closed the week with sprint review and a retrospective, where surprisingly most of the planned features worked properly.

The most important messages for me

First of all I have to clarify that I’m not a religious scrum believer. I started my career in an organization where we followed the classical V-model very strictly. There I have seen some advantages and a bit more disadvantages of that way of software development. Later on I worked in multiple projects which were following some kind of scrum organization, and as I have already mentioned, I'm currently working in a LeSS organization. Here I also see several advantages of the development process, but also some disadvantages. However, I have already realized that some of the disadvantages I observed were because of the wrong adaptation of scrum. So I think learning something new about agile development methodology can only help me. And to be honest this training helped a lot. Here I would mention some important points I learnt.

Proper way of specification by example

I already heard before about the idea of specification by example, but it was nice to apply it in practice. The high level idea is to describe concrete scenarios for your software with exact input and output data and use them as specification. To cover multiple cases (even the corner cases) you can organize the input values (and the expected output) into tables.

This way you can describe your requirements in a way which is well-readable by everyone, even for non-developers.

Additionally you can easily write automated tests based on these scenarios by using some acceptance test framework.

Taking a first bite

It is always a problem to refine and estimate tasks for topics which are absolutely new and unknown for the team. If we have no idea about the topic, how can we estimate it or how can we ask the right questions regarding the task?

The idea of taking a first bite is a solution for that. It means to first take something really small and easy from the topic, work on that and solve it. In the meanwhile you are becoming more familiar with the code base, so as a next step you can take over (and refine) a bit more complicated tasks with the same code. And keep on following this strategy until you are feeling comfortable with the code and topic.

How to do very proper TDD

TDD is a very popular buzzword nowadays. Basically the idea is to implement the code and the unit tests in parallel. But just like in the case of other popular buzzwords (SCRUM etc.) it is also pretty often misunderstood or misinterpreted.

The proper way of TDD is to always implement one test case (better to say, one check for your unit test), let it fail and then make it working in the code with the possible smallest change. Once it’s done you can do some refactoring to make your code nicer.

What is pretty strange for me is that you shouldn’t write more code than really needed. You really have to behave like you are being stupid.  For example if you are adding code where you know that you will have three different cases, you are not allowed to prepare your code for multiple cases as you are implementing the first one. It is absolutely against the way, how I usually work. I’m always thinking about what can be expected in the near future and implement my code to support these upcoming changes. It will still take some time to change this mindset.

The power of strong teamwork

I already realized before this training that teamwork is a really strong power. This training ensured me once again about this fact. I heard several times that pair programming is just a waste of resources, earlier I was not sure if it’s true or not, but now I’m sure that it’s not true. Simply the fact that we were doing mob programming all the time let us learn a lot and helped us to avoid making a lot of mistakes. And the flat communication channels also made it possible to detect issues in time.

However I have to mention that it is mentally really exhausting to work in such a way.

Software architecture in SCRUM/LeSS

There’s a really huge gap between the idea about software architecture in classical development models and agile models.

In case of classical development models software architecture is predefined, planned, well-documented and more or less static. Static in the sense that it should change as little as possible during the development.

In case of agile development there's usually a different practice. The architecture is not really planned, it just happens. It is just the actual state of the code and it is continuously changing. However there’s still a place to talk about the current architecture and to make architectural decisions.

The world is not always ideal

This was maybe the most important message for me.

The world is unfortunately not ideal. There are always issues which make it difficult to implement a proper scrum or to follow proper TDD. There can be thousands of reasons.

All these methods we learned about are working in an ideal world, but even if the situation is not optimal you should make the best of what is possible and try to optimize it.

Remaining open questions

There are some topics where I am still not totally convinced about scrum. Let's see those points.

How to apply scrum with less social developers

There are a lot of programmers who are not so good at communication and other social activities. For some of them that was the reason to become a programmer. But the world changed and soft skills became very important for developers. Especially in case of agile development models.

Of course these soft skills can be improved, but I think we can not expect wonder from developers who are not good at it at all.

I met a lot of developers who had very good technical knowledge, but they could not communicate with their team properly. What’s the future of these developers? How can they be integrated into Scrum teams?

Does it really make sense to avoid thinking about long term software architecture?

It is clear that software architecture is changing frequently together with the requirements. But there are  several cases when upcoming functionalities can be seen in advance. Does it really make sense to use a simpler solution and implement a more complicated one some sprints later if it is already known that the complicated one will be needed soon? At this point I’m still not totally convinced.

How to make sure that our unit testing is really done properly?

The way of TDD is to write test cases and to implement  related code and to keep doing it until we can not think about additional test cases. Well, but these test cases are really just up to us. How can we make sure that we really covered every corner case if our test cases are not connected to any kind of requirements? It is really easy to miss some points.

How to plan an agile project?

Well, agile projects are dynamic, flexible and open for changes.

However in case of projects the question is very often pretty simple from the customer: I need a software with this and this functionality: how long do you need to implement it and how much does it cost.

In case of classical project management both questions can be answered based on some estimations, however these estimations are not always proper.

But how to answer such questions in agiles modus?

Is pair programming always worth it?

I have already mentioned about the power of teamwork. One of the most common teamwork practices is pair programming. It really helps a lot, it makes the knowledge session much faster and it helps to improve the code quality. However there are tasks which are pretty easy, repetitive and even a bit boring and not challenging at all. I think there are such tasks in every big project. Is it really worth it to do pair programming for such tasks?

Final thoughts

I really liked the training. This was the most interactive training I have ever attended and I really appreciate it. From the content perspective it was nice to see a lot of things in practice, it helps much more than just reading about these topics.

It was really a pleasure to have hands-on experience with this way of working: strong teamwork, mob programming, TDD etc.

It was really active, so it is not possible to mention everything well-detailed in this post, but that was not my goal.

It clarified a lot of things for me, but I still did not become a religious scrum believer. I still see a lot of advantages of this working methodology, but it also has its own cons.

You salary is less than it could be! - How to negotiate your salary at an interview?

Introduction

Most of the companies handle the salaries as a secret and it has a cause. I am pretty sure that you have colleagues whose knowledge, experience and performance is worse than yours and they earn more and you. And there are of course colleagues who are better, but earning less. How to be part of the first group and earning more than the others?

Of course this question has a lot of factors. You can ask your boss for a raise. It is also important to change the companies at the right time. But where you can win the most is the negotiation during the interview process. To expertise your skills in this activity first you have to understand the view of the other participants.

The view of the company

If a company is hiring for a new position that means they have some work to be done, so they are looking for someone, who has the right skills to overtake the position with a possible short ramp-up time. Usually they have a clear view which skills are required to overtake the position. It is also important for them who is supporting them on long term, since a new change has a lot of extra cost and effort. And of course they are looking for the cheapest well-working solution. They are either hiring someone who is owning all the skills or someone who is lacking some of the necessary skills, but can be trained fast. Of course the one having all the right skills can achieve the highest salary, since there are no extra costs for trainings.

On the other hand, the company can only see from your skills what you are showing through the interview process. To be honest here you can present yourself a bit better as you are by concentrating on the skills which are really required for the position.

But in the end, the company has always a planned salary for the position, but usually it if defined in a range. If you have all the needed skills you can reach the maximum of this range. But unfortunately most of the cases this range is not public.

The view of the recruiter

Really often you have are first negotiating your salary with an external recruiter. The only goal for this recruiter to let you join the new company, since they are paid after the successfully hired candidates. So the recruiter can go to the company with some prepaid facts: there’s this guy, with these skills, expecting such amount of salary. As lower is the salary expectation, higher is the chance that the company applies you and the recruiter gets the success-bonus. That’s why the recruiters try to ensure you that your expectations are too high. They are often using phrases like “this is the realistic salary” etc. Don’t believe them. You have other ways to figure out what is your realistic salary.

Your realistic salary

It is very important for you to figure out what is your realistic salary. It is up to the company, up to the position, up to the city and up to your skills, that’s why it is not easy to find the right range. It makes it more difficult that in most countries salary is handled as a sensible information. People don’t like to talk about that.

Don’t use your current salary as a reference, it can be that you are really underpaid, but it is also possible that you are changing to a place where your responsibility is less, so that your current salary is not a realistic target. If you are changing the city that can make a really big difference on the realistic salary.

The first source you can use is the internet. There are websites, like glassdoor which can give you a good base, based on the inputs of the others. But in several cases it has simply not enough, or only obsolete inputs, so that it is not telling you a realistic value, especially if you are checking a smaller company or a smaller city.

It also worth to read to feedback about the company on different pages, like google maps, etc. Just google the name of the company and the city. You can find there often information which is comparing the salaries to other companies.

The most efficient way is to ask others who changed their jobs recently. Don’t ask them about their new salary, but ask them about what they think, what would be a realistic salary for you. It can also give you some guess.

Before you start to negotiate your salary, you should have a range in your mind about your realistic salary and don’t accept anything that is below this range.

How to negotiate your salary?

First of all you should show your best side during the recruitment process. Send a well-prepared CV with do your best on the interviews.

You will be might asked for your current salary. Just answer that it’s a personal info. Do not share it. Then you will be asked for expected salary. At this point you have to tell the higher limit of the range what you just determined, maybe a bit more. Most likely they will try to offer a bit less. If that amount is still in the determined range and it is not much less than the amount you told you can expect it. If it is much less or it is out of the range just tell, that sorry it is too less, then you rather search for something else. You may be asked for what is the lowest salary you would accept. Here you should tell a number which is just a bit below the first amount you asked.

During this whole process be patient, friendly but self-confident and very determined. You should show yourself strong and professional. Avoid answers like “let me think about this offer”. That would show weak and unconfident.

The most important point: if the company can’t give you an offer which is fulfilling your expectations, just keep on searching. That’s why it is good if you are not in a hurry at job searching. That makes you more confident.

It is always good to do 2-3 interview processes parallel, so that you can choose the best offer in the end.

Summary

To negotiate the highest-possible salary is not easy at all and the worst part is that you can never be sure that you reached the possible maximum. But it makes sense to take some time to negotiate. Because a higher starter salary makes an effect on your whole career at that company.