First experiences with Large Scaled Scrum

Two months ago I started at a new company. At this company we are following a working model which is much different than anything else I experienced before. This working model is called Large Scaled Scrum (LeSS). At the beginning it was very strange for me, it was totally against the mindset I had before. Right now I think I could already change my mindset partially, but I still have a lot of challenges.

What is LeSS?

LeSS is an Agile framework which is scaling SCRUM for really huge projects. It is trying to keep the organization as simple as possible without a big hierarchical system. It is mostly following the classical SCRUM events (sprint planning 1-2, daily standup, retrospective, review, backlog refinement etc.). Main values the are multifunctional, self-leading teams, learning and flexibility. You can find more info on page https://less.works/.

What does it mean in practice?

What I am describing now is the adaptation used in our organization. It can be that it is sometimes differing from the official theory of LeSS.

As I started at the company I became an official LeSS practitioner by taking part on a 3 day long training. Here I became familiar with the whole theory. Afterwise I joined an already existing team.

Our team has 8 developers and a scrum master who is also taking part in the development. Our task is basically end-to-end development: clarifying the tasks, architectural decisions, development, testing etc. The main concept is that none of the tasks are assigned to individual developers, they are all assigned to the team. Usually we have less tasks than team members and we are doing pair or mob programming (programming in a team). That means we are not usually sitting alone in front of the computer. The goal is that all team members should have an overview on all topics which are done by the team. The responsibility is also shared within the team.

Why is it so strange for me?

I have been already working in working models where I had my own task, which I was responsible for, I needed to implement it, I needed to hold the due date and if there was a bug in my code I was responsible to fix it. Additionally in the last time I was a technical leader in my project, so I was also responsible for the work of others. One hand I enjoyed this kind of responsibility, it made me feel good to tell that: “this is a functionality implemented by myself”, on the other hand it was of course stressful as well.

In this current working structure it is not the case anymore. On most of the tasks we are working with 2-3 team mates. Really often the code is note written on my computer, it is not pushed with my name. I am not feeling myself so much responsible anymore.

It also involves an other big difference in the way of working: earlier I was often sitting alone in front of my computer, listening to music and not talking to other hours long. It is not the case anymore. 90% of my time is about communication, sitting with someone and talking about the problems. I totally did not use to do it in this way.

In fact I’m learning a lot about different topics, working on many tasks, but I will never become the expert of the topic, I will never become the owner of a functionality.

What are the advantages of LeSS?

There are several advantages of this way of working what I can see. For example, due to the shared knowledge and responsibility, if someone becomes sick or has a holiday that does not have a big effect on the results of the work: the others have also all the knowledge, so they can just continue from where it was finished on the day before. And anyway multiple people are working on the same topic, so minus one does not make a big difference.

It also saves a lot of efforts at knowledge transfer. I had always bad experiences with situations when someone left the team: all his collected knowledge needed to be transferred to the others, it took a long time and it was not always effective.

In this model it is also easier to give tasks for junior colleagues: they can join the more experienced colleagues and learn very fast.

Due to the lot of pair and mob programming the code quality is also better and a lot of good ideas are coming up during talking about the tasks.

Also by lacking hierarchy the company is saving all costs of having multi-level management.

The stress caused by due dates is also pretty clear less and the time spent by randomly surfing on the internet in working time is also much less due to the pair programming.

So I can see pretty clear advantages of this way of working.

What are the biggest disadvantages?

On the other hand it reminds me a bit on the theory of socialism: shared responsibility, everybody is just doing his best. But in the end no one is really feeling himself responsible for holding the due dates, solving problems or making technical decisions. Really often we are just talking hours long about alternative solutions and no one is there to finalize the decisions, so we are just talking and talking and not making a clear decision.

I’m also lacking the career opportunities: in classical working structures there are hundreds of roles which can be overtaken and which are making some changes, some step further into the career, here I can not see much of them.

I’m also lacking the feeling that I can tell: “it is my code”. Maybe it’s childish, but that’s what I feel.

I also have issues with the communications: there are so many communication channels, that it is really difficult for me to collect all the relevant information.

I also have the feeling that the project is really lacking someone who has a good technical overview on the whole project, like a software architect. When we need to use an interface really often no one can tell us which interface is it and a lot of interface are duplicated.

