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.

Experiences with Large Scaled Scrum

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: from junior developer you are becoming senior developer, who overtake more responsibility and more challenging tasks. Later you can decide between becoming a technical expert or becoming a manager. There are also certain steps and levels to improve yourself in these directions. It is pretty clear what are the steps that you can reach and it is also clear, 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 equal, but it 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 topics. 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. 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.

Different aspects of Test Driven Development

Introduction

“Testing before the software is done? What a silliness? It is totally crazy. It goes against the theory of testing. These guys should learn first how to develop software.” I heard these sentences from a software architect who had around 20 years experience in the software  business and I think he was a really good professional, he was just a bit conservative. That time I did not have enough experience to have my own opinion about the topic. Now I already have.

The Test Driven Development is one of the buzzwords in the world of programming which became popular during the last years. Each fancy company is advertising itself by being agile and doing TDD. But what does it exactly mean? Does it really change everything what we learnt about software development?

The theory of TDD

Based on Wikipedia: “Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only.”

Practically that means that is you are developing a peace of code you are creating the code and its unit test parallel. First you are implementing one unit test case, which is testing against the first requirement against your code. Then you are running your test case which will of course fail. Now you are implementing a peace of code which is making your test case green. Then you are implementing your next test case and extending your code in a way to pass the test. If you think that you could change your code to be cleaner just change (refactor) it and check if the tests are still green. Repeat the test until your code is not fulfilling all the requirements.

How I interpret TDD

Let’s see how do we develop by default? We are writing a piece of code. After a while we are trying to run it to check if it’s working. If it is a library or something that is difficult to just run we are often implementing a short demo code which is not doing anything else just invoking our functionality with some predefined parameters and we are using it to check if our code is correct. In other cases we are figuring out a certain scenario in our program which is invoking are functionality and we are doing this scenario every time we want to check if our code is working correctly. If our code is not doing what we are expecting then we are changing it and run it again. Once it is doing what we want we are extending it with several new lines (some new functionality) and checking if it is working. We are repeating these steps until your code is not doing exactly what we want to have.

Are you developing in the same way?

I think most of the developers are doing something very similar.

Is it similar to test driven development?

Yes, there is some similarity.

Which disadvantage do I see at this methodology?

• Run the “test scenario” often takes long
• You are always testing against the same input parameters
• You are always concentrating only on the last functionality you added
• If other developers change your code later, they won’t have any idea what should your code do

Sometimes it is also required to implement unit tests (due to project requirements or whatever). So that you are trying to implement some unit cases to an already existing code. You are implementing them in a way that they will pass for sure. Furthermore if you code is not structured properly it can be really a nightmare to cover it by unit tests.

How does it change in case of TDD?

It is basically nothing else then hard coding your “test scenario”. Instead of manual tests (running your scenario manually and checking yourself the results) you are using automatized unit tests.

So first you are figuring out what should your first piece of code do. You are implementing your first test scenario in a unit test. Then you are coding it and checking your test scenario. If it is not working, then you are fixing your code, otherwise you are extending your test scenario (by adding new test cases) and implementing it.

Sometimes it is also required to implement unit tests (due to project requirements or whatever). So that you are trying to implement some unit cases to an already existing code. You are implementing them in a way that they will pass for sure. Furthermore if you code is not structured properly it can be really a nightmare to cover it by unit tests

The only point is that in the classical way most of the cases first I’m implementing and then I start to think what my code should really do. In case of TDD first I need to define what should the next piece of code do. Here I’m handling it a bit flexible and sometimes I’m just implementing the code first and then adding the new test case. I know, it is against TDD, sorry.

By using this way of development:

