 About 40 slides in 45 minutes, so we're going to work fast, so hope you follow me. This is an advanced talk, and I'm going to try to cover quite a lot. If you have any questions you would like to ask, you can do it on the Twitter tag there, or you can send an email. My email will come at the end, and I try to answer, because we may not have time to answer a lot of things during this seminar. Why does this talk come up under outsourcing? The philosophical challenges between Agile and ISO or CMM may be more pronounced when we're working in India here, where we have companies who are certified locally here, and we're working with customers abroad, and we may have additional challenges due to that. But otherwise, the problems are generic. Very quickly about me, I came to India 20 years back. I worked 34 years, I think, with IT. I started when I was in higher secondary, and I've been in it ever since. I'm Swedish, and I've lived here for 20 years. I can't speak much. My children laugh at me when I try to speak Tamil, because I live in Chennai, but my children speak fluent Tamil, and my wife understands much better than me. I don't know what I should say. I work with ISO certified companies, my own company mainly, some of my Indian staff are also shareholders. I have no personal direct experience of CMM, even though I would say a few things about it. We've outsourced the companies who are CMM companies. I have extensive experience of ISO, extensive experience of SCRUM and XP, and I worked a lot with requirements before that. We work with development in integration services, typical in Bistock, and with various green field development, mostly in .NET and mobile. Here are some of our customers. You will recognize some of the names. We focus mostly on the Scandinavian market, but also a little bit on the UK market, but I'm sure you've seen some of these names. We're working with most of these companies today. I will cover something about philosophy, and I'm sorry about if that would be too theoretical. I try to do it very quick and try to cover it. Then there's a question if there is a clash or not, and we look into a little bit about the agile manifesto versus ISO or CMM. I've done some research on this. I wrote my master thesis in informatics a few years back, and I looked into the specific problems, quality system as such, but also specifically to agile. We look at what's easy to mitigate and what's hard to mitigate. First a bit on agile. You've already history of agile. Agile has some roots, or sometimes you could say these roots are created because I think people put things together a little bit afterwards, and things have come together. There are some roots in particular which I think are very interesting. This is one within social constructionism and the one with complex adaptive systems and lean manufacturing. I think those three in particular are of interest. I'm going to look a bit about social constructionism in particular. Constructivism, they are used synonymously. When you look at ISO or CMM, both of them have their roots in the defense industry. ISO is much older in a sense. It was rooted in the British standard during the Second World War and it was about creating bombs with good qualities. They didn't explode in the factories. That was redeveloped and with little finishing where you talked about customer satisfaction in other ways, it's basically the same root. I think in the last standard they even added that we should reduce waste, but it's rarely getting a lot of prominence. I think the main difference when I look at ISO ticket, which we are working with in our company, is getting very similar to CMM. We're getting TIC-IT+, which is adding maturity levels and I think they are more or less merging into a similar pattern. The big difference is about how you certify ISO, you certify basically any product in the company. I think in CMM what I understand is that you look at specific products only and uprace those projects. When we outsourced to one company, they said, well, this product will go through uprace and they knew that in advance. We never know in advance which product the auditor want to look into and we also have a lot of internal auditing so we continuously audit all products internally. Is there a clash? Before that I would like to say, does anyone know what a paradigm is? Anyone studied Thomas Kuhn? A paradigm is a whole world view. It's how you see the world. When it comes to scientific methods, you have an ontology which means what can you know? What is knowledge? Is a company something real or is it something we perceive? That's what is knowledge. Epistemology is how can we know something in the first place at all? Can we know something and how can we know? Then you have methodology and you have methods. Agile is a paradigm but it's very closely related to some other scientific paradigms. I'm sure you heard about positivism and I'm taking Newton here because he's one of the main person we think of when we think of positivism. You see the rainbow down there? He used first one prism, he took sunlight, took a prism and then he used a very narrow, I don't know what it's called in English, and you took another prism and then he could show that the angle was the same as the one for the color. At the time people believed that the colors, the rainbow, was due to impurities in the prism. They thought white was pure and was undividable. Newton proved it was not and he did it in a very, very proper way. Now positivism basically believes that we can fully understand the world, we can construct formulas which would describe everything. It seemed very good for a number of centuries and we used the method, you probably heard it, you put a hypothesis, you do some prediction and you test it and you use induction to get a formula which you can reuse. If I drop a stone on my foot, it's probably going to hurt my foot every single time. But maybe it's not so simple. When U.S. sent up the first Apollo things to the moon and everything worked very well and then with Apollo 13 they had a problem, it didn't work just because it worked a number of times, it didn't work the next time. Carl Popper is a famous philosopher during the last century who spoke about that scientific induction doesn't work just because something has happened one million times doesn't mean it's going to happen the next time. Just look at the stock market, you can't predict the stock market. But today most scientists admit that you can't really predict anything especially when you talk about quantum physics, you can't totally predict. There is a randomness to it or you can't know for sure. Waterfall is very much founded on positivism. Even though Royce, the American who wrote the first paper which is normally considered, he's considered the father of the waterfall model actually he wrote and said that in his paper he said it's a flawed model and he suggested feedback loops to avoid this. So he started with this one but then he suggested something else but people only remember this model so well he wasn't as bad as people maybe thought. Now quality systems are based on positivist view of requirement, positive view of quality. They are rooted in the defense industry. They are focused on mass production and repeatable processes. They focus on quantitative measures of quality. You measure. How many have seen the matrix? Yes. The matrix things were not so easy because you perceived Neo when you started to perceive reality as if it was real and then you realized that well, which pill do you want? If you take the red pill, no you take the blue pill, you just wake up next morning and you don't realize anything. If you take the red one you wake up and realize reality isn't as what you thought it was. Now this idea goes much further back to Plato which showed that what we see of reality is really shadows in a cave and you have light in between and you're sitting with the back towards the wall and you just see the shadows. You don't see the true reality. Now this thought also exists in most religions actually. I knew it existed in Hinduism before coming to India but some Hindu friends of mine told me it exists in Judeo-Christian religions as well. Anyone has read in the Bible it says vanity-vanity and that's exactly the same thing. It means that we cannot fully understand the physical reality. We are dependent on our senses to understand it and we can't understand the true nature. Now the agile manifesto, what does it have to do with this? Well, it has a lot to do with that actually. An agile as a whole. And what it says it's focusing on the individual's interaction, working software, customer collaboration, responding to change. It's not absolute. Now it's well-rooted in traditional engineering, software engineering practices and we use the same methods to a fairly large extent but philosophy is completely different. Quality systems on the other hand, they stress exactly the things which agile manifesto says are not so important. So the agile perspective is based on a subjective word view and I will explain a little more soon. Especially requirements which may be seen as socially constructed. That's what we say, we don't truly know. The customer doesn't know fully, we don't fully know, we don't know if we understand the customer correctly. We use user stories, context, other things which are because we recognize we can't fully understand it. It's not possible to explicitly describe requirements as was earlier perceived. There's a lot of other things also and if you have too much documentation, that documentation is explicit. The belief that you can put everything in document is based on positivism. Now, documents are not bad. So don't get me that way. It's just that it's not possible to capture everything in document and it's easily becoming something for its own sake. Self-management and self-organize comes basically from complexity theory. I'm not going to cover that so much but it's also based on a holistic paradigm which is different from the positivist paradigm. I think you know the rest. There is a slight risk which I said earlier. We base our agile methodology on traditional methods itself into a large extent. Some are new but a lot are old and a lot of them are rooted in a positivist practice. So inside the sprint or the iteration we may actually use a fairly rigid positivist approach to some extent but the bigger picture is different. It's like you are putting your boat in the water, you are pushing it out, you start to roll without knowing the direction and then you adjust the course after time or like the missile as we heard this morning. That's a different paradigm of how to find reality. Now it's a danger if you believe that it is positivist. I claim that. Total quality management is rooted in scientific management and Taylorism adding statistics and this is the father of all quality system basically to a smaller larger extent. So it's not really rooted in total quality management it's influenced it. There is research, there is a pricing little and it shows that maybe the effectiveness is not given. A lot of the studies which have been done actually don't show it, both those who believe and the researchers who believe in TQM and those who don't actually often in their theoretical assumptions they over assume the effectiveness of the quality system itself to deliver. And actually proponents and critics alike avoid studies. There's very little, surprisingly little research. I spent a lot of time trying to find proper research about the effectiveness. Most of it is very narrow minded look and it's very hard to get a total picture of it. That's true about agile to some extent also. Most studies about agile is done in the university settings with not proper when they're trying to quantify it. So it is a little hard to know how effective it is. Reductionism, rationality, positivism are once again the basis of this. Now there's a lot of questions. There's a lot of literature which philosophically question TQM, especially from critical theory and the things which are questioned is that there is resistance from staff. There's inconsistency. There's internal politics which stops it. A lot of groups are not covered. It's mostly the management's view and customer's view which are taken. I think I covered that. Also it's hard to make research also because if you ask people who use it most of the people make their livelihood from it. So if I would ask anyone can I make a critical study if your quality system is valid? What do you think most quality managers, most auditors, I hope there's no auditor who take offense what I'm saying. But it's hard to go in on a study which may show some ineffectiveness of your method. Now when I interviewed our ISO auditor I had to tell that he first didn't want to participate and then I said my interest is to try to get the quality system to work. I'm not trying to find it's bad. I may find some things on the way which is not working but I'm not interested to find faults as such. I'm interested to find how do it work. Then he was happy to collaborate in the study. Now I don't know about CMM but in ISO there's a lot of talk about non-conformities and non-conformity is combined with a fairly hierarchical view of how to do it. It can be dangerous. It can be very high-handed. Internal auditors, external auditors can be very high-handed. And in addition to that I remember I visited a customer in Norway and their quality manager said well no company appoint their best people to become quality managers. That's not saying quality managers are bad but we don't necessarily put our best people into doing internal audits. We probably put our best people to deliver to customers and that's natural but there's a risk with that that there would be conflicts for that. That's not a problem in the system itself it's more a problem how we manage it. Now there's a problem also with incentives. Often incentives are linked to metrics and that may also control things. There are more focus on filling in forms than satisfying customer needs. There's also politics as one which is coming up in a lot of papers is that the quality manager is stressing the internal metrics, the internal things. The product manager is stressing delivering to the customer to the extent of compromising on process. There is a built-in conflict here which may be something we have to live with so I'm not saying necessarily it's wrong but I'm saying there is a conflict there. An auditor is definitely not a proxy for quality control. It's easy to think just because you have it. You have ISO, you have auditors and all of that that you get quality because of that. There is nothing like that. There's also a lot of subjectivity built into it. On the surface it's positivist but in reality there is a lot of human thoughts and emotions and views built into it. Inexperience, when I did a study in my company I read through all non-conformities through the years and I found that a lot of NCs were based on non-understanding by the auditor of the project. Something like 20-30% of the non-conformities were based on that. Also just because you have process it doesn't mean that they are good. Just because you're certified doesn't mean you have good processes. I don't know if you've seen this one. I thought it was fun. Now ISO and quality system typically understand requirements as non-ambiguous description of a system developed and it's done in the beginning of the project. If you have an RFP I'm sure you have to satisfy these requirements and they are not given. An agile view is that they are socially constructed and depends on the perspective. Different people would have different views of the system to be created. There's a lot of needs. There's political needs. There are emotional needs. There are views which we have because of misunderstandings. A lot of these things comes in and we construct our view of it. I think we understand what we want to do but we don't. You know this but it is a problem. It's a problem if we perceive it as proper and explicit. I don't know if you've seen this one. This one was in a textbook when I studied IT in Sweden. In the 80s actually I found the Swedish one and I translated it into English that customers said they wanted something. The project leader, different people interpreted it. Sale described the system in a very luxurious way as you see in documentation. Everyone forgot about that. They installed a version which was not complete and they invoiced a lot and there was no support and the customer wanted something else. This of course is extreme but it's telling something about that there are different views of things. There are different views. We see things differently. There are different views of control. Quality systems look at process to control, management to control. Corrective action is mostly from outside and agile looks at self-managed teams which is a completely different philosophy. This different definition of what is quality. In ISO it means if you satisfy the requirements you deliver quality. If the customer afterwards says well I wanted it differently but they had written it that way in their RFP we would say we have still delivered a quality system. While agile would say the feedback loop is that we encourage change. We want to understand what the customer really wants so changes are encouraged. If we are selling fixed price project also we have a problem with change request naturally. Customer would argue no that was the way it should be while with the agile method if we understand from the beginning we have an understanding. We partner with the customer we can get a better understanding of that but the business models matter also of course. There is a conflicting view of process improvements. In ISO the auditor is a formal in a formal audit he is assessing and judging what is a non-conformity and I am stressing judging. He may have a perception of that and it is his perception. He hasn't spoken to the customer he doesn't see the whole picture. In nothing what I am saying is saying anything what we are doing is wrong I am just saying it is incomplete and it is in conflict. In agile all stakeholders have to be involved in the collaboration and it is a different perspective. Now it is easy that the QMS will take over and be heavier on the weight and that agile will be less important it is very easy that that will happen. Now you are coming here to listen about agile and you believe in agile I assume and you don't want this to happen. So what can we do about it? Just before that I also want to say no I think I covered that I skip it. Now what can we do to mitigate? Well if we don't mitigate it could be like this. In my company I have done an action research together with my staff. Action research is a method a collaborative approach to do it. You do it together with the team. You watch, you plan, you act, you observe what happens and you reflect on it and you continue. It is much older than agile. First I think it has its root in the 20s, 1920s or something like that. It can be combined basically with any paradigm but it is fitting very very well into agile. We have used a collaborative audit. We have had the auditor and I was the internal auditor of some of these first iteration but then others have taken over. What we do is we jointly find NCs. The auditor ensures that we cover all areas but we jointly agree on what NCs. We encourage NCs. We use yellow notes. We do it in the retrospective meeting of a scrum retrospective meeting. We agree on the root course and we agree on corrective and preventive actions in the retrospect meeting. We have done it very light. We let the one who is assigned as auditor be a secretary and ensure that the wording and the reference to clauses and all of that are handled the right way so the team does not have to be too involved in that and can look at the creative process more. We also encourage identification on on conformities during the sprint. The one who is assigned as auditor may sit in on a few sprints but the members whether the auditor is in or not can come up with NCs when they do. We have what we call a hit and misses list. Also positive things we did which was not new things we interact. We would make up we can change this. We can do it during the process during the sprint and if we miss something, if something goes wrong we identify at an NC immediately. We may take corrective actions there. We still consider it an NC later in the retrospective. Yes, okay. Before the retrospective this is not specific for this. We also prepare all kinds of statistics. We have the auditor and the scrum master jointly ensure that that is in place so that we have statistics about schedule variants and other things like that. We have a lot of bug statistics and other things. We'll have that also and discuss it and we look for improvements for that. We have used there is something on the internet. I have a list with references for whatever I've got the stuff from. You can get that list if you send me an email and send it to you. On the internet you can find an inofficial scrum checklist. We use that one together with a checklist we have developed ourselves which covers most of the ISO aspect of it. We try strongly to avoid letting ISO come from outside and tell people what to do but we let the team try to see that they belong to a bigger picture. We strongly avoid a high-handed approach to it. We strongly avoid fault finding and we let the team fully buy into that it is an NC. Before we did this it was very common that the auditors were quite high-handed and the people felt very insulted by the NCs which were and they didn't agree with it. Now today we have a much better buy-in. The auditors have got lighter they're more meaningful and they are definitely more value. The auditor also don't need to know much less there was a problem earlier that the auditor did not understand the customer did not understand the specific technology and so sometimes that was a problem. We find that that's much less of a problem now than it was earlier. There's no focus on fault finding it supports continuous improvement much better it mitigates lip service to process and to quality objective also because everything is in the open there's much more transparency the data we have we have done this we started with one scrum team which has done four sprints in a row we started with a baseline and then we have done changes to it now they've done a fifth one they just did a fifth one I just dropped in I didn't see the fifth one it wasn't part of my study but they did the fifth one last Monday that was a fifth retrospective of a fifth sprint and they did this it has become the natural thing of how to do things. We're spreading it to other teams now we started with that but it's not taken root in the whole company yet but it's yet to come and we have been able to see that this has given more effect than what we saw earlier when we introduced scrum in the company this team has performed better because they have put that they have really done earlier thing NC's came so late so the corrective action often happened long after now corrective actions happening much earlier is a visible effect in various metrics here is I just took a photo from the last retrospective meeting in my office in the video conferencing system you see the statistics in the background but the team is sitting here you can't see the whiteboard where they have the yellow notes in the background but this was the last one and it worked I just dropped in and saw it was working very well some easy mitigation strategies of avoiding the conflicts and some of these are taken from a few papers which I have in my reference I've learnt some from others some we have learnt ourselves to avoid documentation you can take a photo of the scrum board every day and just put it in a directory somewhere and you have it documented that's an easy way to document you can record videos when you speak to customers over Skype or over video conferencing and store it if you need to some calls may not be important to store we find we're not looking that much at them but to satisfy the ISO we can do it also you can define there's a conflict with ISO when it comes to requirements user storage the auditor generally generally don't accept user storage as requirements but you can use user storage together with acceptance criteria and that seems to be acceptable to the auditors I've spoken to you can what we do we have an Excel sheet which is a live sheet which we put anything which happening during the sprints in we put the hits and misses we also make the live thing the changes which happen if we have a feedback over video with customer and customer suggest something we just put it there and ensure that is documented we keep it as a live document we check it in at the end in the document system we don't keep check it in on a daily basis it's been quite accepted by the auditor also that we do that we use demos and actively request feedback and changes from client that's nothing new with that we do injection analysis on the spot when we find NCC even if it is in the during the sprint and we calculate metrics continuously yes I think I cover the rest there are some cases with RFPs and with certain things where you're forced to follow a process what we have done a few times we have used agile in the middle we forced to do certain requirements and high level design in the beginning we forced to do system testing at the end so what we do is we do as much agile as we can and put it in an envelope of more traditional process it's not ideal but sometimes you have to it's part of the business deal you have to what's harder actually is to get alignment when it comes to the philosophies because external auditors customers and other stakeholders may not understand the paradigms of agile this is a tough one I can't say I have a solution I think it's the only way I think is to accept that no paradigm is a complete picture no paradigm is a correct if you think of the social constructivism reality we don't know the true reality we just use our senses to understand and if we use different paradigms maybe we can triangulate and see them from different perspectives and accept that reality is messy we're not ready yet we're working on it, we're getting better and better we're not ready with the journey agile means move it means that you're adjusting but we're adjusting sometimes in a hostile environment the other paradigms are there it's sometimes hostile yeah I think agile is not what you do, it's what you are I don't know if you've seen there is a TED show I don't remember her name Amy something, she says you fake it till you become it she's talking about postures, how you stand that when you do things you become like that that's what we have done in this action research we have done it, we were not ready we try it out, we do it when we see it works, we continue doing it until it becomes part of our culture I think our agile journey has been that all together it's not that we were fully philosophically agile from the beginning we started doing it and more and more we realized this is the right way to do it and our customers get happier so to conclude I would like to ask us all some questions we should think about what is our underlying paradigm what values do we have do we want to have which methods best support these values what practices are required to do these methods and which tools require to follow them I think we have to ask these questions when we work and we have to decide are we agile or which one is the most important one I'm sure you can't read all this I can send this to you actually I had more sources than this I don't want to waste them in somehow it's part of a number of papers one paper which me and a professor at Bleking a Technical University in Sweden we present in hopefully present in London in May some of these sources so any questions we had customers who said that some of the big companies they demanded that we should be ISO certified as you saw in the I think it's like it doesn't say what's inside it just says your ISO certified that was a requirement from the beginning I do find ISO helpful for one thing and that is to ensure that you do what you say I find the problem is with some aspect of the standard but that you are continuously sometimes it is like you're going to have an external audit it forces you to put your documents and other things in order I do find that to some extent helpful but sometimes the actual actions you do are not the right one you can use it as an effective management tool I think Toyota throughout ISO at the end I don't know if they are I think they are not ISO certified any longer because they thought the lean paradigm was more important than ISO but they still continue to do internal audits but they thought the standard was not consistent with their lean values I would at some stage potentially consider that if we had the organization where we could do it ourselves and our customers would accept that I'm not saying ISO is bad I'm saying there is a conflict and I think it is a choice you do at the stage we are I think we draw value from both the ideal and from the ISO but there is a conflict we struggle with it right just showing you the 7.2.2 it says the review of requirement shall be conducted prior to the organization's commitment to support to supply a product to the customer that's what ISO says they say you have to review the requirements before you commit I do agree with you but when you are ISO certified you have an external auditor which comes to we are at tick ID we have two times a year he comes he may interpret it that it has to be done this way and he may argue he may argue with us right right right we have two logics and got our auditor to buy into this but I tell you it wasn't DC yes yes right right right right right right right right in the internal audit this is possible to do quite easily you are getting an external auditor he is coming there for one day he doesn't look at your definition he looks at the standard and he looks at that and then he's he may look into what you said and then he said like well I disagree with that and then he gives you an NC and you have to motivate how you're going to close it I am a little cynical about that side of ISO because it's the audit I'm concerned about it's not I'm agree with you but the audit process is concerning that there are aspects of ISO also which tells management is controlling responsible for there is a conflict with self-management team managed team and ISO of course not but but the auditor may not agree with that interpretation I grew I do agree with what you're saying oh when they go and audit the product they go one in very very deep oh yeah that's exactly how that's how they audit they audit that way I think we are managed to mitigate this to a very large extent with the methods I suggested so the conflict is there but there are ways to cross over by agreeing on definitions but I think to some extent you also have to agree on that there is a philosophical conflict conflicts are not necessarily negative they can be healthy also I found this this discourse with the auditor with the ISO and agile it's very helpful for my and my company's maturity development of maturity I think the conflict has been good the conflict conflict helps me help us and me to grow so I'm not saying the conflict is negative I'm saying there is a conflict when it's helpful to acknowledge it but as I said if we look at the world as we triangulate with different paradigms we would understand things better but it's not neither paradigm is complete agile is not complete ISO is not complete but they give different perspectives to reality but in certain situations a conflict is a problem because one take precedence that's basically what I would say any more questions okay thank you