Last but not least I would like to mention that the permanent pair and mob programming is really exhausting. It is really difficult. The team members needs very good social skills and a lot of patient, which is not typical for most of the programmers.

Summary

I didn’t expect that this change will be so big for me, it was also surprising for me that a working model can be so different from everything I experienced before. With time I’m changing my mindset and my feelings regarding this working model is also changing permanently. I am often asked if I think it is more effective, than classical way of working? To be really honest, I have no idea. We are loosing time by assigning multiple people to one task, but we are winning a lot of time by reducing review and knowledge transfer time. I would like to also clarify that these are my personal experiences, other developers may have different opinion about this way of working. I plan to write again about this working model after several months, maybe my opinion will change again.

The rules of efficient meetings

Most developers hate meetings. They have the feeling that meetings are just waste of time. But meetings have often a purpose, they can be important. They makes sense and they have an effect on short term or on long term. I collected some points about how to make meetings in an effective way, which is also good for developers.

1. Always have an agenda

You should have some points what you would like to talk about, so that it is clear for everyone what is the purpose of the meeting. Put it into the invitation.

2. Invite only necessary people
   Don’t invite people, who has nothing to do with the topic. They would just waste their time.
3. Not everyone needs to take part on the whole meeting
   It can be, that for some of the participants only 1-2 agenda points are relevant. Let them leave when their points are over.
4. Everyone should have the right to decline the meeting
   Everyone can decide about his own priorities, so everyone should have the right to the decision to do some higher priority job instead of taking part on the meeting. So no one will have the feeling that he could spend his time much more effective.
5. Have a meeting invitation with timeframe
   Always send out a meeting invitation with the start and the end of the meeting.
6. Hold your timeframe
   The meeting should really happen in the timeslot when it is scheduled. Don’t be late, don’t make it longer!
7. Follow the agenda strictly
   Follow the agenda, don’t start to talk about other random topics. If new topics are coming up schedule another meeting for them.
8. Make meeting minutes
   Takes always notes about the meeting and send them to all participants after the meeting. With that you can make sure that everyone has the same understanding and no one will forget the content of the meeting.
9. In case of regular meetings: if you don’t have topic, just skip the meeting
   It is really typical that the team has for example a meeting every week. And even if there’s nothing to really talk about they still have that meeting. Why? Really, why? Just skip it in that case!
10. Pay attention on the meeting
    If you are already on the meeting pay attention on the meeting: no laptop, no phone, no e-mails!

There is one meeting which is really popular nowadays and it is a bit special, so I would like to mention it separately: this is the daily standup meeting.

The purpose of this meeting is that all team members can share his own status with the team. In theory the team should stand in a circle and each team member has maximum 2 minutes to answer 3 questions: what did you do yesterday? What do you plan for today? To you have any impediments? It sounds easy, but in practice it really often turns into detailed discussion about technical issues, which is simply not the purpose of this meeting. So my suggestion is: if any of the team members would like to reflect on the status report to the other team members just do it face to face after the daily stand up. So that you are not stealing the time of the others.

How to negotiate your work as a developer?

Effectivity has a different meaning for a manager and for a developer. As a developer you know about the task how complex it is. In case of managers sometimes you are doing something using really all your power, you think you were really fast and the management is not satisfied with your, in other cases you do something easy and the management will be really satisfied. Crazy…

The point is that as a developer one of the most important soft skills is the knowledge, how to sell your work. How to negotiate with the other how complex is what you are doing. If you are negotiating well you can make the management more satisfied even if you keep do the same work as before. It can be also useful to know how negotiate your work if you are working directly with the customer or if you are discussing with other developers.

So the goal is to show someone else, who is most of the cases not so experienced with the topic, that your task is taking a bit longer. These people often things that “you just need to add one more button, it shouldn’t be complicated”. What it means in the reality? You need to setup the environment, understand the existing code, change the frontend, change the backend, setup the communication between the frontend and the backend, test your functionality and update the documentation. Furthermore you need to take part all the meetings related to the topic. And all of this takes time, pretty long time, even if the functionality itself is not complex.

Earlier I have written about how to do an estimation. Now the topic is how to let your manager/customer understand your estimation.

If you are simple replying that “Well, to add this button will take me three and half days”, then the answer will be simple “no way, it is too much”.

