Dr Sven Ehlert presents on Scrum - the incremental agile software development framework - and explains how it will be used in Ethereum's development.

Transcript

[00:13] SPEAKER_00: Hi everybody, I'm Sven. As I said, I joined the team three weeks ago and this is a talk I'm giving about some methods. It's not about Ethereum at all, just some way to organize ways how we can interact together. A thing that you can use and I've used it in my previous company very successfully and I just want to introduce you to a little bit to it. I think a lot of you have already heard about Scrum and all these buzzwords that come around with this Kanban, extreme programming, test driven development, all this stuff that is all the way. We talk about one principle which is called Agile software development. It all boils down to the term Agile and that's why.

So I want to talk first a little bit about what Agile is. If you know in old days, in very old days, how projects were made in software development. I think you heard about the Waterfall model, how to develop software. It's like, so you specify something, you implement it, you integrate it, you test it later, you maintain it. Water falling down. And this is the way projects are being built. But this has a lot of problems. So in an area already 13 years ago, some very cool guys came together and said, came together in Utah, 17 programmers and said the Waterfall model has some problems to develop software and we want to think about ways how to improve the process of doing software. And this is known as the Agile Manifesto, which is already 13 years old.

The knowledge that they gave us is about four basic principles in software development. Some values that you have to do is that we value most people and because we're all developers and we should work together, we value working software. Working software is much more important, for example than documentation or having the latest features. Working software is a value for that. We value customer collaboration. That is our software lives in a place where for somebody and that's our customer and we want to work with the customer to use the software. And I think one of my favorite is responding to change in software development. There's a lot of times when it doesn't work after plan. So that's where the Agile Manifesto actually gets its name from. We welcome changes no matter when there's always changes.

So the Agile world is just an umbrella which there's a lot of technologies that you can use. Scrum is one, extreme programming is one, feature driven development. There's all different processes which you can use to do Agile software development. And it all boils down that you do something iterative and incremental. So like when you do something you always do it, always in the same round and you just add a little value all the time.

Another way to put this is this sentence. What is Agile? It's early delivery of business value. And I really like the sentence. The sentence, while it is about software development, it has nothing to do with software. In the sentence, it has early, so we want to be fast. It has delivery, get it out and it has increased something and that is the value. But there's nothing written about software.

And there's another way, put that behind that it's less bureaucracy, mainly because it comes from the Waterfall model. But I think here in this project it's a little bit different. I think our roots are not from the Waterfall model, but more like in an open source project. And I think, you know, a lot of open source projects which have amazing features, they do something really great, but in the end nothing works. I have created this great, great library which shows 200 different images. It can display 200 different images. But can it zoom? Yeah, it can zoom into my image only when you have installed something different. And that's the thing, the software, it has some good features, but it does not give the impression that it really works. And that even though we have intelligent people doing it and passionate developers and the thing what I like there is we are all nerds.

And I feel a little bit heretic by telling that as nerds we like to develop software, we like to add features, we like to do something great there. But when you think about it, nobody actually wants software. We want software, we like software. But the people out there, they don't care about the software, they just care about something that they get done. Think about, do you really care about the details of your tax income stuff? Nobody cares about that. So what we care about our software, nobody out there cares about the software. So the goal as a good developer is just to develop enough software to solve something.

And I've rewritten this sentence a little bit. What Agile is, what fits better to an open source project is like we deliver early delivery of business value but we need some bureaucracy because mostly open source project, there's not really so much bureaucracy, just some bureaucracy to make it work.

So that's about Agile. Now about Scrum. I'm just talking about Scrum because I've used Scrum in my old company. It worked very well. Before I was in the company, we didn't use any of those. We used the classical model and it was a failure. So that's why I think it's quite a good thing to use.

This is an overview of how Scrum works. Normally, what you see is, okay, we have a great goal. We want to build a huge thing. We have a huge group and we have some time to build it. That is the basic premises. We want to build something great with Ethereum. We have a huge group here and we have time to build it. That's one way to do it. The other way is, no, don't do it this way. Split everything up. Don't try to build everything at once.

And splitting everything up means, first I split up my product. What is Ethereum? What is the project? I split it up into very small parts. This is called user stories. And all these stories they make up my backlog. My backlog is actually my task list, what I want to achieve. If I have done my full task log, my project is done. I order my backlog and say, what is the most important stuff I have on my task list there? And these, they create the most value. They go up to the top and there's other stuff which are nice to have, but they go down.

Second, I split up my organization. We actually do that. We have teams which are in different places. Which is good. That makes sense.

