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.

Experiences with Large Scaled Scrum - Part 2

Introduction

In my previous post I already went through several points regarding my experiences with LargE Scaled Scrum. In this post I would like to extend that with some additional topics, like how do self-organized teams work, when to use LeSS and how to be a perfect developer in a LeSS structure.

Self-organized teams

In the LeSS process developers are working in self-organized teams. One team consists around 7-8 developers. Each team is supported by a scrum master. Based on my experience working as a team is at least as important here as being self-organized. I used to work at several places, but I have never experienced such a close teamwork yet.

Becoming a team from individuals

Earlier wherever I worked teamwork meant that we were several developers working different tasks which are connecting to each other in a way. So everyone did their own tasks and sometimes we synced up about our status and if someone got stuck we helped each other.

But in fact it is not a team work, just a synchronization between individuals who are working on their own tasks.

In case of LeSS it is slightly different. First of all, the team can decide which items they are taking for the upcoming sprint, they can decide what is the amount of work they can overtake. Usually the amount of items is less than the size of the team, so that multiple people are working on the same item. In extreme cases the whole team is working on one item.

The tasks are not assigned to one individual, everyone is working on them and the related responsibility is also shared within the team members. So there’s no “my task” and “your task” only “our task.

How is it done in practice?

One radical way of doing it is mob-programming. So that the whole team (or at least several members of the team) is sitting in front of one big display and they are solving the tasks together. Someone is handling the keyboard and the mouse (leading the mob-session), the others are telling them what to do. After a certain time the leader of the mob-session should be changed.

To be really honest in practice we are rarely using this method.

In our case we rather prefer pair programming, or individuals who are taking really small pieces of the big task.

If the team is doing well that has the following consequences: everyone is aware about the whole code base and all technical decisions, everyone can overtake the tasks from another without long ramp up time (it is really useful in case of a sickness), everyone can do technical discussion about any item being done in the team (because the needed background knowledge is given).

Of course it sounds too idealistic and we also can not always reach this state, but we keep on tending in this direction. Regular technical knowledge transfer sections are also required.

Unofficial roles within the team

Within the team officially everyone is equal. There are no leaders, no dedicated persons for different kind of tasks (software design, testing etc.), everyone is free to take part in any meeting (LeSS ceremonies, discussions with the customer, etc.).

However with time some unofficial roles are being set up within the team, even if noone is talking about that clearly. The team will realize with time who has the best knowledge in a dedicated field, who is the best candidate for fast bug fixes, who is the best in conceptual work, who is the best at communication with the customer, who can motivate the team members, who can help to resolve personal conflicts etc. And with time these people will be preferred to overtake specific tasks.

I think this is pretty fine, just the team should make sure that other team members also get a chance to take part in such activities to be able to improve themselves in that direction. The best is such activities are overtaken by the “expert” and some less experienced team members, so that their knowledge level will get closer to each other.

All-days reality show

Most likely until know you realized that this way of working requires a lot of interacts between the team members. Most software developers prefer to sit alone, listen to their favourite music and deep into their work while avoiding any communication with the others.

In case of the working model it can not work like this. Since the tasks and responsibilities are shared you have to communicate frequently with the others. In can of pair of mob programming sessions you are basically communicating all day long.

Most of the software developers are not really prepared for so many interpersonal contact. I was also not really prepared, I did not expect it. But fortunately most of the developers can adapt themselves, even if it is not so easy. It requires a big improvement of several soft skills (communication, time management, conflict handling etc.).

If you are working so close with the others you will know their personality very well after a short period. You will know both their strengths and weaknesses. And most of the people have some weakness which is difficult to tolerate: being self-fish, self-driven, not accepting different opinions, aggressive communication etc. Facing with the characteristics often leads to conflicts within the team, especially during the first period.

So very often I feel myself like watching the Big Brother reality show. But this time I’m also part of that. It is not easy to resolve all the conflicts and keep a balance inside the team.

I’m pretty sure that it would be a good research topic for a psychology student.

To resolve these issues good retrospective meetings are needed with a very open manner.

Life without home office

To work in such a close cooperation is only possible if the whole team is placed in the same office. Of course there are a lot of modern tools available, but pair or mob-programming sessions can not be really done in an efficient way if the participants are not sitting next to each other.