First rule: always ask some time to investigate the task. It makes the feeling that you are doing a really professional estimation instead of bullshitting and of course you can also consider all circumstance which can influence your estimation.

Next rule: split your task into several subtasks (more is always better). And make an estimation for each of the subtasks.

Like:

• Setup working environment (get source code, compile it, install dependencies): 4 hours
• Read all documentation and understand the current implementation of the button functionalities: 4 hours
• Plan how to add the new button with the expected functionality: 2 hours
• Add button to the frontend following the current design: 2 hours
• Implement related functionality to the backend:4 hours
• Implement unit tests for the new functionality: 2 hours
• Connect backend and frontend: 2 hours
• Do functional level testing on multiple operation systems and fix potential bugs: 4 hours
• Code review and integration with the current code base: 2 hours
• Attend related meetings (planning, demo, review etc.): 2 hours

SUMMARY: 28 Hours

So now you showed that is takes 28 hours, which is exactly three and half working day. Most likely some of the points are a bit overestimated, like most likely integration won’t take 2 hours, but nevermind, at each task there are some unpredictable issues which takes time (not working compilation, magic bug, huge git conflict etc.), you can use the overestimated time there. Now since you have a nice detailed list noone can really tell anything against your estimation.

You need to always see the following: for most of the subtasks are used either 2 or 4 hours as estimation. It is on purpose: 2 hours is small enough, so no one starts to negotiate that “Could it be done in 75 minutes?”. No, 2 hours is short enough to be acceptable for any task. 4 hour means that it is more complicated than the 2 hour-long subtasks. Against that it is also difficult to negotiate: if the other task takes 2 hours and this one is more complicated then let it take 4 hours, which is a bit more than 2, fine. If your estimation for a subtask would be more than 4 hours split rather the subtask in multiple one. Because if you are telling that “it takes 10 hours” then it is easy to tell that “It should fit into 8 hours”. But if it is splitted into 3 clear subtask no one will argue.

It is also important: find names for the subtasks which are easy to understand also for the one who are not technically deep in the topic. It makes the feeling for the manager/customer, that he totally understands what you are doing (even if it is not true) and it makes more trust.

When you are talking about your estimations user phrases like “based on the experience from previous tasks”, “it is similar to one of my previous tasks”, “last time unit testing took also so long” etc. It makes the feeling the you are really professional and you really do what you are doing.

If the customer/manager still thinks that it takes too long you can just tell, that “yes, I see, this is current estimation, we can make it faster but leaving xy sub functionality”. So always offer a limited functionality which takes pretty clear less time for your to be implemented, but never tell that you can do the same functionality in less time, because it makes your whole estimation meaningless.

These are all my tricks I used at negotiation, I hope they are helping also for you! If you have other good strategies feel free to share them!

7 good opportunities to do networking as a software developer

Networking is really important nowadays independent from that what you are professionaly doing. Networking means to know the right people, who can support you in case of need (and of course who can be supported by yourself). To have a good network as a software developer means that if you would like to change job you are not applying blindly for jobs, but you are asking your network for opportunies. Or if you need new colleagues you are also just asking your network for recommendations. A good network means to get better opportunities faster.

That’s really nice, but how to extend your network? First of all normally you are having a network from your workplace: colleagues, customers. Keep connection with them. But usually they are not changing frequently, so it is good to find other ways to extend your network. I collected some ideas.

LinkedIn

First of all you need to be registered to LinkedIn. This is a professional social network, where similar to Facebook you can manage your friends. Your profile is like a CV. LinkedIn is the best place to find new job opportunities and to extend your network with the right people. Really often the job opportunities find you, unless you did anything. At the beginning set up a strong profile, connect your current network (colleagues, customers, ex-colleagues, friends from university etc.) and wait until others (mostly recruiters) find you.

Dev.to and other online developer communities

There are several developer communities on the web. I found Dev.to as the best one. Other are sharing their experience in their posts. You can comments and also write posts. There’s also opportunity to ask questions from the community. It is one of the best ways to get in touch with developers from all around the world.

Mentoring on exercism

There is a good chance to support less experienced programmers by reviewing their code and give them feedback on exercism. You need to register yourself and apply to be a mentor for a specific programming language. Later on you can review the solution of others. The mentors also have a slack channel where you can set up new connections with other mentors.

Contribute to open source projects

