 Okay, last up, two things that we need to discuss. First of all, agile development is often mentioned as a great thing, the new invention and a lot of it, a lot of companies swear by it. So I think we need to do some sort of reality check and discuss what are potential issues with doing agile development. And then we move into what is actually being used in industry, in the software IT industry. So first off, agile development brought a lot of improvements because a lot of things went wrong in the 2000s or end of the 90s. So if I mention a couple of things that are negative or that you need to be aware of, it's not to say that agile development is anyhow bad, but you should consider them in certain contexts. First off, there is the notion of agile teams. So we have, for example, for Scrum we discussed that the teams are self-organized, there is no manager that assigns tasks, they collectively own everything, and that sounds really great. It gives you a lot of freedom. And of course it's very exciting to work in a team like that where you don't just have the manager that tells you what to do. The issue is, if you look into organizational psychology, for example, this is something that requires a team that is very, very mature. So a team that is mature works in a way that it can be self-organizing, it doesn't need to have this management that tells them what to do, but that's not true for every team that you can imagine. And that means if you want to do agile and you want to have teams that are actually self-organized, you need to be aware of that you might not get there right from the start. So you can't just put a bunch of people together and expect them to work in a self-organized way, but you need to expect that there will be conflicts and you need to manage them, you need to put effort in that they will actually reach this maturity, that they will become a self-organized team. So that's something that is not really mentioned much in the agile literature. It sounds like you just follow these practices and everything is great, but in fact that can be a big problem. And of course if you look at sort of the top companies that every graduate or every developer wants to work at, they very often have extremely good people and they might also have people coaching the teams. So if they work very well in an agile way, it does not necessarily mean that that's the case for every single company. So be aware that getting to the stage that your team can be agile is quite some effort. Next up we have the topic of architecture. So this is something that we will discuss later on in the course. I believe it's module 5. So structuring your software system into smaller components that are reasonably independent and achieving certain qualities like a certain performance or certain security. In agile development there is no talk about doing architecture. So you just focus on the functionality, you focus on the user stories, which is great to get new features out quickly, but it comes at the risk at the expense of neglecting the architecture. So there is a chance that you have a so-called architecture creep and things work great at the beginning but over time they slowly get worse. You for example get a slower and slower system and this might at some point in time hit you and require a lot of rework and in some cases rewriting an entire application because it's just not maintainable anymore. So there is a big risk in neglecting the architecture and that has been recognized in some newer agile methods for example include things like sprints that are dedicated only for architecture development, not for any user stories. But this is something to be aware of just by focusing on the functionality only and not doing any planning ahead you might run into issues with the architecture. There is a similar risk with the documentation. So we are valuing a running system over a comprehensive documentation. The problem is if we don't do any documentation we might similar to the architecture case get to a point where we simply don't understand anymore what the system is currently doing because we're constantly changing something and if the system is reasonably large, reasonably complex it can get really difficult to understand where we are right now. So especially systems that have a long lifetime might suffer from this and might require more than the usual agile development. And the user stories are not always enough to document this so sometimes companies like to say they keep the user stories or they have their test cases and that's enough to understand what the system is doing but these are usually single scenarios and if you want to get the big picture what the system does overall you might need additional documentation. This is especially a point in companies that try to adopt agile development on a large scale with multiple teams with up to hundreds of developers then you really need documentation. So that's something even if you don't like to do it you need to look into what is required there. On the topic of documentation and requirements we have the user stories. User stories are a great innovation in the sense that they include the stakeholders and the rationale. So those are things we typically are missing in requirements and that can make it really hard to understand requirements later on. For example you have a statement that says the system shall offer a certain functionality and after two years you don't understand why and maybe you just remove it and you realize too late that it was really important. By having the user stories you have this rationale and you should directly understand yes that's the value we're having that's why we need it. The problem is again more common in large systems sometimes you cannot anymore express requirements in a user story format that are kind of small enough that you can do them in one sprint. Imagine you're developing software for a car implementing anything that has a user value might require multiple teams and definitely more than four weeks so it gets increasingly hard to use this user story format for sprint planning. So that can be tricky and a lot of the work that the teams might be doing might not have direct customer value, direct user value but it's still very important. So again this works mainly for smaller systems, for smaller teams but it might not work for a larger scale. And then finally we have something that we call the agile islands or sometimes the agile islands in the waterfall. If you are working with other companies, if you are a team within a bigger company you often have process issues in the sense that not everyone uses the same process. So for instance you might be doing scrum and it's great but your customer works in a very traditional way maybe according to a waterfall model even. And then the problem you have is that you have this clash at the border that for example the customer is not ready to give you feedback every four weeks or every two weeks even because that's not the way they work. They expect that at the beginning you want to do planning and at the end they come in and check what you have done but in between there is very little communication. So then you can be as agile as you want it might still be problematic because you don't get the feedback quick enough. So it can be very hard to be agile if the context around you is not. And a similar case are again larger companies maybe on the project management level they really like their old stage gate model they like the milestones and then they somehow try to fit you into that. Can you tell us which milestones you have in half a year? So this can be a really tricky thing that a lot of bigger companies are struggling with that they would like to be agile but they can't really because the rest of the organization is not. Okay so these are things that you need to be aware of. They can be solved so it's not like they break agile but it's something you need to take into consideration when you decide what process to use. So what processes are used in industry? The answer is as very often in software engineering it depends. So scrum is definitely as I've already mentioned an extremely popular process because you can tailor it so well you can put things in. There is also something that is called scrum of scrums which we don't really cover in this course but that's the idea of combining multiple scrum teams together so you can do development in larger teams. So scrum has been very influential but I would also say because it's so flexible a lot of companies that say they do scrum have gotten really really far away from the agile values so their development might look much more like a traditional waterfall development even though they call it scrum. But talking about the traditional models the V model and all sorts of plan-driven models are still really really common. So this is still there it's not like everyone does scrum especially if you have large organizations as I've discussed here or if you have systems engineering or heavily regulated areas so things that move slow basically. Again the car example if you build a car you have certain safety standards you have certain security that you need you depend on mechatronic components so maybe you need to wait for the brake system to be ready you can't test the car because it's not ready yet so even if you have the software how do you test it in a proper way and in a lot of these cases you actually fall back to the traditional V model or any kind of plan-driven process. So these are very very popular still especially in large regulated areas. Now this depends a lot on the domain it depends on the size it depends on the country and since I'm having these lectures in Iceland it's important to mention that Iceland has a lot of small companies and it has a lot of companies in the web development area so small products, web products and that's why in Iceland you are seeing a lot a lot of scrum and other agile methods being used but if you go to a global scale you will see much more of these if you go to the big European or US companies then you will see a whole lot of the more traditional development so judging from a single country you need to be a bit careful what is used somewhere else you very quickly run into this idea that everyone is just using this and the rest is not anymore in place so it's really a mix and the landscape is changing constantly so nowadays you hear a lot of things like DevOps there is Kanban or Lean and there are a lot of other things they are all somehow related we might cover some of them later in the course but nevertheless the core ideas are still we have plan driven or incremental development and then we have the agile world that is focused very much on customer value minimizing documentation and planning iteratively okay so this concludes the module on processes just a big overview and next up in module 3 we will look at modelling of software