Common Component Architecture

Transcription

IVAR JACOBSON: So, thank you very much. Yes, I'm really excited to be here. You may not know it, but I am a resident of Switzerland. I live in [? Werbik ?] most of the time. It's a great pleasure to be here. The talk today is about the essence of software engineering-- the SEMAT approach. So I will have a couple of things to talk about. First is just to talk about what is SEMAT, and what is Essence. These are two concepts, but I would like you to know what it is before we leave this room. How many of you know what SEMAT is? And how many know Essence? OK. I would say 95%, at least, didn't answer positively to these questions. But remember, when you-- the rest of your life, you will always remember this was the first time you heard about these concepts, right? So, I will introduce the concepts and then we have two talks here. Welcome to State Club, it's a new way of thinking about software development and how you actually can measure progress and health in your endeavor. And having done that, we will talk about Welcome to the World of Practices-- is how you actually can compose your own method, your own way of working-- by composing practices. And how you, in an organization as large as Google, can actually be a continuously-learning organization. So that is what it's all about today. First, what is SEMAT? It's actually a community which we founded in 2009. Apart from myself, it was Bertrand Meyer, who most of you should know-- at least Swiss people-- and Richard Soley, who is chairman of the Object Management Group, which is a forum where new standards are taken. SEMAT stands for Software Engineering Method and Theory. Originally, when we identified what is it that we want to do, we wrote the case for action. It's time to act. And we got about forty signatories. We didn't ask for more. When we had got forty, or little less, we said, this is enough. It makes sense to do. And among these signators we find famous people from around the world in different areas, including computer science, software engineering and-- things like computer science-- I think I mentioned that twice. We have basically any area. Agile, pre-Agile. So the whole community is-- the whole area is really represented. 2,000 supporters have signed up for it. We also wanted to have some customers. People who really say, this is what we need. This is good for us. So we have about 20 companies. Ericsson, IBM, Microsoft. Not yet Google. Maybe that can be the outcome of today if we do a good job. And we also have 20 academic signators, meaning universities, that are using it for education and for research. It's a quite large community of people searching for a new theory in software engineering. General theory in software engineering. And they are publishing themselves quite a lot based on work being done here. Seven chapters of SEMAT in China, India, Japan, Korea, Latin America, Russia, and South Africa. And a chapter is created if you have distance, in a way-- for instance geographical distance or language distance. So many of these don't speak English so well, so we need to have a chapter. So we initialized to hold SEMAT with a case for action. It had two parts. First, there was what we said, that software engineering is gravely hampered by immature practices. And second, we support the process to refound software engineering. It's quite a dramatic statement. We want to refound it. Actually, it's easier than that. We didn't have a foundation in the first place, so now we are going to create the foundation. What is software engineering? A specific problem we identified is that we have a huge number of methods and method variants with differences little understood and artificially magnified. Every methodologist magnifies his own work. That is part of a game. And another refounding, we said we need a kernel of widely-agreed elements. So we need to find these things that are universal for all software development. So a kernel of widely agreed elements is what we felt we needed. And that is what SEMAT has been working on for almost five years. And we can see the result now. So why do we need a kernel of widely agreed elements? Because we have no common ground. When you teach anything in software engineering you have to basically start from level zero. Maybe some terms you can use, but we don't have a vocabulary. We don't have any foundation. So that was how it all started basically. We don't lack methods and practices. How many methods do we have in the world, do you think? It's more than 100,000 at least. So it's quite many. The problem is we don't know which they are. We have no way to learn from one another, really. Even in a big company, you may have 25, 30 different methods. And people working in one area of a company cannot move-- even if they are very professional, 10 years experience-- cannot easily move to another area because we have no common ground. They have to sit on the school benches. I have done it. I know how it is. It's terrible. You have lots of experience. The young kids started yesterday, or maybe a year, know much more than you do because they know the language of this organization. That's not good. We don't take care of our best people. So every one of us knows how to develop our own software. But as a community, we have no widely accepted common ground. That is a dilemma. So if you see here, we have all kinds of methods-- of practices. User stories, use cases, Scrum, CMMI Waterfall, whatever. But they are isolated islands. You cannot-- you learn one area and then you cannot easily move over to another. Do you recognize this problem? Those who are senior here? OK, good. It's significantly more than we had positive answer I got last question. So anyway, what we want to do is build bridges between these so you can easily connect. And basically, such a foundation we want to create should not compete with these ideas. They should still be there. They are still good at-- but they should help us to have a common ground for them. So basically what we say today is that we use-- we power these technologies. We improve them. We make them more effective by using Essence as a platform. Because Essence is very solid. It's the first result of SEMAT. So yes, this is the first [INAUDIBLE] is we call the Essence Kernel. So this is a common ground on top of which you can build practices. One, two, three, four. As many as you want. And you will see more about that in the next presentation. These practices can share things. They can also be composed and the overlap will disappear. Be nicely integrated practices. The interesting thing is, though we have 100,000 or more methods in the world, we only have a couple of hundred practices that are documented, that are described. So basically, one of the most important discoveries we did 10 years ago is that basically every method is just a composition of practices. So every method is a soup of practices because, when someone creates a method, they do take what they like. And understand. Not to forget, that. You don't understand everything, so you just take what you understand. And you make your own soup. And that soup may work. Usually, because you have good people. Or it doesn't work. So this common ground is what we call the kernel. And we use this notation to talk about the kernel. So what is now the kernel? What's inside this kernel? Well the most important things are what we call the alphas. The alphas-- alpha is a new term. We have never had that in the software engineering community, so it's a new concept. You will see why it's new as I go on. So these are the things we always have. Always produce. Always have when we develop software. We always have stakeholders. People who want to use and consume what we develop. They have seen an opportunity and the opportunity is implemented in a software system. The software system helps to address the opportunity. It fulfills requirements. So when you see this word, requirements, don't think about the specification. Don't think about the documents. Because requirements are there even if you don't document. When you build something, you have an idea, an intent, of what you want to build. And this can be documented. It can be discarded. In many case it is. But it doesn't need to be. So requirements exist even if you have no documents. Just to take these three. You also have work to do to fulfill requirements. And the work will result in updates and changes to the software system. You need a team. There's always a team to develop the software. They may be only one person in slim case, but there's always a team. And then you always have a way of working. A methodology. Even if it's not documented, you always have-- a team applies the way of working and the way of working guides the work. So these are things we have identified as always universal. Something you always have when you develop software. They are-- you shouldn't think about these as documentation. You can have a way of working without ever describing it. It's in the group, in the team. And I guess much software is developed without having a described method. We have three different concerns. You see, we have a customer concern, which is related to the opportunity and the stakeholders. We have a solution-- that is requirements and software system. And then we have an endeavor, which is work, team, and way of working. These things progress independently. They are different-- they basically represent different dimensions of software development. Another very important characteristic of these alphas is that they have states. Progression states. So for instance, requirements move through a number of states. From beginnings, just conceived. And then it is founded, meaning you have an idea of what the limits of the system are. And so on. So you move through six states for requirements. Every state is defined by a checklist. Here to the right, we have a checklist for every state. And then we also have a little card for each state. So basically, we have two kinds of cards. We have cards for each alpha. It's one of these requirements. Software system, and so on. And we also have a state for each one of them. So each alpha goes through number of states. You may progress-- a really good work means you progress all of these things basically at the same time. Here's another perspective of it. Actually this is a [? toon ?] developed in Italy by some people at the University. Base view, here in this picture you see that these alphas represent dimensions. You have seven different dimensions when developing software. If you forget one of them, you will take a big risk. So for instance, you have-- all these alphas, I mentioned earlier, represent one dimension. And when you work you progress each one of them, basically in every iteration never split. You have to take consideration each and every one of these. There are more things you can have taken consideration, but at least these things. So one of the most important things here is the checklists. And the checklists are incredibly powerful. For instance, flying an airplane doesn't happen without going through checklists for many different checks. And no one would sit in an airplane without knowing that has happened. I mean, we wouldn't fly. Surgeons have a checklist with about 19 different checks, asking things like, does the patient have a known allergy? And so on. And from the beginning, the surgeons didn't want to have this. They are qualified. They don't need to have checklists. They have been educated for many years. This is ridiculous I have to do this. But result is that the number of unsuccessful operations, meaning deaths, were reduced by almost 50% by just using this simple checklist. So simple checklists save lives. Why not software projects? Of course. But we have had checklists in the software community for forever. The problem has been with these checklists that they were asking questions like, have you written this document. Have you made-- have you had a requirement specification signed by managers? Or have you done this job? Have you made this activity? That is really not give any real value, because you can write the document without having done anything really useful. People filling templates just to have done the job. So these checklists are measuring real results. [INAUDIBLE] So all questions in the checklists in our case are a measurement of progress independent of how you did it. If you used user stories or used use cases or used feature-driven development or any other thing-- it doesn't matter. You measure progress in a uniform way. So the great thing is that in an organization like Google, you could have many different projects going on but you use the same way of measuring progress. OK, you can add more to it. But you have a starting point by using this work. So this is work that has been done within the SEMAT community. It's not the only work, there is more done. Particularly with theory-- in the search for theory for software engineering. But this is the most interesting to us in the industry. So it has become a standard. There is a book. There is actually several books. But this is one book that we have written about the essence of software engineering which describes how to use these cards in practice. So its essence is a Kernel and Language for Software Engineering Methods. It's very agile so it's easy to change. It's easy to do what you want with it. But you have a starting point. So now I'll get to the second section which is about the playing serious games. Software development games. We call this Welcome to State Club and How to Be Lean and Agile with Processes, Checkpoints and Governance. This is of course referring to a Fight Club by-- what's his name? You all know who he is. And instead of the fists, we use cards. Here is a set of cards. It has, not 52, but almost 52 cards. And they are used to play. And I'll show you how we play with them. And we also have, for in a team-- we have a little bigger cards so we put one the wall so people can go and write on it in the team. So it's the same cards, but its used on the wall, on the board, so you can actually describe where you are and so on. And of course we have a little smaller one. So that is for all tastes here. So we will do a couple of things here now. Show how to use these cards to build a health monitor, and we will play two games, Progress Poker and Chasing the State. Progress Poker is to agree on which state are you, the team agrees on in which state they are right now. And Chase the State is that the team agree on where are we now, totally, and what do we need to do next. So the cards are-- we use these state cards to visualize the health of your software development endeavors. So basically, you could think of a scenario-- you go in to team-- you have never been there before, you have not necessarily worked with them. But you can, in quite the short while, get the team to agree on something. Where they are right now. In a way that was very hard to express otherwise. You would have to express it in terms of documents, or something that is more visible, more tangible. Here, this is-- even if it's tangible, it's more abstract, so it doesn't mean that you have to agree on a particular methodology. You can use any methodology. You can use it for small teams, big teams, large organizations-- you can use it for any kind of software development project, any kind of application. The same thing can be used, and is being used, in a very concrete and valuable way. So let's look at this. So we are building a health monitor for be used by a team. We start by laying out the cards. So these are the alpha cards. These are the cards that describe every alpha and its states. So it gives an overview of what states you have. So here you have a first state, is that the stakeholders are recognized. And you see underneath-- you cannot read it, but underneath are a number of checkpoints. To get to this state, you have to agree that these things have happened. So it's recognized, represented-- have found the people who are representative stakeholders and should have a say in what we're doing. And in this way, you add more and more. Next line of alpha card-- opportunity. And you have all the cards here. To the left, you have the alpha. The key elements that you have to measure. And to the right, you have the states. How far you have reached. So you start by looking at the-- take up one of the cards. And you go-- sorry, you take one card and then you will move it to the left of the screen. I'll show you later how it actually works. So what do you do? We had, last year in Nashville, a presentation. That's an Agile conference-- and had about 80 people. And presented a case. We actually got some documents to start with and looked through the documents-- we had about 15 minutes-- 10 minutes to look through the documents. And then they went in and evaluated, which state are we in. And of course, these states cannot be 100% unambiguous because it's just English. But the value is that they make you, as the team, to think about things. Have we reached this state? And what do you mean-- what does it mean-- is a discussion point. What does it mean to reach this state? What does this criteria mean? Of a checkpoint. And the discussion results in an agreement in the team. And that discussion is more valuable than if there was a formal-- well, a formal definition of every checkpoint would not give us anything of value. So you have some documents. And collect these documents. And then you sit in the team and agree on which states you're in. So, for instance, you start by looking at the first card in stakeholder and see-- Are we recognized? Have they been identified? Is there an agreement on which stakeholder groups should be represented? And so on. And you check if they are approved. And if they are all done, the first card on the top we move to the left. So that is [? once ?] something you do. You could take the next card-- see that little thing here? You see it shake? It took two hours to do. So then you take the next card and see if it's represented. Stakeholders are represented-- yes, yes, yes, they are. Wonderful. So you move that to the left, too. Then you get to a card where you find, no, this is not done. This is not done. We have not got the stakeholders involved. They don't do what they're supposed to. That's a bad thing, OK? So really good to force you to say, this is not done. So we cannot really move forward. If we move forward, we take a risk. So we should be aware that we take a risk. So this card will stay where it was, not move to the left. And that way you go through, line by line, and agree on where you are. And some of these, you may not have done anything. For instance, there was no work done on way of working. So you still have to progress that. And that means, if you look at the card you will find, this is not done, this is not done-- oh, that is a risk. You should think about, what do we do to remove that risk. OK? So, in this way, we can show where the team has reached. And help them to decide where to go next. Because obviously, to move to the next card is where the team should go. This has been used in several organizations. Actually, quite many organizations around the world. Now, I have to tell you that this was first done in my company, Ivar Jacobson International, which is represented in at least five countries. I think it's more, but we have companies in five countries, not counting Switzerland-- which is where the head office, is by the way. So it's a Swiss company. And we have been working this for almost ten years. So in my company, we did these things for five years and then we said, no, no no, this is not the right way to do it. This should be a standard. We need a standard, otherwise nothing will really grow. Because otherwise, everybody would create their own kernel. And then you have no foundation, so you try to describe practices on top of a kernel-- which we will talk about in the next presentation. So this has been used-- for five years it was used entirely in my company. Then, we started to go to create this community. And when we did the community, we agreed to give away everything we had seen, but not push it. So when we started to work on the kernel, we didn't present our kernel to the others. We started to find a way to work on it. So this is actually-- in China, it's a team working on internet applications. And they used these cards on the top. They use the cards to measure progress. And they put them on task board so they all reason about it. They use these big cards that I showed you, but they were in Chinese here. And they were also in gray. They helped the team to be agile. They helped them to set goals for the sprint and with retrospectives. So not only are these cards used to guide the team on what to next, but actually go into the team and look at where they are and what they haven't yet done. So it creates retrospectives. And they help us in-- imagine the whole organization, in this case, we have many project-- many teams working in parallel. And they all use the same way to measure progress. And in that way, they could learn from one another in a way they didn't do before. So this was in China. And this is Carnegie Mellon, on the West coast, which is a University teaching software engineering. And they had 28 post-graduate students that all were out working in the industry and they wanted to come back to learn more. So they created seven different teams of these 28 students. They could develop any application they wanted. They could use any methodology they wanted. But they used the Essence kernel to measure progress and health. So at the right, we have the different seven teams and how they worked. After six weeks, they had reached different states. Some of them worked very balanced. They progressed each dimension, each alpha, in every iteration. Some of them focused on the early-- more like a Waterfall approach. Which is completely OK. If you want to work Waterfall, this works very well for that as well. But of course, most people today would use it for iterative development. So this allowed the different teams to measure progress regardless of what practices they used. And it helped them to discover problems early. Because, for instance, if the stakeholders were not engaged, they would get that question early and say, no, they are not engaged so I cannot progress. And then they can say, we have to do something here or we take a risk. So that is the first game we play, Chasing the State. And there is another game here, and that is to-- as well as you can, show where the team is. The cards can also be used to create checkpoints to show where the team should be. So they use this, through use of the cards, to identify where they should be. So imagine the situation that you're developing software that should be go to operations for deployment. You need to have support ready to take on ownership of the system when you get to that point. And the critical legal compliance requirements must be shipped. So this is a real situation that you have. Would it be good to have a checklist that could be used to confirm whether or not the software system was ready for release? So how do you-- would you confirm today that this is ready for release? We evaluate risks. It's not an easy problem. One of the problems we have is always to define the definition of done. When are we done with something? So in this case, we've started by saying, which alphas do we care about? Software system? Where should be? It must be ready. And ready is defined by a number of checkpoints. And requirements? Well, it should be address and fulfilled. So this is where we want to get with requirements. Opportunity addressed, stakeholders satisfied for deployment, and so on. So we go through, and all of these things help you to agree on what should be done. So, are these checklists efficient? Not necessarily. For instance, you may want to have something extra. An extra checkpoint that you don't have. Yes, please. AUDIENCE: Do you want the questions now or [INAUDIBLE] IVAR JACOBSON: We are going to give you 30 minutes for questions at the end. So it's better to save it unless it's-- AUDIENCE: [INAUDIBLE] IVAR JACOBSON: OK. So that will be as planned. And we hope you prepare a lot of questions, because that is real fun part for us. So if you, for instance-- software system, you can add checkpoints that fit your organization needs. By the way, as you can understand it's easy to scribble something on these cards, if you want to add something. So it's very flexible. What we provide is a starting point for you. So you can start with something, and from that learn. And you will definitely prove it so it fits your needs better in the long run. So here is an example-- you want to have a certificate in place before you consider software the systems, you just add it on the card. So as well as showing you where the team is, the cards can be used to create a series of checkpoints to represent your development lifecycle and help with governance and compliance. So you can actually, now, create your own lifecycle for a software system. Usually, companies buy into one lifecycle. One lifecycle pushed on every project you have, instead of having different lifecycles which you can have based on the kind of problem you're solving. So you know about these-- working in sprints. You have iteration zero, where you set up a project and make a plan. Iteration one to n, you develop and test. You get feedback. And the [INAUDIBLE] iteration nine is you release your product. After every such phase, or step, there's something needs to be done. You need to know when you can move to the next step. That is not trivial to define. This is an example where you can use the cards. And I'll show you-- this is another very particular method to use for scaling Agile by Scott Ambler. And he has three phases. Each sub-phase must have a definition of when you're done. It's not easy. It's not easily done. We have these things where you have a lot of ideas. And you find business cases. And so on. And you have-- after the end of each phase, there should be some criteria for when you can move to the next phase. Because this is all about business decisions. It's not about iterative development. Where you're sitting and develop features, for instance, one by one. So you need to have phases. Phases are needed in the software development. Here's an example for one of our customers, KPN in Holland, where they had an approach for-- we have a number of phases. Each phase identified that something needs to be done. [INAUDIBLE] before we started to work with them-- and now I say we, I mean actually my company. So this was actually done before SEMAT was created, or about the same time as SEMAT was created. And so for every such phase, you had to deliver some document. And for instance, the decision to fund was a couple of hundred pages of documents you had to review to see if it was done. It was document based. And that is not a good measure. So instead, we added these-- the kernel and the alphas. So you can see here that you have every row represents an alpha. The top row represents opportunity. And the green point represents what needs to be done. It's a state. All these little boxes represent states. So you need to have reached a particular state to be able to move from one phase to the next. So this was used here. The value was that-- for instance here, opportunity. The progress of opportunity-- we moved from state to state here, over these five phases. So what we did is moved away from signed documents to recognize achievements. That you really can measure achievement without looking at the documents. So that was KPN. So in general, you can lay out your lifecycle and say, I want to have, in this case, three different milestones or checkpoints. Decision to fund, decision to go live, and decision to handover. So what would-- now using the cards. So what would you require to get the decision to fund? Well, you look at the cards and you come up with the first four cards for opportunity must be fulfilled before you can fund it. And so on. The software system, you have one card that needs to be achieved. You need to get the first state of the software system before you can fund it, meaning you should have an idea that there is a solution to the problem. And in this way, you can this describe any lifecycle using the cards very clearly-- distinct. Something that is very hard to do, if just use English or communicate with one another. As you see, some cards are lying down. That is the way we use when it's optional. If we need to get this state-- is optional. Here's another customer. This is Munich Re, in Germany. The largest reinsurance company in the world. Represented in the United States, in Singapore, and I think in many other places. They started to use these cards-- and here, see, another way to represent it. It's a poster with sliders. So you move states up and down the slider. And you decide to reach-- and to the left, you have the different states, the different checkpoints. So in this case, you have four different checkpoints for the project. And you decide how far you need to have reached to pass a particular checkpoint. Now, they found they have seven different kinds of projects. They had one they call exploratory, and that is risky projects. New projects. We had not done it before. So we had a different milestone for that. You should have a lot of these kinds of projects here. So you may have different milestones, different checkpoints, that works for these kinds of projects. Then they had a standard project. This is more like adding more features to an existing system. They had another, and then they said, we need five checkpoints for this one. And small enhancements-- that's maintenance. You make small enhancements. So they had another one. And they used to same cards to define these lifecycles. And finally, for support. They used the same key ideas to define-- what are the different checkpoints? And what is the definition of a checkpoint? Definition of a checkpoint is done by specifying which states should have been achieved of the alphas. There is an app-- unfortunately, only iPad and iPhone. I apologize. But this may change-- can easily change after today. So in this app, you can actually-- also, you have states, so you can click on it. For each of the states, you can check if you have reached it. So this is a tool you can use in your project. It's free. But the risk you take is that you like it. So there are particularly four things to remember of what I just said. So this is basically kind of summary. SEMAT relies on a common ground, or kernel. We call this kernel Essence. The kernel includes seven alphas to be used to measure progress and health, so that's another. So this alpha concept is new to software engineers. It relies on a simple, intuitive, visual language. We have so many languages in the software community, and some of you may know about UML. These languages are not easy to use. The tools are not easy to use. I remember when I worked at Rational Software that the people said that the tools could only be used by Ph.D. students. And whereas most people are not really interested in the technology they want to have support, so we have been spending an enormous amount of time to find a simple way to express ourselves. And that was one of the goals. And then let me play the software development is played as serious games. On our website-- and I made my company's website-- we have seven different games that you play in developing software that are really helpful in doing it. So now I've come to the second major section we'll [INAUDIBLE], and we welcome to a world of practices. Here I have asked a colleague of mine, Ian Spence, who is also working in IJI, my company, and who has been instrumental in the development of a kernel and what we have here. He's the guy who knows more than anyone else about how to the kernel, the essence, and the practices in real situations. So, welcome Ian. IAN SPENCE: Good afternoon everyone. [APPLAUSE] So this is going to be a bit of a lightning talk, as we haven't got that much of the time left. There's a few things I'd like to add to what Ivar's been saying in the way we can use the kernel as a foundation to empower our software development teams to innovate and share their practices. This is where we can act as a worldwide community to improve how software development works. And the interesting thing is, we are in a very competitive market. The world is changing, the technology's changing. We can't afford to stand still. This is not an option for the companies we work for, and is not an option for a company like yourselves. Can't imagine you're ever standing still. But we need to keep moving quickly and keep up with the times. And as companies grow, we need to be able to share those things have helped us be successful with each other. And what you find in the software industry, is that there's this tendency to think there's one true way of developing software. There is one method. And what I want to tell you is that there is no one true way to develop software. There is no one method. The Agile Movement has given us lots of great things, lots of practices. Well there's a worrying tendency for them to say, these are the one true practices, tie them all together, and produce another big method. I mean Ivar himself once tried to do the Unified Process. This was very popular for maybe about five years or more, but you look at the practices in it, like use cases, iterative, they still go 20, 30 years later. I've been in software development over 30 years now, and there's still some things I learn, there's still a foundation of things I do today. So if we can get and understand those practices, understand the circumstances, then every team's way of working becomes a collection of practices. And when teams are trying to do things that have never been done before, they will start to create new practices. Now if those practices can play well with the others, then everyone can benefit from them. I'm sure many of you do Scrum in your projects. We had a little tour earlier. I saw at least one Scrum board, and a board saying which we can [? spread ?] people within. What had made Scrum so successful and kept it alive? It plays well with other practices. It doesn't tell you how to do the requirements. Now, when people pick up Scrum, they think they have to do user stories for example. But you don't. You can do use cases. You can do features. I've spoken with Mike Cohn. He's done projects with use cases. Alistair Cockburn is quite big in the Agile Market, [INAUDIBLE] he's done books and things on use cases. But what you've got to do, and one thing Alistair does on all his courses, is he makes everyone swear an oath of non allegiance. We need to free the practices, make them independent. There are practices I know that have come out of Google, in the areas of testing other things that other people pick up and apply. But their environment is not the same as yours. They might need to have different kinds of controls for using different technologies. So if we can free the practices, we can create an industry where we keep competitive in our software development, we keep moving, and we can share with all our other developers and communities around the world. And that's part of the goal of SEMAT. So as a matter of practice, this is a very simple idea. It's just a repeatable approach to doing something. And what we've done with the kernel, is come up with a way to make the practices be able to play well together. So you can see how they fit together. So they complement each other. Do they conflict with each other? And the way of expressing them. So with the card idea-- I'm going to try and skip a load of slides on the fly-- so we have the cards. So just like the kernel was put on cards, we can put our practices on cards. Just like the kernel had alphas in it to show you the big picture, practices can have ones to show you a little picture. If you're using user stories for example, I suspect somewhere you have a tool where you can see whether they've been prepared, whether they've been completed, whether they've been accepted. That's a classic case of an alpha. You'll have documentation to go with that, describing the story acceptance criteria. When you're doing activities like a workshop to find use cases or a workshop to find user stories. It will be useful to have, one, information to help you plan, how long it's going to take, who should be involved. So we have activity cards to show that information. And they can also find one on the stack that is a checklist for people undertaking an activity. Are you ready to start, have you done the right things, are you ready to [? end? ?] And again with the kernel, you can use these to communicate with each other, to find out where you are, and to drive things forward. You could also plug and play with practices. So this idea is very powerful. And just like surgeons benefit from checklists, --anyone know what that is? That is Buzz Aldrin's glove, from when he went to the moon. He had on his glove, a card, and on the card was a checklist. So that him and they Neil Armstrong, when they're on the surface could coordinate their activities. This is what we're trying to do, provide information that lets our teams work, communicate, and collaborate effectively. It's the same kind of thing. With this you can, with the kernel, you can bring your practices together and plug them together safely. You can look at some other things than just the alphas in the kernel. That's a match [INAUDIBLE], that'll allow you, when you're out of practice, you can add information into the checklist in the kernels if you are doing use cases, when your requirements are conceived maybe you should have a use case model. So it will start to come together, and there's stuff to help you analyze and understand your practices. So I will skip over that a little bit. And this separation of concerns is key. You're mainly software engineers, so you'll all have software engineering practices you can share with your colleagues. But, there are other practices in your business that you need to be cognizant of. There's always some kind of financial governance and time recording and things like that. Let's make that important, but not constraining how you develop your software. You're the experts on those things. And business practices as well. You might have to work with your stakeholders and your business. How are you going to communicate with them? It's great to say, we will talk to every day, but it's not always possible. So you might want to add practices in those areas. So the key ideas is empowering things. We're not trying to sell you a method. We're trying to sell you an idea that will allow you to explore, and create, and establish-- for your teams-- the best way of working to do that job, and to understand, what is the best practice in your situation. You can't set up something that tells you the best practice in all situations, but look at their strengths and weakness. So this is the idea. So there's a couple of other slides in here, just a couple of case studies with a company that had different life cycles and different sets of practices for different kinds of projects and customers. Another example is Fujitsu services, where they set up a set of practices they can use when they bid with their customers, that included both waterfall and iterative ways of working. Because the customer gets to set some of these practices, not the supplier. But it also helped them pull their tools together. By lining the tools up on the kernel, they ensured that they could use the same tooling, regardless of which practices the teams were using, which then frees the teams from being, oh, I'm using this tool, I must use this practice. And it even got as far as cards appearing in their ALM tooling, in Java that they use for their stuff. When they go to tasks, they could see the cards and the checklists that applied to that piece of work. So, I'm sure you've got the idea, this is a powerful idea, it helps bring people together, it helps you build communities. Where do practices come from? They don't really come from people like Ivar or myself, they come from people like you. People who are doing the work, doing the innovation. What we do is we meet you and say, that's a good idea, we write that down and take the credit. But let's get it so we can take out those middlemen and have communities and practitioners working with each other. So I hope that's been useful for you. Bit of a lightning view-over there. If you get hold of the slide deck, there's more detail on the different kinds of cards and things. But now I'll hand it back to Ivar for questions and the final wrap Up. [APPLAUSE] IVAR JACOBSON: So, who wants to ask the first question? And actually, I have a little bit more able to say. And then, we get questions. I will be very happy when we get to questions. So just to give you some kind of conclusion here, SEMAT is in essence, have been going on since 2009. We started to write the paper for Dr. Dobb's Journal, in need of a theory in software engineering. That was 2009. And this theory basically was meant to get an understanding, a foundation. We developed Essence to stand out [INAUDIBLE] June this year. I'm sorry. And we have this book and number of other books. We can highly recommend you to read this book. So what you could do is find out more about the practices. You can go to our website, I mean IJI's website. [INAUDIBLE] SEMAT's website, where you'll find a lot of material, and papers published by many people and work going on. And so [INAUDIBLE]. And playing with games, you can have find to the Alpha State Cards, on our website. And I see that there will be some cards like this available for you. You can go through LinkedIn to participate in discussions and uses of it. That's all we want to say. We are in five different locations right now, and have companies in five different locations. In the US, UK, China Netherlands, and in Sweden. So we are happy to now go over to the questions. Finally, The questions. [APPLAUSE} AUDIENCE: Thank you very much for coming and sharing with us. I want to preface that sometimes it's nice to understand something by probing how it's different than your expectations. So if it sounds like criticism, please just take it as engagement. I find that for a lot of teams here at Google, the goal isn't to win, it's more like to survive and thrive. But in the way that pragmatic programmers put it, we're not really building structures we're gardening. And we're trying to tend to things and make them survive and last and grow. A lot of these methods seem geared towards starting, progressing, and completing, which ignores the fact that we need to have maintainability and just long term continued progression without ever completing. Could you please address how we would use that for that situation? IVAR JACOBSON: I think this is quite typical for a very successful technology company. And we are moving very quickly. But eventually it will be necessary that you create an organization that is continuously learning from one another. And it's very hard to do traditionally. In my experience, in so many companies that we have worked with, its been very hard for companies to create organizations that people can continuously grow their knowledge and learn from one another. So this is one of the objectives of SEMAT to do that. But there may have been something more into your question that I didn't really grasp or comment. AUDIENCE: Are these methods useful for understanding the maintenance of a system that continuously improves and never completes? So all the cards never move over to the left. IVAR JACOBSON: So yes, I can let to Ian respond IAN SPENCE: So an interesting thing about the kernel and the cards is that it's about understanding where you are and then putting that in context. So you don't have to have a fixed life cycle, but you can understand what it means. Say for example, for your software to be ready, a lot of companies do continuous deployment. But you can look at the checklist to see if you've gone back. Maybe you've forgotten a few things and actually its not ready for deployment anymore. So you don't have to use them in a linear sequence, you can use them as a map to see where you are. And then balance that against your goals and objectives. So they're useful in lots of circumstances in terms of having a healthy understanding in the team, where you are, who's involved, what's going on. So that can be helpful in those circumstances as well. IVAR JACOBSON: Are you okay? AUDIENCE: [INAUDIBLE] IVAR JACOBSON: Yeah, you should stand here because I was [INAUDIBLE] onto you. But that's a benefit to the people on the cameras I would think. AUDIENCE: I would like to follow up on this question. It also seemed to me that the cards, as far as we saw them, were mostly informed by projects that were just started and had to go to completion. So the question is, were are these cards actually informed by projects of the type that were just described, that are very long lived, that evolved for a long time over time? IVAR JACOBSON: Yes. AUDIENCE: So maybe we just need to look more closely at the cards. IVAR JACOBSON: And [INAUDIBLE] very important the second part of the talk that Ian gave is about adding practices on top of the kernel. The kernel is universal, and something that every project would encounter. So to reach to specific things, you need to add practice on top of the kernel. Every practice has its own alphas. It also introduces what products which are not in the kernel, and activities, things you need to do. So they are working, for all of a whole life cycle, for not only starting as one example, Munich Re has used this model to describe with different milestones for maintenance projects as well. AUDIENCE: And I have an unrelated question. I can imagine that you can use SEMAT to create a map of all the existing methodologies, and where their strengths and weaknesses. And this ever been used to actually go into a team, look at how they're doing, and then maybe choosing a different methodology for them to compensate for the weaknesses that you observed in how they're currently doing? IVAR JACOBSON: Definitely, in several cases. But this where Ian is the expert. So I will let him. IAN SPENCE: One of the things that has been done most with the kernel is exactly that, to help the team understand the strengths and weaknesses of their current way of working, and look to improve it. So I've used the cards just in retrospect is with Scrum teams. Because I've never seen them before, but you've been going a while, and you've taken your eye off the ball in some way. So you can go and see where you are, and you can take your practices, write what you do on Post-It Notes, stick them onto the kernel, and see that we have 50 ways of describing this, but we never talk to our stakeholders. We've seen some traditional organizations. So that's been used a lot in those areas. You can use these things without making a full commitment. You don't have to build a method. You can use them just to understand how your tacit way of working is shaping up. AUDIENCE: I take it these were successful interventions. IAN SPENCE: Yes, when you do the card, you get a conversation started. So people find strengths and weaknesses in their way of working. And things like that, and then they use that to drive improvements, and they're very easy to use. IVAR JACOBSON: One of the most common mistakes that were done in China, one of the big companies we have been working with, a really big company, was that they didn't involve the stakeholders. So there was no thinking about stake-- they had stakeholders, but in a loose way. So the seven projects were just the [INAUDIBLE]. No one really wanted their product. Such simple things. As soon as we talk about the surgeon, they had almost 50% percent of all deaths that they had before were disappeared by just the simple checklist. And this is a very simple checklist. All the stakeholders were in agreement. All the stakeholders, first of all, [INAUDIBLE] identified them? Are they in agreement? And that is something we often forget, we developers, we think we understand what needs to be done. AUDIENCE: Hello, thanks for the talk. I just wondered about the efficiency. If you have measured efficiency together with some control group of teams, using this in a checklist compared to-- the any control group and what the result was from that and how you measured it basically. IVAR JACOBSON: You want to take it? Be honest. IAN SPENCE: The interesting thing is that the most of the efficiency will come from the practices that have been selected. The kernel allows you to understand how things are progressing. Probably the most scientific study is the stuff from Carnegie Mellon, where they looked at that those certain people doing individual [INAUDIBLE] all at the same time. There are, I believe, papers being published on that. That's quite interesting. You would look at those graphs on the top right of that slide, and you would make some judgements about what kind of method they're using, and who's doing best or not. But what's interesting, it just shows you the situation. So where I've seen this used-- What using it does, is it helps projects be more successful. But whether it makes it more efficient, there's no real evidence of that kind. This kind of efficiency measure is very difficult. AUDIENCE: Because what was the results for the successful rate? And how did you measure if a team was successful compared to the other? IVAR JACOBSON: Well, like I say this is about understanding where you are. I did do a lot of work at KPN where they had 14 programs, over 400 projects, and they used a method based on the kernel. They did their QA based around the results. So had you got the result you needed rather than had you done it the way. Right? And some projects opted out of working in this way. But everyone was measured not with the kernel, but with productivity measures and things. And the ones that opted out and carried on in the traditional way, all did worse in all measures. And they had worse quality, more slippage and all of those things. Now you can't attribute that purely to the fact that the others had the kernel info. Is also the practice it. But we have seen that kind of separation. In our industry there's not a lot of good science done on the effectiveness of methods and practices. The same holds for agility and things like that. AUDIENCE: OK, thank you. IVAR JACOBSON: So there's a few examples. Let me add to this that the kernel is just a month old. The standard. We had a kernel in my company and used it. So we have experience from using the kernel. The kernel was basic that we had. It is very similar to the standard, by the way. So it's very easy to move people that were our customers, can easily move to the SEMAT kernel, even if they worked with us. But what we haven't seen is comparisons whereas there are all people working with Scrum. And they have now, and writing papers about how they experience, how much better it will be by using SEMAT Essence as a platform for Scrum instead of describing Scrum in the Scrum guide. And you can describe it on top of Essence. You can make a much more concise description, and it's also very easy to find holes in Scrum where Scrum doesn't really support you if you need some other practices. But we would like to see that kind of papers, experience reports. It is not yet available. AUDIENCE: So in the last part there was some talk about business practices as well, this division into three different groups. So is this going to stay a software engineering thing, or are you planning to branch out to practices and all kinds of work in general? IVAR JACOBSON: Yes, I take it. We have interesting enough, we decided originally when we start the SEMAT, we took a hard decision. Should we support more than software development? And we said, we have to make it successful for software development before we go to other areas. And the other areas is typically systems engineering, business engineering, and there are other areas like projects in general. In Russia there is a group of people from INCOSE, which is systems engineering, which has made some minor extensions to the existing kernel to make it applicable for systems engineering. So that is a group of people working with it. There's another group of people also in Russia working on using it for project in general, so not only software products or systems but any project, any endeavor, human endeavor. And finally there is a group of people working on using the kernel for education for high school students in software. But this is just for beginning. The interesting thing is that the academic community has really taken on using it. Because, for the first time in the history of software development, academics can teach what is the core of software development. What is it that you always do? And they don't need to teach a particular method. In Sweden, for instance, one university teaches Scrum. Another university, extreme programming, Then a a third one, [? KAMPA ?]. . So when people come out and they meet, they're sitting there with no foundation, and have to fight to get to some agreement. Have you seen that by the way? That should be normal. But if you had a-- Because there's nothing really fantastic about this code, it's just the foundation. We don't need to have a lot of arguments about whether this is the only-- It's not the only foundation we could have had. Its one foundation, and if you don't like it, make some changes. IAN SPENCE: So, at Fujitsu, they model their sales process and other things using this way. What I like to think is that for too long, in software development, we've been looking at other industries and taking their ideas. I think it's time they should start looking at us and taking some of ours. So hopefully if this is successful within software, then other areas will pick up on it. So It could be generally applicable. I'd like to see that thing turned the other way around. The software isn't manufacturing. It isn't building buildings. It's a new thing. And we've got lots of new ideas. Not just us, I think we all do. AUDIENCE: And so you maybe touched on my question with this answer. Do you have an established process for updating the kernel itself, like not extending on it, or updating it, for a specific team, but the master kernel itself? Or do you think that it's universally true and will never, ever, ever change? IVAR JACOBSON: And so let me-- Can you rephrase, repeat it, please? IAN SPENCE: The question was, is there a process for keeping the kernel, evolving the kernel, improving it, and keeping it up to date? Or do you think it's the one true kernel, never needing to be changed? IVAR JACOBSON: No, first of all we don't believe there is one true kernel. We don't believe the kernel we have now is the best one, but it's a good one. Because as you know, the best may be the enemy of good. And then when it comes to changes, this is thankfully now organized within [? object ?] management group. So they have a developed a form, or process, for changing. And there will be-- There is already started the next version of a kernel. That work has already started immediately when the standard was taken. So there is work going on, on identifying problems, coming up with new solutions. So there will be in maybe one year's time a new version of the kernel. But it's probably not dramatically new. Only if really dramatic problems-- But we haven't heard anything. Actually we don't see any problems. We only hear people are doing well. So if you hear and know any problems, please tell us. We would love to hear about them. AUDIENCE: Thank you. AUDIENCE: That's just sort of on the softer side of things. But given that you've had a lot of experience across a lot of different organizations, why do you think it is that software engineers in general seem to have such a hard time arriving at methodologies for developing software? I mean, I myself have experienced multiple different organizations. Every time I go into an organization there's a huge debate as to how things get done. Lots of things are clearly wrong, and it seems to be very, very difficult to arrive at a good way of getting things done. And it seems to be something to do with the culture. Just curious to know what your opinions are on that? IVAR JACOBSON: So, did he have a question? IAN SPENCE: Yes. IVAR JACOBSON: Can you repeat it? IAN SPENCE: So the question was, why is it so hard to establish a method in an organization, when there's obvious problems? Why are they so hard to address? Is it just a cultural issue? Or is there other forces at play? AUDIENCE: Ya, so it's not a specific question. It's really just, I'd like to hear your general impressions, given that you've had a lot of experience across different types of organizations. IVAR JACOBSON: Ya, I can give one answer. I would ask Ian to also add to it. I think the general problem here is that we have so many different contexts. So if you, for instance, every company think they're doing something unique, successful company. If you go to banks, basically every bank thinks they know better than anyone else, the software people, how to develop software for banks. You go into the defense industry, it's the same thing. Telecommunication. And area after area, people think they have something really unique. And so basically, they drown in this, that so much context depend on thing. So what we're trying to do-- And if you read our book, you will see in the front page we quote Michelangelo, Michelangelo. Michelangelo is right pronunciation, sorry for that. When he did "David," he got the big block of marble. And he could see David inside that block of marble. No one else saw it. But he saw it. And the thing he had to do was to shape away the things that were not part of David. That's what he saw in the job. And we have paraphrased that and said that we have found the essence of methods. And among the mess of methods-- And we take away the things that are not essential, that are not universal, for all methods. Whereas for people out there, they see that we have a particular problem, and we have no description or foundation of what software engineering is. They have a method. They have another method. They have a third one. And they try to do the best of their knowledge having this basis where you can stand on top of. And then add the things that you think are great will, of course, make it easier. IAN SPENCE: And just to add to that, the single biggest reason for this is, people don't break the practices down. So they think they've gotta change the whole method. And then they have wars about it. AUDIENCE: Yes. IAN SPENCE: And they try and change the things they don't need changing. Because if I want to do this, then I have to do the others. And then it just churns. They never give people time to mature or experience. And they don't allow the people on the ground to define these things. IVAR JACOBSON: And defining the method is so much more complex than describing singular practices. Because every method is the soup of these practices. And that makes it complicated. And also when you create a soup, you want to add a little here, and you want to make it a little unique for you. So we are to tailor, get the joke. And you know, I was in the Sistine Chapel in Rome, and Michelangelo, he made the painting in the ceiling. And it was damaged some years ago. It was damaged. So they have to fix that damage. They couldn't ask anybody to do it. So they asked El Greco. And he was-- Well somebody said to El Greco, you know, you are maybe the most prominent painter now alive. And you see that damage up there? Can you please help us to fix it? Repair it? El Greco looked up. And he took a step backwards and said, oh, no, no. I can't do that. But I can repaint the whole thing. And that is very much what the people who create methods want to do even if I have a good basis to start from. And we need to get away from it. And that is part of what we do. AUDIENCE: So you've built basically a meta language that lets people that speak different methodologies to talk to each other. And you've built a way to measure how good they are at what they do. Do I need to improve in the way I gather requirements, or in the way I address the programmer requirements, not just gathering. What I think it's lacking from this model, as far as I see it, is actually the cultural aspect and the environment where these projects operate. You're gathering a lot of data about how good they are, but not in which area they are good. Am I working on something that is like I live in aeronautic industry, like building the software for an airplane? Or am I working in a place where I can take much more risk? And the other side also, the cultural things like, I'm working in a society where I can address authority easily or not. And I wonder why you are not gathering this kind of data, because it will be extremely useful for a community, the software industry itself, to know if I am to address this particular aspect, and I am in this particular context. Then this practice is gonna be the best across all the things that are ready and available. And once you have the data, it's easy to do the math to figure this out automatically. But there is no one that's gathering this data on a very large scale. IVAR JACOBSON: OK, so I'll let Ian summarize your question. IAN SPENCE: Oh, I'll take one. IVAR JACOBSON: He is the native English speaking person. I am speaking Swinglish, so. IAN SPENCE: The question was about the-- We've defined the kernel, and a language for defining practices. And that's good, but are we collecting information about the context in which the practices would work? And some of the cultural aspects around things? So we have a team as one of the elements in the kernel. So we can collect practices around there and stuff. But is anyone collecting data that would help you understand when it is that certain practices work, and when it is that certain practices would be wanting? IVAR JACOBSON: That's a very good question, I'll let Ian answer. IAN SPENCE: The simple answer is as part of the SEMAT community and the research, we hope that by establishing some common ground people will do this research. Alright, and they will gather this kind of data. And hopefully that will start to happen, and this practices get out. These people need to say in which circumstances these things are applicable. So we're hoping to build that. And I believe some of the researchers are looking, at least in a small way, but there's nothing significant happening. But I would love to see it happen, personally. And within the remit of the community, to look at those sorts of things. But as an industry we have a total sparsity of that kind of information. IVAR JACOBSON: And I would like to add to it, too. And as you know, SEMAT stands for Software Engineering Method And Theory. We have always believed from the start of these that we need to get the academic community to be part of it, and not be dominant. I described it that this work needs to be driven by the industry, formulated by [INAUDIBLE]. So I felt we need to have a general theory in software engineering as such, underneath whatever we do. And there is quite a large group of people now working on a general theory in software engineering. They have meetings every year and present papers. And where we'll be a special issue in some magazine, I don't remember which it is, about just the general feel in software engineering. What they expect to be able to do is to predict what happens if you have this situation, and you remove this practice, we have another practice. Will it be better? Will it be worse? And similar questions, prediction, which is something we can only do in a few cases right now. So maybe academics behind it, we can get better education, we can get at schools so we actually teach something of use at the universities. They do method, but maybe could be more useful what to teach. And also the research, less than 1% of all research in software engineering is ever useful. That is too, too low number because they really don't know what to hunt for. AUDIENCE: Can you share some experience about application of the methods in a context for geographically distributed teams? IVAR JACOBSON: So, yes I'll let Ivan respond to that question. IAN SPENCE: Yes, the ideas in the kernel , certainly the one that we had in RGI, have been used in very large and geographically distributed projects, and ones with outsourcing. And by having that common ground, and being able to communicate, that help brings the parties together. But also you can understand which practices are being done in each location, which practices need to be the same across all the people, and where you can have the variance. So one of our big adopters is a company called Munich Re and they are all over the world. And they've had to establish some practices that everyone shares because they are part of Munich Re. . But they don't-- They leave holes in this set up for all of those different areas to go their own way. So it can certainly help bring people together and understand what the interfaces are. Which bits of the kernel are they responsible for? Which bits of the kernel are we sharing? Which things are you doing? We've seen that quite a lot. That answers your question at all? AUDIENCE: OK, hi. The thing that interests me is, you started this talk trying to address the issue where up to point trying to address the issue of a person changing an environment, and switching a team, or something like that. So in two teams that use different methodologies, or there. So I'm interested in, have you measured, or do you have some useful data about how does your platform help people change environments and adjust to a new environment better? Because if I understood correctly, that's one of the big issues you're trying to address. And if not, do you have plans to gather some really measurable data about that, and run some experiments? Thank you. IVAR JACOBSON: So this is really where Ian can, based on his experience in working with big clients, Munich Re, KPN and [? Friitzo and ?] so on. We also have a similar experience in China, where several big companies are working with Essence as a platform. IAN SPENCE: And again, we haven't really reached enough people to be able to get good enough statistical evidence where we've used it in large companies, with district communities, or companies bringing in different outsourcers. And having the common ground certainly allows them all to get up to speed more quickly then they've done before. That measure is a qualitative measure. And that's what they've said. Rather than having that should be in a situation to do controlled experiments, or measure those timelines. But we have seen teams coming together, and becoming effective, and then getting on the same page with each other more quickly than we've seen previously. But it's anecdotal, rather than measured information. MALE SPEAKER: Any last question? OK, lets thank the speakers again. IVAR JACOBSON: Thank you. Thank you. [MUSIC PLAYING]