Part 1

Introduction

Trends and development processes come and go and software developer need to adapt themselves to the new trend and the new development processes.

Six months ago I started to work in a Large Scaled Scrum team. During these six months I learned a lot and I think this is the time to analyze a bit what I learned, what are the advantages and disadvantages of this working model and to collect some hints for developers who start to work in such a process.

I already wrote a post about this topic in some months ago. Click here to reach it. That time I had only some very first experiences with LeSS, in the meanwhile I experienced more and I have a much better overview. Some of my feelings changed, some of them are still the same. Since I collected a lot of points this post will be published in two parts.

Change your mindset - Don’t compare it anymore

As I started to learn about this work process I was always comparing it with the ways how I used to work before, but mainly with the V-model. I was not the only one, even other people, who started to work in this process did the some, I think this is the normal way how human beings work: compare new things always with the known ones. But this time it was a huge mistake.

Simple it is not possible to compare agile with non-agile work models, because it is so much different.

It is a bit like neural networks: you will never prove that your neural network is working properly, you can not compare it to classical algorithms in terms of how it calculates the result, but still you can experience that it is a good solution for a lot of problems. But there are still situations where classical algorithms are better than neural networks. In my view it is a bit similar to the case of agile and classical development.

If you are in a situation that it is the first time for you to work in a real agile environment, please don’t compare it to your previous workplaces, just try it out, try to follow and evaluate your experiences.

I still need to have one remark: most of the places which are calling themselves agile are not agile at all in reality, I’m not talking about these places now.

Shared code - shared knowledge

One main principle of this development model is that everything is shared: the code, the knowledge and responsibility. This can be ensured by following methodologies like pair and mob programming and it is also important to rotate the tasks and topics within the team. Even the technical decisions should be taken on a team and on an individual level.

Being part but don’t own

The normal human behaviour is people like to own things: they like to have their own car, just to be able to show that they have a car and this car is the most valuable if no one else has such a car.. This is the same with the knowledge and success. Developers like to be unique in a way: “I am the only one who knows how this code works”, I implemented this whole functionality, “it all was done by me”, “I decided to do it in this way” etc. This is a very common mindset. And it is a mindset which will never work with LeSS.

In LeSS you are not owning any line of code, each line of code is a result of a team work. One they you are writing it. On the next day someone else is changing it. The knowledge is also shared, to be the only one who knows something is totally again the agile theory. If you know something share this knowledge with your team as soon as possible.

What you need to realize that you are part of a team and your team is part of a big structure. And this big structure has common goals, simple to achieve something. And if it can achieve it that is a success for each and every team member, even for you. And it can be achieved if the people have a good knowledge. To achieve this success, which is even your success, support your colleagues to extend their knowledge and to resolve their issues.

You are part of something big, part of decisions, part of code changes, but you are never owning it exclusively. This is the first part of mindset which should be understood.

Life without domain experts

One interesting thing that in this structure there are no real domain experts: there’s no expert of a specific component, no software architect etc. One hand this makes the whole process flexible: you don’t have to wait for the one dedicated person etcon the other hand it can make some situations also difficult. If you have an issue regarding a specific component there’s no component expert who could easily answer your questions. There are also strange situations in case of architectural decisions. Instead of dedicated software architects, there’s a software architecture community. The members of this community are developers from different teams. This community is dedicated to making all software architectural decisions. But making decisions takes really long for this community, because of the pro and cons, they can simply discuss some questions weeks or months long. So sometimes I see a need for some better coordinated way of decision making.

From developer perspective it makes a great chance to collect knowledge about a lot of different fields (different components, software testing, architecture etc.).

When the code is burning

It is also interesting to see what is happening if something is broken in the code.

In this case there’s a lot of advantage of the shared responsibility. The question is not “who caused the bug?”, the question is “how to solve it?”. Since every team is able to change any part of the code base, it is much faster to fix bugs, since you can just fix it, even if it is not in the component you worked on before. Based on my experience resolving bugs is much faster in an agile environment as in a classical environment.

Quality assurance in such an environment

Good software quality is of course really important even in an agile environment. The way to reach it is a bit different than in a classical environment. In such an environment roles like software tester, software developer and system engineer are not separated. Usually any team can overtake any of such tasks. Practically a lot of things can be automatized. Such projects are usually following the TDD (Test Driven Development) process, where automated tests and software are implemented in parallel. It makes it possible to have a much more flexible and faster delivery loop. Next to it continuous integration is also used where all tests and software quality checkers (static code analysis, code coverage analysis etc.) are running automated after every code change. So that the developers are getting a pretty fast feedback regarding their work.