And the third part, we split the time. Instead of saying, okay, we have one delivery in whatever months, we have many deliveries every two weeks, every three weeks. That's called a Scrum sprint. And in each of these sprints, we deliver something.

If every team just delivers something, that is only one part of the equation. In the end, you have to build it all together and reintegrate it all together into something. And that's the last part. We take all the small parts, put it all together and see how they work. So we have, in every fixed moment, we have something new, always a little incremental, and all that. During this time, we optimize the process after one round, after the first sprint, we look what is gone, what is good, and after segment, we look what is good and we optimize it. There are some other features about Scrum. It's about the standard meetings. It is about the Scrum board. I'll come to that later.

What is the structure in a Scrum project? The important person there is this product owner. Normally the product owner is the boss. Here it has a different name and he's the one who's in charge. He's the one who is in control of the product. But his role is to talk not only to the development team, but also to the stakeholders. And that is the really important part of Scrum. It's like you talk to your stakeholders and who's the stakeholders here? That is what Stefan already told a little bit out. Who is the one for whom we are building that? The stakeholders is of course us we are building at. But there's the people who invested in the Ether sale, they're also stakeholders. There's the developers who want to build something greater and there's the users in the end. And with them you have to build a communication. That's the role of the product owner.

He decides, okay, in communication and looking in my backlog, the stuff that I want to do, what should we build next? The team. The team gets empowered and the team says, okay, you want to have this build? We decide what we want to build. So instead of the boss saying, okay, you built everything like this. I declare that the team says, okay, we think we can build some of those, we can build a little bit of these, we can build a little bit of these. And we commit to that. So that is, we take from the Scrum backlog, which are all the tasks. We have some small tasks to the Sprint backlog. The Sprint is something we do in one or two, three weeks.

And the last role we have here is a Scrum master. He's part of the team or can be an external guy who just is like doing, he's helping the process going on.

How does a typical sprint look like? Normally you decide, okay, a sprint is something which will last two weeks or three weeks. And at the beginning of the sprint, the project owner, he says, okay, I have my big backlog. This is all the tasks I need to do. My user stories. I think about what should be done in these two weeks. That is the sprint planning. I decide, okay, this is really something I want to do. The team decides, yes, boss, we can do that. We can take this part of it, we can take that part of it. Let's do that. And the team starts building and the team starts building. Only this part. Normally there's not much change in it. You just commit to this thing and we just, the team starts building it.

What you do every morning or at fixed part in time, you have a stand up meeting. With the stand up meeting, everybody gets updated on the progress. Are we all on the same track? Are we still doing the right thing? Are there problems when you do that? You can continue with the work during the sprint, during the three weeks, the product owner, he thinks he looks about okay, are we doing good progress. Have features changed? Is there feedback coming in that says, okay, maybe we need to change something? That is, he refines the backlog, he adds something or says, okay, these priorities have changed or something gets lower.

And in the end, after the sprint is done, we make sure that we have done everything and then we show it. At the end of each sprint, you deliver something. You don't deliver anything big, you just deliver something. And this something at the end of each sprint, it works. That's the goal of it because you get it out, you have some working improvement and you can show it. You can show it to developers, you can show it to users and you can show it to the other people. That's what we have achieved right now. And this is doing is going round and round.

Scrum is a little bit complex at first and there's some ways to learn it, but it's just like learning skiing. And there's an Asian way of doing it, it's called Shuhari. And it basically means, oh, this is all very complicated. In the beginning you just do something. What you have to say, okay, I know I have to do my sprint dancing, I know I have to do my stand up meeting, I'll do that. When you get more comfortable, you adapt the rules, say, okay, this does not really work for us and this we need to change because Agile is about the people, it's not about the process. You adapt it to your own needs. And when you are master of it, you say, forget about the rules, we have found our way to doing it. We don't want anybody in the team saying, hey, this has to be like this. This is the way it's been done, no other way. So this is one way of delivering software projects.

Why does this work? Normally in big projects it's all about risk management. And I think Ethereum is a really, really big project. When you say, I want to build the Ethereum car or something really, really big, you have, of course, a big risk. The risk is that it will fail. And that's a big bang project. Get it out, do a big bang. See that? Everybody likes it. Or maybe not everybody likes it. That's the thing.

Some smart people have looked into it for a long time and why are there so many dudes project failure? And there's extensive research showing that the most important fact when huge projects fail is complexity and size. That is something that is really the reason why the huge projects fail. So the goal must be to get both down, complexity and size.