It also means the doing home office regularly is not really possible with this working model. I encounter it also as a big disadvantage, since home office opportunity is a really common and comfortable benefit if someone is working as a programmer.

Different knowledge level within the team

It is also challenging that the different team members have different experience and level of knowledge. It differs topic by topic and also overall. In the way of work the junior developer with only a few months of experience and the senior developer with decades of experience is working together on the same tasks. And it can be challenging for all participants. The team should always pay attention on the members with lower knowledge level to give them the base knowledge which is needed to understand the current tasks and the less experienced ones needs to make a lot of effort to extend their knowledge.

Regular knowledge session meeting are helping a lot on this issue.

And if you are working in such a team and you don’t clearly understand your task: don’t be shy to ask the others, don’t stay without a clear background knowledge. You have to learn always something new. One hand you can just read after the topics, on the other hand you can turn to your teammates.

How to be a perfect member of an agile software team?

As I joined the team there were a lot of things which were pretty strange for me, it is really different than anything I worked with earlier. It took me some time to figure out how to be a useful member of such a team. I collected some suggestions you should do if you find yourself in a LeSS team:

1. Find some tasks for yourself always in a proactive way

In a LeSS team you don’t have dedicated tasks assigned to you. So if you have nothing to do noone will go directly to you to give some tasks. Be proactive, always ask your teammates whom you can join or support. It also helps a lot if you are aware of the status of the others.

2. Always share you task and knowledge with the others

If you know something that others don’t know: just tell them. And always let the others know what you are doing and how you are doing it. Ask them for their suggestions accept their ideas. It is even better if you are not the only one working on the task.

3. Always give a clear feedback about the status of your work
   On the daily stand up meeting always tell your real status. Don’t tell that you are almost done if it is not true and don’t tell that you know everything if it is not true. It would just mislead your team and make it unable to close the items until the end of the sprint.
4. Always try to understand all topics which are being in progress in the team
   It can be that you are not strongly involved into all items, but you should have at least an overview: pay attention to daily stand ups, check the commits of the others in the version control system and ask if something is not clear.
5. Always try to understand your team mates
   If your teammates have an idea or solution which is not clear to you you should always take the time to understand it. You will never be able to discuss technical topics if you are not on the same page.
6. Let’s accept the ideas of other if you not strongly disagree.
   It is really typical that different teammates have different solutions for the same problem. But it is not good if you are sticking to your idea. Always accept the idea of others if you don’t see any big issue with that.
7. Be chilled and patient

Don’t be stressed. That just makes the life of your and the team more difficult. Always be patient with your teammates.

Agile and future

Is it really the future?

I heard many times that classical development frameworks (Waterfall, V-Model etc.) are the past and agile is the future. First of all we have to see that most of the companies and teams calling themselves agile are not agile at all. They are just renaming the roles and the meeting of the classical processes.

The world of programming is becoming faster and more flexible. Requirement changes becoming more frequent and due dates becoming shorter. Agile methods provides good solutions for these problems. From this purpose they are pretty clear the future.

But there is still the other side: one popular point against agile frameworks if that quality management is much more difficult in such frameworks. It is exactly because of the frequent change of requirements. But we have to see that software are becoming more and more safety critical: they are driving cars and aeroplanes, they are responsible for transferring of dollar billions etc. I see it as a big challenge to reach the quality which is required by such functionalities in an agile framework.

The other point that the scale of programming languages, methods and frameworks is getter wider and wider. It is really challenging to keep yourself up to date as a programmer with all the changes in such an environment. That means it is really challenging to be a generalist software developer, specialization into a certain direction is becoming more and more necessary to be able to keep up to date with the changes. But the whole SCRUM and other agile frameworks are based on developers with general knowledge and not on specialists.

So in my view there’s a place for agile, but there is still need for classical software development methods.  

Summary

After 6 months of working in a LeSS team I really have a lot of topics to write about. That is good, it means that I learned a lot during this period. I found new ways of working and I collected more experience in cooperating with others.

I think every developer should try out this way of working and it could help for a lot of projects, but it is not the best for everyone and not for every project.

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.