As for me it was a bit strange to start to work with this principle after working years based on V-model, since it is contradicting with several rules of classical software development (test cases are created based on requirements, testing should be done by different people as development etc.). But after several months I see that this way of development can also assure good software quality. But to be able to reach it the whole project needs to be really string on coding guidelines, test coverage and quality of testing.

On the other hand it is also giving a much faster feedback. Since in V-Model most bugs have been found after the software release in the testing phase (usually weeks after the implementation), here most of the bugs are found immediately or very soon.

Are the teams really cross-functional?

The expression “cross-functional” team is a bit miss-leading. Of course it is not possible that every team and every developer has the same level of knowledge in every field (design, implementation, testing etc.) and in every domain (every component etc.). But this is also not the goal. The goal is that the teams can do end-to-end development from clarifying the requirement with the area product owner until delivering a tested software. But of course there are always team members who are strength in communication, until other are better at testing or at software design. So in the different phases they can give a better support to their team members. But it is important that every team member should have an idea about every step. So it is not possible that someone is never doing tests or never takes part in requirement clarification.

Even on the level of teams not every team has equal knowledge. Most of the teams have their own area where they have a better knowledge (like good knowledge about a part of the code etc.).

I’m not sure if based on theory it really should be like that, but that’s my own experience and I also think that it is good like this. It gives everyone the possibility to learn a lot, but there’s still some place for expertise of specific topics.

Life without management

In classical development management has a really central role. They are planning the whole project, they are communicating to the customer, they are tracking the project etc. It makes it possible to keep the project to some strict plans, but it also makes the life of the developers difficult. It is also leads to conflicts between developers and managers. The other problematic part is that the managers and the developers are not on the same technical level which can lead to misunderstandings during planning and tracking.

In an agile environment it is working in a different way, which has several advantages, but I can also see some disadvantages.

Flexible planning

In an agile environment we are usually having a much more flexible planning methodology. We can usually plan only for shorter periods and functionality can be reduced to achieve the right quality.

In case of large scale scrum we are working in sprints just like in the case of the traditional scrum. But there are also long term project goals. It is the responsibility of the area product owners and the product owner to keep the development in the right direction to achieve the long term goals. So all tasks to be done are going into the backlog and the team are free to decide that we items they are taking from the backlog. The team can also decide about the amount of the items. It is really good for the teams, since they can decide about the amount of work they are taking for the next sprint, which is usually taking two weeks long. So they can avoid the long over hours, which are needed to achieve the predefined milestones. They can work in their own tempo.

On the other hand with this structure it is much easier to bring through quick requirement changes on the whole software. So I think this part is good for everyone.

Everyone is a manager

On the other hand it also means that the team needs to take over some activities which are done by managers in classical development models. Like the team needs to decide about their work items and the amount of work they are overtaking for a sprint. The team needs to organize this work within the team and track it. The team is responsible to implement the tasks for the right time with the right quality and also communicate about experiments.

So at the end of the day there are no managers, but still everyone is a manager.

Personal development

Let’s talk about the dark side.

At the classical companies there are typical, predefined career paths: like from junior developer you are becoming one a senior developer, who overtake more responsibility and more challenging tasks. Later on you can decide between becoming a technical expert or becoming a manager. And there are also certain steps and level to improve yourself in these directions. So it is more or less clear what are the steps that you can reach and it is also clear, that what you should do to achieve these steps.

In case of less process it is a bit different. Since as part of the team everybody is working on the same tasks, there is no real difference between the tasks or responsibility of a totally fresh junior and a well-experienced senior. Everyone is kind of equal, but is also means that as a developer there is no next step to be reached. During your daily work you can learn a lot about different technical knowledge. But there is no predefined direction for developing yourself and you can also not really track your personal development, since there are no certain levels what you can reach. And it can make a lot of developers demotivated. You can simply take the question to you: “Why to improve myself, if I still work on the same tasks and I will still have the same responsibilities?”.

Furthermore in case of classical working mode your manager is usually also helping you to find the right direction for you. In this structure you are totally alone to figure it out.

And it is fine on short term, but a lot of developers are losing their motivation on long term.

This is one of the biggest disadvantages what I found about LeSS.

Bye Bye stress

At the end of the day since the team can decide about the amount of work it makes this working model pretty stressless for the developers: no fight with the managers, no over hours, noone it pushing you to implement features ASAP, etc. So you are really getting rid of the classical stress.

On the other hand you can interact a lot with other developers (mainly your teammates) and it can also be stressful in several situations.

Summary

I really have a lot of topics to talk about my experiences with large scale scrum. I hope they are useful. The follow-up article is coming soon, where I will concentrate more on the part: how to behave successfully in such an environment.