You can ask, what is the successful project? Then there's the three ways of looking into it. The scope. Do we have all the features that we want? Do we have all this cool stuff that we wanted to build in? Is it there? Yeah, that's something. Are we on time? Can we manage our deadline? And are we on budget? Do we do everything with the money?

Do you have a successful project if you meet all this kind of. It is important, but the real important stuff is that you get happy stakeholders. If you get the scope, if you get the schedule and the budget and you have happy stakeholders, then you have a successful project, you can have the scope, the budget, and the time, the schedule, and you have unhappy stakeholders, then everything is for naught. And even if you miss on all the other deadlines, if you don't have all the features, if you just have some, and if you're late and if it costs differently than you thought, but the people are happy that are using it, then you still have a successful project.

And the goal there is to do different ways. In a big bang project, you say, I have a plan. I know where I want to go. I shoot in that direction, and that's where I want to go. And everything follow there. The problem is something might change if you shoot in this direction. It will change. You might miss your target line.

Agile, on the other hand, is different. It's like a homing missile. It's saying, I'm smart. I know that something will go wrong. I know that I don't know everything right now, but I will adapt. I always will adapt and do something in the right direction. Therefore, I minimize the risk. Because if I just push everything out, saying, this is my big bang, I have a long time where really nothing is shown. You just develop. You do something, you present it. You present it to your users, you present it to your developers, and in the end, maybe they don't like it too bad.

In an Agile environment, you say, okay, I deliver value all the time, a little bit. In the beginning, users will not be happy, but they will be happy each time when you do something like that.

How we do that is to, is how you change. You achieve that by changing also the way you organize your structure. We have a lot of different features that we want to achieve, like the cool technologies that need to be built. For example, there's Whisper, there's Swarm, there's clients, each of them, and you can of course say, okay, I'm building Swarm, and I do it in the end, here's Swarm. Let's have it. That means you create a lot of value at once, but it needs a lot of time.

You can also change that and say, okay, we do a little bit of Swarm, we do a little bit of this, we do a little bit of client stuff, for example, and we create a little bit of warp value all the time. In other words, if you want to build a car, don't have someone with tires, don't have someone build the chassis, create first a skateboard and then move the skateboard into something else so you get satisfaction in a different way. When you build all the parts out separately, you can only have satisfaction at the end. When you do it by changing stuff, you get always a little better smile on the customer's face.

Okay, we already have cross functional teams. Okay. That is, I think, sorry, good. The message here is really do not build a lot of stuff. Build valuable stuff. That's actually why I used this presentation from Henrik Kniberg. He's a very cool Agile coach. I could have created my own presentation and do all this stuff, but I thought, well, he does already this good presentation. I adapt it for my needs and I think I create value by just telling you that. And instead I build the other stuff that I have to do.

So Scrum is a lot about planning. And one key feature about Scrum or Agile is anything is you empower people. Empowerment means let people ask, why? When someone tells you, okay, we need a bridge, you don't say, yes, let build that bridge. You always think at first, why do we need this bridge? Okay, we want to go to the other side. And then, what are the options that you empower? This way you empower your team and you get better options.

By asking your team, I would even say you can go another step forward and say, do we need this bridge right now or can we have it later? Because it's a double sided sword of one side. You say, okay, give me your options, tell me what you think. You always get a lot of stuff. Oh yeah, let's do this bridge and have some very cool stuff on it. And also we need this interface to add more to it there you need a strong voice of reason that says YAGNI. YAGNI is a famous term in Scrum world. It means you ain't gonna need it. And that's something someone always has to put. Do we really need that?

Now Scrum is also a lot about, it's about change. When you have a good plan, you say, okay, I want this feature and it has to be ready in four weeks. And I want ABC features inside there. You have a good plan, but most of the time you know it's going to fail. Or if you don't know it's going to fail, well, normally, then you're late.

Scrum, on the other hand, says, okay, we will always deliver something in four weeks or in two weeks, we will deliver something of value. We deliver something, think what is important, what brings us forward. While we deliver that, we might see that we're not as fast as we think we are, but we still deliver something. What we get out where people look at it and we get feedback. So in the end of these four weeks, we might not get the original features that we wanted, but we get something of value, maybe different features.

And that's what you get with Scrum when you plan, when you say, okay, these are my features, this is something that I've done that is in progress. And in the end of the sprint, yes, you see everything that we have done, you can in the end count. You can count for every sprint. Well, I got four features done this week. Next week I got seven features done. The week afterwards, I get zero features done. Something went wrong. And when you have that, you can predict into the future and say, okay, if I want to have this cool project, if I want to do all this stuff, I can give good measurements, how long it will take.