• You can tell that you are doing TDD
• You can check if your code is doing what it should by one click in some short seconds
• You don’t need to repeat the same manual test scenario always
• You can easily set different input parameters to the all the corner cases
• You are always running and concentrating on all test scenarios, so you realize for sure if you broke some previously implemented functionality
• If anyone is changing your code in the future, they can check if they did not break the original functionality of your code
• Your code is for sure well-structured to be testable, which is one criteria of the good code quality
• You can anytime refactor your code without taking the risk that you are braking the functionality
• You have unit test with a good code coverage

The only disadvantage I can mention is that implementing good test cases takes time. But running manual scenarios 1000 times also takes time…

There’s no black magic, right? You don’t need to change everything in your current practices.

The relation of TDD and classical test methodologies

In the classical development processes (waterfall, V-model) there are requirements. The software development team is creating a software design from that and they are implementing it. After that a dedicated test teams checks if the software is fulfilling the requirements. It is really important that the developer and the tester should be two different person. So that if one is misunderstanding a requirement the other will realize it.

But the requirements are usually high level functional requirements, so they are not tested by unit tests, but by some higher level tests, like system tests, components tests or integration tests. So the tests done by the test team are on a higher level. The unit tests are usually done by the developer team based on the software design what was also done by the developer team. In 99% of the cases it just means to implement test cases which are passing on the already existing code.

TDD is replacing this kind of unit testing activity. But it doesn’t have anything to do with the higher level testing. I think such tests still makes sense before a software release, so good news: you don’t need to leave your classical testing process, it is not against TDD.

But let’s see further: what happened then at testing phase? The test team finds a bench of bugs, creates bug tickets and send them to the development team. The development team is fixing the bugs and creates a bugfix release. The test team if testing again and realize that some of the behaviour is still not correct, so a new bugfix release is needed. To improve this process the higher level testing can also be done (at least partially) by automated tests. And it is also a nice idea to implement these automated tests before the software development is done and provide them to the software team. So that the software team can run the test cases on its own and in case of failing test cases they can fix the code before releasing it. So that they can save a lot of time both for themselves and for the development team.

The very best that can happen is to run all test cases in the continuous integration system, but it is already a next topic (maybe for next time).

Summary

You can see that test driven development does not differ much from the usual way of development and it also does not hurt the main points of the classical testing approaches. It can take some time and requires practice to implement proper test cases, but it makes really a lot of benefits on long term for your project. So I can just propose to try out TDD, but you should always handle it flexible and don’t expect that it is solving all the problems of the software development.

Let’s understand team structures and development processes

Introduction

As I started for the first time at a big multinational company I just felt myself totally lost. It took long month to figure out who is doing what, what does that roles mean and why are things done as they are done. Later on whenever I changed to a new company I met with totally new team structures and development models. The goal of this post is not to go into details, just to have a first overview, so that if you are starting at your first job you won’t be so lost as I was.

I also need to mention that most of the companies are using some special version or some kind of mixture of the following models.

Last but not least I need to remark that the team structure and a development model is not strongly pending on each other.

The classical development models and team structures

Waterfall and V-model

In the old times there was no real structure of the software development. A small teams of developers just sat down and developed something without a well-defined process. Later on around the 80’s as the bigger companies and bigger software projects came the work needed to become more structured. That’s how the first development processes were born.

At the beginning the waterfall model was the most typical. That means, first the requirements needed to be set up, right at the beginning of the project. Once the all requirements have been clarified a software design has been set up and once the design was done it has been implemented. Later came the step of validation and the software was down.

The next step after Waterfall model was the so-called V-model. The V-model put more effort into validation. The left side of the so-called V is requirements, architecture/design and implementation, just like in case of waterfall. On the right side there are the different levels of testing: unit test and integration testing against the software design and system testing against the requirements.

These were the most common development models for decades. The V-Model is nowaday still used for example in automotive business.

Functional teams

If there are a lot of people working at a company they need to be structurized somehow. The first idea is the split them based on functional area, like: team of requirement engineers, team of software architects, team of software developers, integration team and test team. Or even more detailed, like separate developers into frontend and backend developers. And then each functional team does only tasks which are belonging to their responsibility. So that if a new project is coming all teams will work on that, but only with a small part.