The most classical way of self-marketing as software developer is to contribute open-source projects. There are several interesting open source projects up to your interest. New volunteers are always welcomed to implements new features. Your code will be reviewed and you can get part of the developer community there. It is also a good reference if your are applying for a new job.

Join developer conferences

There are several developer conferences all around the world in different topics. They usually takes 1-3 days long and all the biggest companies are there who are working in the area. There are usually nice presentations and also space for open discussions where you can get new high-value connections. One disadvantage of such conferences is that they are usually a bit expensive.

Join meetups

Similar to conferences you can just join meetups. These are professional events where you can meet with the local developer community. It is also a good opportunity to get familiar with the local developers companies, since most of such meetups takes place at local companies. Meetups are usually after the office hours. The usual program goes about presentations and open discussions. The big advantage is that they are free. So just go to meetup.com, search for relevant groups at your place and join their events.

Write your own blog

Last but not least you can write your own blog. It is also making some chance to extend your professional network.

From individual work to team work

Since the projects are constantly growing and the time pressure is getting higher and higher in the software business to walk alone on a project is not an option in most of the cases anymore. On most of the projects big teams are working from some people up to multi-thousand. But how are these big projects organised? Are the people working in a team or just individually . Are they really work in a team? Is it good if they are really work in a team?

The classical way of working

At most of the projects a projects is splitted between the different subteams based on some well-specified area: components, knowledge area, activity (architecture, testing etc.) or functionality. So each subteam has its clear job with well-specified inputs and outputs and they need to sync up sometimes with each other, but they are basically working independently.

How is the work organised inside a subteam? At all my previous projects the situation was the same: the wok was splitted up to smaller tasks and each task was assigned to a team member. That means each team member had its own task, own responsibility. Everyone was just working on his own tasks. The only interaction happened between the team members at the daily status meetings, at code reviews and if someone asked from help. But normally the team members were not technically deep in what the others are doing. It resulted the following situation: one hand you could working concentrated on your tasks, which was effective as far as you had all the necessary knowledge. If you stuck it took a long time to get help, because the others were also busy with their tasks and they needed time to understand what you are doing. Another difficult situation was when some became sick. Quite often no one else could finish his job without a really huge overhead. So it was always almost causing problems. It was also challenging when someone left the project. Most of the cases he had project-specific knowledge which the others didn’t have, so a knowledge transfer needed to be done. It was always difficult to work with junior colleagues, because they often stucked and lost days with trying to figure out their own solution.

On the other hand it was really comfortable that after getting familiar with the project you were able to work really independently, it was easy to work for example from home office due to the lack of interactions.

To escalate the problems the management was tracking our performance on a personal basis. That means if you wanted to reach a better number next to your name in the performance report you really needed to concentrate on your tasks and avoid wasting time with other issues. It was totally not productive.

The way of real team work

Now I changed to a new company and I’m working on another project. Here the way of working is much different. It is real teamwork here. The tasks are assigned to the team and the to a specific team member. Usually we are working on less task than the number of team members. The is no dedicated person the work on the specific tasks. It is really typical the 2-3 team members are working on the same task by doing pair or mob programming. So we are all sitting in front of one computer and working. It reminds me on my childhood as we were working with computer games with my friends, but we had only one computer. We are also changing tasks between team members frequently. It can be that one day you are working with one guy on one task and on the next day with other guys on another task. This structure is basically solving all the problems I mentioned before: the whole team is aware of the technical content of each topic and there is always multiple people who are deep in a specific topic. So that a sickness, a holiday or a change in the team does not mean a big problem. The junior colleagues can also work together with more experienced team members and they are learning really fast in this way.

On the other hand we often have the feeling that it is not effective at all what we are doing: three of us just sitting in front of one computer and talking about one easy class….hmm.

It is also mentally challenging: instead of listening to music and concentrate on the task, you need the follow and participate discussions all the time, listen to others opinion and formulate yours. This kind of close cooperation is also causing several conflicts between the team members. All things considered it is not so easy to work in such a structure, but I can see also several advantages.

In such a working structure you need to be able to communicate properly, describe your ideas and issues properly and to be very patient and flexible.

I have not the feeling that the best working model would be a hybrid model between strong teamwork and individual work. If you have experience with working in such a working model it would be nice if you could share them.