The last part, which I think is the most important about Scrum, is shorten the feedback loop. Because think about it again. The Agile Manifesto says, talk to the customer, don't do something above the customer. You want to have feedback when you want to succeed. Normally, I would say the fastest learner wins. Not the most intelligent, but the one who gets things right from the world because you do something for yourself. But the world might be different. You should strive to get feedback as fast as possible. Feedback you get from the stakeholders.

And how do you get it? You release. Often you do it like in, the shorter terms, the better for that. It's very important that you close the feedback loop. That is what Stefan was talking about. We get the feedback, what people really need. As I got from your talk right now, it seems like right now our target is developers to build dapps, so we should listen to them. What do you need? What do you really need to build successful dapps? And we should minimize the feedback loop. How does the feedback from the developers come back to us and learn from that?

In a technical point of view, you want to have releases really, really easy. Normally when you have huge features and a long time has passed. A release is a catastrophe. You say, okay, in one week we release something and you know it will not work. Something is not integrated, the testing was not really done and it's normally it's a catastrophe. So the goal is to say, okay, I automate the process so much that I can release often in small increments, but I get something right so that I can really say, okay, next week I need some working prototype, I can get it. This is what I'm actually working on. So I'm talking about that tomorrow and some last parts of it.

Just about best practices. If you are in a team and you want to get feedback, the best way is face to face communication. It's just the easiest way. So that's why the stand up meetings are so popular. You get these things out very fast.

And what also belongs to Scrum is at the end of each sprint say we did something, we delivered something and we learn. You do a postmortem, introspective or however you want to call it, you show what you have done and you say, okay, we have done that, we have learned that and you spread the word so that the other people learn from that. It's not about blame saying, okay, yeah, this didn't work, this didn't work. Just about, okay, we want to learn something and get the next round better.

On a side note, this is very common. It's something that is also very popular in the lean startup world, which is actually the same principle. If I want to build something successful, I start with an idea and I start with, with doing some prototypes and then I built a minimal viable prototype. That's something that's just the basic feature to get people hooked. If I got that, I let it out to some users, see what they think. I do measurement, I do variations of the measurements. So this part of users gets this feature, this part of users gets that feature which comes better. And so I have a feedback circle and you increment, you always increment and you always get feedback. And if you get feedback, you learn.

So that's about for Scrum. Scrum is not for everyone, that's for sure. If you're a product owner, you have both sides. The development team and the product team are owner. They have to have to like it, otherwise it will not work. The product owner will give a little of control about this vision because the team gets empowered. If the product owner says, okay, I want this feature and the team says, oh, can I deliver it? Whoa. Or if user feedback says, oh, this new cool feature is really nice, but actually people have problems installing the stuff, for example. Then we should focus on that, get it back. So the product now gets a lot of nasty questions and he has to talk a lot to the stakeholders.

Developers, they also give up something which is quite common with developers. Hey, this is my project. This is my code. I'm the hero of this part of the code. I'm the one there. No, it's not about this anymore. The team is responsible for everything. So you must be willing to share, to talk to others and be partnered with them. Also, you get a lot more responsibility as a developer. If the sprint is not going ready, it's not also what the boss saying, okay, it's not ready. Just do something. The team takes responsibility to make this sprint happen.

Basically, for a lot of people, it means you get out of a comfort zone. You do something what is maybe not what you really like. And this can be a draw, it can be bad or it can be good.

But on the other side, you get a lot. As a product owner, you get a team where you can depend on because the team is empowered. And you also get reliable measurements. You know, okay, if you want to go this way, I know in this time frame, I can do it.

As a developer, you get decisions that count because you're part of the decision process. You get less death march. I don't think we had that before, but I think it might come when we need some features done and you get story points. Yeah, everybody likes story points. Story points. And when you do something, when you finish something, you get a story point for that everything belongs and you learn a lot of new stuff.

So wrapping it up from this presentation, I think this is the three most important stuff in managing projects. The thing is the first sentence, which I really like. Early delivery of business value. So everybody should know what business value is so that we are going in the right direction. Early in delivery means get it out fast. Nobody wants software. Sorry, I'm heretic by talking like this, but just do the minimal way of doing the software, what is really necessary to solve something, and the fastest learner wins.

If you want to get started with Scrum, it's best to get some really a pro into it. A Scrum master who knows about it can make the Scrum experience fun and just do two sprints with him. That's the easiest way to get people on board because people need to. You need to be willing to do that. I'm not telling you Scrum is the good way of doing it. I just think it is a good way for success. It makes life easier. Thank you.