As an advantage there will be a really good knowledge base in each functional area. On the other hand there is no one who has project specific knowledge, who has a good overview of the project. The communication between the different functional teams can be also difficult.

It is also not always effective, since there can be periods when there’s a lot of development task, but still nothing to test. In other periods much more testing is needed than developers. But in case of functional teams there is no real flexibility.

Project teams

An alternative of functional teams is to have project teams. Each project team is responsible for one project. Inside the project team there can be dedicated responsibilities, like: developer, tester, architect etc. But they are concentrating always only on one project. Usually as the project is starting the team is set up only slowly, at the end of the projects the people will be moved into other project teams. A big advantage is that the all developers have a good overview of the project, it can be especially useful if there’s a lot of project specific knowledge. On the other hand the technical area based knowledge is not centralized, so it can get lost easily. It is also often the case that the teams are concentrating only on project goals and no one takes care about building up a team based knowledge based.

Matrix structure

The matrix structure is a mixture of project and functional teams. There are functional teams, lead by teams leaders, but every member of the functional teams are assigned always to a project. The projects are lead by project leaders. The team leaders are responsible to set up the team based knowledge (by trainings, hiring new members etc.) and the project leaders are responsible for the success of the projects. One disadvantage is its inflexibility.

Agile project development

Main idea of agile development

As we have seen the classical way of development is really well-structured and professional, but really often too inflexible: there’s no way to change employees between functional area, it is complicated to change the requirements of the software, it is also reacting too slow on the changes.

So the developers started to search for new development methods which are trying to avoid the above mentioned issues.

There are several different solutions like extreme programming, lean, kanban or scrum, but there are things which are common. Agile development is usually working with cross-functional teams. That means the same team (often the same team member) is able to overtake the communication with the customer, the development and the testing, teams are not separated based on functional areas. Additionally the development is usually done in shorter cycles.

SCRUM, Kanban and LeSS

The most popular agile methodology is called SCRUM. SCRUM works in sprints. One sprint is usually two weeks long. Before the start of a sprint the team (usually has a size of 7 +/- 2) is planning the sprint together with the product owner. They are setting up the tasks (user stories) for the upcoming sprint by shifting them to the sprint backlog. The team is checking the status every day on the daily stand up. And I still did not mention several scrum elements, like refinement, where the team can give positive and negative feedbacks about the previous sprint and set up some actions for further development. Or the refinement where the team tries to understand the user stories better and also estimates their size. There are several good books about scrum, if your company is using scrum you should read one of such books.

The big advantage of scrum is that if the requirements are changing it can be considered in the upcoming sprint, so it can be changed within several weeks.

There’s an other agile methodology called Kanban. In this case the work is executed based on a so called Kanban board. The Kanban board has three columns: To do, In progress and Done. If a new task is coming to the team it will be added to the To do column. Once someone is starting to work on that it will be moved to the In progressed column. Once it’s done it will be moved to the done column. To focus more on the tasks the number of tasks in To do column can be limited. The Kanban table is popular, that it is used at other agile methodologies as well.

I also need to mention LeSS, which stands for Large Scaled Scrum, which is basically an adaptation of Scrum for big projects.

Cross-functional teams

In agile development environment cross functional teams are typical. That means there are no dedicated role for testers, frontend/backend developers, architects etc., but each team member can take over any kind of tasks. That means it can be that in one sprint you are implementing tests and in the upcoming sprint you are working with backend development. In the cross functional teams a closer cooperation by doing pair or mob programming (programming in team) is also typical. This way of working makes your team much more flexible, because it can use its full capacity for any kind of tasks.

Summary

As I already mentioned this topic is really complex, I could write a series of books about this topic, but currently I tried to give really just an overview and make it possible to understand the difference between traditional and agile development.