 This is me in my early days, we didn't have colors. Bit proud of the pictures. I was early in embracing computers. Those days it was early, I was like 14 or so. So I was one of the local experts. So I was called in to do, and actually all of it, I'm 17, but I was called into the training to local people. So actually my dad was called in, but he's like the state I am in now. Now I can't code anymore. So I will be blunt with you. I haven't been coding for 10 years. A little bit embarrassed, I hope I will be able to do it again because I miss it, I enjoyed it. I met a good friend, my stage producer, actually we turned out to be colleagues for a couple of years ago, I didn't notice. So excited about that. But anyways, so I like this, why I bring up this picture. At one time I was able to code. That was a pretty good idea. Yes it is. I was actually able to code in assembly also. I was pretty good. But I'm not anymore, so I have to rely on people like you to do this. But I'm proud of being able to talk to people like you. I'm very proud of being able to give this talk. Because this is about, in my mind, it's one of the, I feel not saying the most, but one of the most important aspects of agile is the engineering practices. And I remember, it kind of started. Some people argue that agile has been around actually forever. Since the 50s or 60s when we started getting a computer in our hand, it was natural to develop software in an iterative manner, evolutionary manner. And then in the 90s, some crazy people thought we could describe how it should be done. Yeah, when I first read the book, it made so much sense. Because I think it was kind of a break in the late 90s. Because there was this movement in the object-oriented community in the 80s and 70s. It was quite strong, but it was kind of internal. And then at the end of the 90s, Kent back wrote this book, which really hit and embraced a much larger community. So in my mind, how I have experiences, that's when agile really started. Then we started to use the term and more people embraced it. So it was important. And to me, as like starting early, it made so much sense. Instead of I was being conditioned in traditional, this American consulting company, we were conditioned to believe that we will wait for a sophisticated design to come and we will make it. And then someone will test it. And it will take forever, a lot of paper and a lot of confusion, a lot of stress in the end because we always tend to miss. Or for some reason, they didn't really want what they were described to us. That's why I like this engineering practice, which puts an emphasis on stuff that works. And also I put up these pictures because the value of these kind of things and how the agile community learned from each other, these are the kind of events and all the, like the community, we love to share our experiences, our opinions, we challenge each other. It's a very vibrant way of learning, I feel. So this is from, I was the industry chair at XP 2010, which was, I'm very proud of that also, but I was just a sample of how powerful these events are. So I'm very happy for you that you started doing this here now. I think you had similar events, but this is branded agile Indians and there's so many people here. But anyways, this is, this is visible at all. I will go into these things when we go. So when I put this together, I try to use more common terms among IT people. So in the agile community, we tend to use some words and we take for granted that people know those words. So I bolded down to the, the essence is we code and we test and deliver. And those terms, they are understood outside our community also. Traditional IT people, they will understand those words. So they're not very sophisticated, but I like the simplicity, the simplest thing. So I'll talk about those aspects and I'll talk a little bit about some supporting practices also, collaboration and process support. But the emphasis is on the actual thing. And I was pondering how to do this and when I proposed this first time for agile 2011, Salt Lake City, I gave some feedback and I kind of like, so I deliberately start with testing because that was so kind of core to, I think that's what Kent Beck was pushing on, testing and development. But this kind of aspect is from, yeah, this is, yeah, let's do the next one just so we get the context. This is called different things in the community. You sometimes you'll hear people calling about, talking about acceptance testing. Kent Beck was very strict about, there's only two types of testing, there's acceptance testing and unit testing. And I kind of like that, it was kind of refreshing. I mean, used to being a consultant, we had seven types of testing, or eight, 10. And in one way, that's kind of true. But I like this, it's kind of refreshing. There's only two kinds of testing. There's a test where you accept the system and there's a test where you as a developer guide responsibly, you take responsibility for testing what you do. So in one sense, it makes sense because then there are other people testing, acceptance testing that. So, and then, I feel I need to just to give some perspective into this. When we talk outside our community, we will talk to people, we talk to the organization that have a test department or QA department. So I think it makes sense to relate to that. Like from a dogmatic view, there are still, I mean, there's only two types of testing, the acceptance testing and unit testing. And the agile community has been a lot of emphasis on supporting the acceptance testing part or the functional testing part. It's kind of what I realized is that if you say functional testing, it causes less confusion. If you say acceptance testing, it's kind of very formal. They're kind of still a buy into that, but it's kind of, that's usually perceived as the organization formal commitment to your deliverable. So they usually, sometimes they might even have an external agency doing that just to make it really formal. Because then they sign off and they take on the risk or responsibility. But in this sense, I like to say, just be simple about it, just two forms of testing, acceptance testing or unit testing. And there might be, in real life, you have to juggle this. So I was in the IRS and then we had to call this, I think we called it this developers teams functional testing and this was still the QA doing the formal acceptance testing. But if you really, I think the aim, I think we should strive to go towards to achieve is we want also testing to be embraced in an agile manner. And I've seen it being used fairly successfully. We have a, last year I was working for Citrix Online and then we have the QA people, they were formally embedded into the scrum teams. And I liked that. So then they have the same stake as the developers. But that doesn't always happen, unfortunately. So they were actually driving the test almost too much because they made the developers lazy. Because there is the developers, I think they should still feel some kind of responsibility in the testing. So there's a, you should find out how to play that. But anyways, I'm talking about the background. So the scope or the presentation, this is about functional acceptance testing. BDD is a popular term, behavior-driven development. So if there's a talk about that during this conference, I would recommend that. It's kind of, so I might go deeper into this. The way just to set the expectations, I will only give some smells or taste bites of these things. But hopefully enough. So if you want to go to details, I will encourage you to go into talks or tutorials that covers these things. Pretty sure there is. Usually there's a lot of enthusiasm thinking the testing. There's always people engaged about that. And listen to those who are extremely passionate about it because it's good. So usually, this is the way we do it. This is the ideology, but I like it to try to work this way. Hope it's not mine. But to be first to describe the behavior and scenarios, and that description should ideally be executable. That's the behavior-driven design kind of ideology. So you describe it in a way that you can execute it, like a script or a test type of program that you can run the program against. So then, like the book says, you run the test, and of course it fails the first time because you haven't made anything. But you should do that. It's kind of, I kind of deliberate to do that. Test it before I have anything. So just make sure that at least that test works. It should fail even if you don't have anything. If you pass, if you don't have anything, then the test is not really good. And then you fix things. So this is kind of the coding party, the code. Fix here means, this is at the feature level or the function level. So you have your test, you run the test, it fails. You fix things, find out how to fix things. And then you actually run the test again. So this is say, first time is the first real one. Then you just do this in cycle until all tests pass. And you should, all tests should pass. If they don't pass, you're delivering something that doesn't work. So what you could do, you could adopt the test. Like if you say, this thing is not really that important. But then that's a function requirement. Then you should adopt your test to accommodate that. Instead of this thing, bugs, or I get red lights and then accept that. You never accept a red light, the dogmatic agile view. You change the test so they can trust the test. You really won't. And the test should be, you probably know that, but the test should be fully automatic. You shouldn't require any manual inspection. Because if they do, then you lose the effectiveness. I know there are some shades of gray hair or nuances, but I like to take that view. Try to get that ambition. They have your executable test, run them against the thing, and they should be automatic. They should make the decision on whether the tests and the pass are not, so you can see it. Then there is the debate in the community, especially when agile people meet the test community. But it isn't always possible to fully automatically test everything. And that's actually true. But still I like for us to aim to do as far as you can. There are some things that might be extremely challenging to test, but don't accept it upfront. Try, maybe there are ways that you can try. Because there are people who have actually, I think Google has made test programs that can assess some quality measure or the usability automatically. And I think there are people doing amazing things. I thought you had to have a person to be able to do that. But they can give you some kind of things. So there's a lot of things happening. So this is just an example of how we have done things. This is an electronic scrum tool. And most of these tools provide a way of describing tests. And we actually did this, not throughout, but we tried to, in the beginning, even I thought that would sound a bit. Should we do that? We know the story, we know what we're supposed to do. But it kind of makes it very disciplined if you have those things. And these tools they usually provide ways of tracking how the test passes. So we can get the precise measure of progress. So you see, I prepared this for Agile 2011. So here you see, I tried to make this a proper user story format. And then they have some tests that could be, because test is your way of assessing how you can save these stories done. Yeah, unlike in this case, they failed the first time because I haven't done it yet. Okay. So here's a set of other tools that I've heard of. When I mentioned tools, just be, I know there are, I remember last time, the vendors are pretty excited to see the tools and maybe others who have been involved in developing them. I haven't done an extensive research. So these are just tools that I have been exposed to, that I've seen. There might be other tools out there. But these are, and no vendors is paying me anything. I'm not asking them to do that. So there might be other tools. So these are, but I believe there's so much, some traction around these tools. Cucumber is getting a lot of traction these days. I'm kind of proud of that because it's a fellow Norwegian who's pushing it. It's one of those, their ambition is to be a really BDD behavior-driven development tool where you describe what you do in English. You describe the test in English and then you actually execute that test. And there are mechanisms for doing that. I feel like showing you actually it's, I was, last time I did a demo, it takes a little more longer time and I have to fix my laptop so I don't have a Ruby environment here. But just, I haven't coded for 10 years or so. I was able to make a cucumber test. So it's that easy. And it's kind of cool. I don't know if you can read this. You describe what you do. There is some, you're supposed to follow the proper story format, normalize story format. And if you do that, and you use, so here's the story and you describe a scenario also in a proper structural way. And then cucumber can parse that and use that to execute. And the way it does it is, so we have the scenarios. The scenarios are say test cases for the story. And then they will just translate the numbers or the parameters in the story. And you have ways. This is still, it's written in Ruby, but it's Ruby's, it's, I don't know Ruby, but I could, I was able to do this. So like you instantiate the thing you want to test. You do something with the thing you want to test. And that's also how you do unit tests. So we try to do this, cucumber wants you to do it this way. And you run it and it fails because you haven't made the calculator. Then you make the calculator and you started to get, you run it again and then you see some yellow because these haven't been done yet. And then you do it like, like the pictures if you remember the cycle, you run it until it passes. So my point of this, I wanted to show you cucumber as an example of how to do this. There are other tools. RSpec I think was the predecessor to cucumber. I think there's been a lot of things going on in this field. Fitness, I was hoping to demo that, but I, how many have heard of fitness? Oh, okay, but I don't need a demo. Half the room, that's good because that was very popular. I like fitness a lot. It's just for those who haven't seen it. It's kind of, I think the metaphor there is example driven tests. You write something based on how you expect it to look like. And usually by tables. And then here you see what you typically do. It's totally web-based. So you just hit the test button. Based on that table, this table is a test. And then you will get the red on the 33. You get the red there because that's wrong. And then you can act on that. And here's the test data that was wrong, not the goal. And this is the architecture behind fitness. I kind of want to show this just to get you a feel for, this is typically how you make these kind of tests. So you have, in the community, I think this is actually what the profession test is called. It's the systematic test. Now you have your test cases. And then you have this, they call it pictures. You have this glue. Like in Cucumber, they have these step definitions, which is the glue from the system under test to the test framework and the acceptance test. So it's fairly straightforward. The challenge is typically like the guys who's working on this to making the pictures thin enough. Because if you get complexity in the picture, you risk adding something that can break. So that needs to be really thin. This is just something you want to access your code to be able to test. Because it's tempting to be very sophisticated about the picture. Okay, so to coding. And I boxed in our community, we usually talk about test driven development. So this is the kind of test that is close to the code. The kind of test that was scrubbing earlier. The goal is to actually, actually our wish, our dream is that we will have the stakeholders writing those tests. And I think you should try for that. Try to challenge your stakeholders to write those tests. So then it's very important that the test framework allows you to do that, but it is not too complex. So like having Cucumber write the step definition, it's probably a good thing. But I have to admit, if you had a really hard time making that happen, it's really challenging. So usually we end up doing it with developers. But try to avoid it, but if you have to, at least what you could do is they give them at least the numbers and the description and you try to be extremely accurate about getting that down. So you don't add any, be very careful of interpretation. If you disagree, talk to them, don't change it. Have a conversation with them to make sure that you understand what it is. Okay, so about coding. These are some practices that I believe are important. Refactoring, source code control, peer programming. So we'll go through some of them. You see, the loop is almost the same and that's intentional. It's supposed to be the same. There are some things that you think about when coding when that you don't really think about or think less of in the acceptance testing. So you code your test and that's actually, how many of you have you, are you used to J unit? Pretty, quite a few. How about M unit? If you see sharp, test NG? Some there. So you seem to be fairly exposed to it. So you know, not the drill. But I still want to stress this because even in Eclipse I think and especially Visual Studio, Visual Studio has a wizard that creates J unit or N unit. I think it creates tests based on your classes. It does? Okay. You don't want to go that route? No, you don't want to. That's the point. Because I will challenge you try not to fall for that temptation. Write the test first and then write the classes. That's the whole idea. You want to write the test first and it is not that hard. You don't need a wizard to make that. And the only thing the wizard does is write stubs. I think you should be very careful at least because the whole mentality, because the refreshing view here is that you write the test first and you have never done that. Try it. If you have never done it, it's very challenging because you probably have a design in your head or whatever you want to call it. But if you do the test first, you're so much more focused. You just do the simplest thing. If you do the other way, you might over design. It's fairly easy. So the difference here between the other thing is this guy, and I would like to stress that. How many of you re-factor on a regular basis? Oh, good. This is nice. You're better than the Americans. I was in Salt Lake City. I was like doing 20% of the room. So I continue that for those of you. I understand why it might be challenging because you get pushed to deliver a feature and people tend to only care about features. But it's like Rebecca told us this morning. It's our professional responsibility in my mind. It's our professional responsibility to re-factor mercilessly. It should be part of the cycle. Every sprint, we should re-factor. I know there's concept of a re-factoring sprint. I feel a bit unfortunate that it has come to bear, but it's better than nothing. So if you need a re-factoring sprint, do that. And in my mind, if you need specific stories to re-factor, to get it prioritized, do that. There are some schools that says you shouldn't have re-factor stories on the story backlog because it should be second nature. But in my mind, if it doesn't happen, by not doing it, put it there. I don't think we should be religious about that. I think we should be religious about re-factoring. I think it's so important because if not, and I have seen it, I'm pretty sure you've seen it. The cold dust rotten gets, if you don't take care of it, it will get sour. And then we submit often. In my mind, I feel we should submit as often as we can. We don't want to submit to something that breaks for others. But still, you don't want to be too careful. You will probably submit, have anyone not broken a build? You have? OK, I might want to hire you, but it will happen. I know we should be careful because you waste other people's time, but we shouldn't be. I feel at least once a day, maybe more times a day, people hold on to their stuff. It's even way too long. I have some thoughts about re-factoring or branching strategies. This is just to show you, you seem to be used to this. But I do the test first, write the test code first, and then you write the classes. And it's OK to not have any classes at all, just do it. Because it actually helps you design the class also. And their view was that, I think Kent would sit here. Type A and Ward will sit next to him. And it's supposed to be our class this way, so they both can see. And he should be able to talk to him. And it's nice. And extremely intense. And it's like a steady code review. You do it all the time. So you get this guy, he's picky. And sometimes you get out of the dynamic and work. Sometimes you do a really trivial thing. And maybe you don't need Ward or anyone else to help you with that. And it's also extremely intensive. It can be anything exhaustive. It could be by sitting next to a guy. I think one guidance I've been given is maybe six hours a day. Maybe you can do more if you have the stamina. But give yourself maybe some time. And also, I like how they do it. And I've seen this happens usually automatically. If you have a team that is well bonded, you tend to want to discuss with another guy and test the idea and get feedback. And you're probably aware that the peer program part is not only the code review, it's also a joint design. You do that to get, and it's also a way that you're less in need of documenting the design because you'll be talking to another guy and you get the clear idea in your head of how the design looks like. Unfortunately, they haven't been finding real supporting evidence. But the claim is that the quality gets much higher. And what I'm thinking of, maybe the research didn't take that in account. Because it's consistent review, so the quality is higher. So it's likely to be less rework after. And also, you have the design part and you have the teaching part or the learning part. What they found, though, is kind of interesting is that for some reason, the senior developers preferred not to have a peer. Maybe because a senior, they know the domain well, I don't know, or they used it. Whereas the juniors, they kind of liked it. But I think there are a lot of supporting claims. But the scientific evidence is not extremely strong. So that's why I'm kind of thinking, maybe be practical about it. Do go to your colleague when you think there's value in it. You might not have to do it all the time. The professional. Repactoring. You seem to be used to that. I was kind of thinking, oh, that's more of source code. I haven't slide on source code, but I thought of making a comment on, or do any of you have a good experience in branching strategies? You want to share that? And you will feel to share a strong branching strategy? We want it over the next six months. There also, every two months, you want to give it a leave. And it, parallel, you will keep on giving a small minor tweak here and a minor tweak there. So it becomes, what we typically do is create first the main trunk, which is after our first tree, which becomes, like, this is our main stuff. And whenever we maintain one minor relief, and the other is a minor trunk, and the other is a change request trunk. The change request trunk would come to the main trunk after the end of our first one month, like in after six months, first one month. Minor releases is, like, you just switch over to the branch, brand new branch, new branch, it will work completed, bring it back into the tree. So that merging happens faster. Other one comes, keeps on coming after a month and month. That's how we manage it out. OK, how does the one that comes monthly, how does that go? It's a merging which happens with file comparisons happen. And if there's a new file, it's copied as it is. I have a php out in the shower. No, no, no, it's probably. If you compare the files using a file comparing two, if it's an existing file, then move the code back in. OK, yeah, because I have to admit, I like the other, like the first one, when you go often, because that's the ideal. Yeah, you go often, very small things, you go often. But there's a larger change. I think we just put that in the entire stuff and break down. We can't put that in, so it has to go at the end of it. After all, like in a year, it's scheduled monthly release. At the end of the month, you're actually bringing it to the main branch. I think that's a, it's a typical trade-offs. Still, I like, there are people, and maybe, we also did that. So it's a typical practice. But I think what we're trying to push is that you want the trunk to be, you want the trunk to be safe, but you also want your work to be current. So these guys, you're branching off, they will have one month where they're not current with the trunk, which could be an issue, because maybe there are things in the trunk that you would like. So I think it's Henrik Neiberg, he wrote, there's a paper on it, like, and I like that recommendation, that you probably have branches, but what you could do, you can be respectful to the trunk, but then you can sync with the trunk as often as you can, ideally daily. So if they could sync with the trunk on a daily basis, then you don't mess up the trunk, and you're also current. But what you also should do is you need things back to the trunk. That should also happen so often. So you do that when you're done testing, and ideally, you test, you have continuous integration, and things work, and then you can just push it back. But I do know if you're concerned with that. But ideally, if you believe in continuous integration, you should be able to push it back to the trunk after each successful CI. If you don't trust the trunk, crazy things happen. So I really, at least we should be respectful of that. You should trust the trunk. If you don't trust the trunk, people will, in the worst case, they won't use it anymore. So you'd rail off and you have your own thing. So you have to trust the trunk. That's why I like CI, ideally, CI should be the way so you should get things, I heard people at work, they call it, although the trunk is accessible. I don't want to be in or near it. I don't want to have anything from it because people throw anything at it. Well, I think it was a bad day for him. It wasn't that bad, but if people had that perception that the trunk is accessible, it wasn't that bad. But it was, I think, someone made a mess that day, which affected him. And it wasn't really that bad, but. So anyways, here are a couple of tools. Some interesting thing is, people tend to be passionate about their ideas. And that's okay, I think I will be inclined to let people have their own ideas. But it depends, and maybe people have a super productive setup of an IDE, so maybe you want to have a standard of it. People have emotional feelings about it, and I kind of, it might be, maybe we should respect it. I don't know. But then again, they are, in my mind, as a CTO of a company that has been coding for 10 years, they seem fairly similar. They usually pick up from what they do. So Eclipse is, in my mind, pretty good. I know IntelliJ is probably better because we actually pay for it. And I know the passion seems to be stronger on IntelliJ idea than on Eclipse. I can understand it. Test framework, we talk about that. Mocking, this is kind of interesting. I was looking into what's happening. And every time I looked, something new is coming up. So when I looked, it was, Mokita was the cool thing. I'm not sure what's the cool thing now. What's the coolest thing? Mokito. What? I like Mokito. Mokito, so Mokito is the cool thing. But Mocking tools are good. I didn't talk about that, but you probably used to that. I use Mocking tools. And the good thing about several Mocking tools, you can use the one that suits you the best. And I say, you really don't have to standardize on Mocking. Because that's what you want to standardize is on the actual deliverable. And it's okay to have multiple Mocking tools. They have different, they have different serve purposes. Version control is kind of interesting. There's a debate that's been going on for a while that distributed version control is, people tend to be, again, more passionate and they love distributed version control tool than centralized version control tool. It's a very interesting debate. And I think it's a healthy debate. But people should, you don't need to be religious about it. Figure out what works with your organization. There's kind of, there's a lot of, there's more traction around Git material and those kind of tools than the other tools. So there might be, because of that traction, people will move over, I don't know. But I do want to say this thing. I hope there's no vendors here. Usually the extremely expensive source control tool tends to be very complex. They might be extremely good. Then about something really cool. All the coding testing is also cool. But I think there's so much thing happening in this field in delivery. How we make ourself operational. All the DevOps thing, I have a tremendous faith in that. It's challenging, which, yeah, we tried, sometimes we can make it happen. Sometimes it's almost impossible. So I think some of these practices is very supportive of that. And I call it delivery continuous integration. Continuous integration is a popular term. It's a term I think Kent Beck used in his book. So we sort of take it if you're granted that people know what that means. I kind of feel that it's a little bit imprecise because it has to do with more sort of integration. I think it has started to mean delivery or build continuous build. So people are doing continuous build, they say, just to be clear. I think originally it was, because these guys, they came from the small talk world. So it was about you do some things and you just test everything after there. And I think in the beginning, it wasn't even automatic. But then I think it was top works and made cruise control. And the concept of doing this automatically on a server really caught on. And now, so the concept in my mind, it has to rely on an integration server running in the background is asynchronous. It runs, you don't fire it off. It just smells when it needs to run. And they call it, I think it's sort of an official name CI server. You usually have one if you're adopted this practice. And usually it does it this way. It compile or builds, depends on the environment how it does it, but it does some things to pack it together. And usually I would strongly recommend that you do, there's so many automatic analysis tools. So you fire off some of them. You do your tests and usually, so you have the CI server who builds the same thing and then you deploy it to a test environment which usually is another environment. I have the test run. And then you compile the analysis and the test reports and make them visible. Earlier, Maven did all of this. I think Maven, they are more, they do only the compile and build. And I think that maybe that makes sense and other tools have done the other things. I'll give you a picture of the tools landscape after. And feel free to pitch in because there might have been something happening for the last years. You make the visible, I think that's extremely important. My last organization failed to do that. So and people somehow were reluctant to show these things. And I feel this is very important. I have seen it successfully done where when they started to expose the results, they cared more about improving the quality. If you don't see it, then even the scrum master or the project manager started to care. And I can't, if you get that support, it could be even stronger. Because maybe we just have to admit sometimes we might not care enough or someone needs to tell us that we think quality is important. And if you see it in your face, it helps. And then you deploy it. And then, but this is actually just part of it. And then you, so this is the core part. You message them. So it's kind of coming, it was fashion for a while. I don't know how people do today, but I like the CI tools, they usually send a mail if the bill breaks. But now you have all kinds of cool things. You have Venice, I can jump up. You have love lamps or you have, I will show you, it's for people. They use the big TVs with the face of the guy who last committed. But it was kind of, it was healthy, it wasn't too bad. So I feel strongly about using the source code also for the final thing. This is about how the process from you develop, you check in, it's in a source repository and you pull it, that's in the normal way. So it checks the build server or the CI server, checks in if it's anything new. So it's kind of important to realize that. So it doesn't have to be the last guy checking in to make the mess, but oftentimes it is. Because it just takes, it usually pulls and takes or something. So here are some tools. I mentioned Maven, and maybe you've heard of SOTYPE, it's a proxy to the internet so to speak. Because sometimes Maven downloads all of internet and if you are a big team, you don't want to do that. So we found Nexus, so it had to be very useful. Hudson were named, we were mentioned, and you have... Jenkins, Jenkins was named. So Jenkins is more vibrant? Interesting, kind of, that seemed to be happening. But it's very cool, people are passionate about Jenkins. They used to be passionate about Hudson. So it's obviously something good. And then there's the commercial tools doing similar things. I think Bamboo is also quite popular. You heard it? If I could throw one into that, I mean, again, I don't get paid for this. Okay. Okay. It's visibility, we do this little thing to get everywhere. Easy to do stuff so you can spend your time doing coding rather than writing a build server. Okay. And even if you have to buy it, it's not that expensive. Yeah, it's insidious. Okay. Is that a language agrostic or is it tied to any environments? Somehow, it's probably a jeep or something. Yeah, yeah, yeah, yeah, yeah, same people. Oh yeah, same like resharper guys? Yeah, yeah, yeah. Okay, cool. They make good stuff. I'm not paid to say that too, they make good stuff. Here, kind of like Sonar. Because they pull the analysis reports together and I think they drive them also. In the early days, we had, on the region, we made X radar, which is similar to what Sonar is now, but maybe because Sonar got more attention or I think the extra guy got promoted to some management position, so he wasn't able to support it anymore. But the same idea that you capture multiple measurements from multiple tools and the most powerful aspect is actually measuring trends that you see improvements through each time. Then you have all these technical tool findbacks, which I was the first time I heard of it. I was just fantastic at people making. You probably don't know about that. There's some new things coming up. I came across this, I'm not sure if that's an old one or a new one, but this is CKJM, they provide a series of metrics. I think they have a metrics themselves. But you can find it if you Google them. J-Depend, and then there's Google Testability Explorer. And I think, I don't remember exactly what this code analysis plugin is, but the cool thing is essentially cyclomatic complexity tools, measure cyclomatic complexity, which measure the essentially complexity in the code, how many branches you have, and it's kind of, I think it's, the number tells you something. If you have a high number, you should probably look into it. So those are the memory tools. Any, because I'm pretty sure there's some more things that happen. Any other tools you've come across? Yes? Griddle? Griddle? Griddle, yes. How is it written? G-R-A. G-R-A. G-D-M. Griddle? And that's for? It's a really big tool, but it works on Java code as well. Okay. The best part of Griddle is it combines the strength of Maven. Yeah. Okay. What's it into one? Okay. So it's a build tool? Yeah, it's a build tool. Yeah. And then you mentioned something else earlier. What was that again? I forgot. No, you mentioned it, Howard. Team Siri, which is also a build. Any other tools you have seen or like or been optical? See you. C-O-D-E. Synoptical, okay. Cool. Yeah, so now if you haven't seen it, I like those kind of tools. And I like the fact that it has happened on people. People get motivated by this. They see, it makes sense to focus on quality. Sometimes I had this team who, they had a hard time committing themselves to improving the test coverage because they didn't really see the use of it. When we started using X-Radar, which is a similar sonar, then they saw the need for it. They saw the use of it, so. So I think only that has a great sense of use. Okay. A little bit of process side. This is, when I proposed this as a tool thing originally, so I thought I could touch, if you're not that interested, we can skip quickly, but it's kind of interesting that stuff happening here also. And I thought, if you want to have a process tool, what kind of process tools do you want? This is, so essentially you would like to have support for three types of processes, compound, scramb, or issues. So if you, and if you have strong preference for a scramb, for instance, you would look for tools that are good with scramb. Like version one is very good with scramb. It doesn't support compound that well. You can tweak it in. We managed to tweak it in, but it's kind of like, in compound you have a workflow with, you have a specific workflow, but for some reason in version one, that workflow ended up being a global one. There's some, it's kind of, you have to squeeze it in the shoehorn. It's possible, but it's obviously not designed for it. Do you recognize that? Okay. And the whiteboard, it's a great tool. So this is a sample of the tool. There's a lot of people get a bit heated that we don't like these electronic tools because we like the whiteboard. And of course I like the whiteboard. Whiteboard is by far the most efficient communicative tool. The thing is challenging if you are distributed. If you have people working on the same team, some project across distances, whiteboard is challenging. So that's a good reason in my mind to have an electronic tool. So I was in a shop where we used version one. So I know version one. I'm not a big fan of it. I don't want to, it's a good tool, but I, the whiteboard is better than I, before version one, I used Gira. So maybe that's why I kind of, maybe that's why I like Gira. But it's like, it's almost, it's more emotional than anything else I think. You get attached to something because you're used to it. I think, I like the vendors behind, they really want to make something good. So we usually respond to, if you complain about something that they don't support, they usually respond to it. And it's, when you get used to version one, it's actually pretty good. So this is, we use this for a stand up. So you have your, you have your backlog. And you can see it on a storyboard level where you only see the stories or you have the task board level, you receive the task by stories. So when you get used to it, it was fairly effective. And you have a burnout chart, you see, and you see when things are not healthy, for instance, we have been spending almost two weeks on the same things, not progressing. It's nice to see that. We should probably see it earlier. So those tools, they provide that instantly. In, you might not see it that easily in a whiteboard. So there are some advantages that you can see some unhealthy trends. Just hope you're aware that you should never spend eight days on 40 points. That's not very healthy. But sometimes we did that. This is kind of cool. One of the other things you can get though, this is a release forecasting. And we started doing this because before we started using it was just a theory. You use the numbers, the data to extrapolate when you're done. And we were pretty good at, actually, we did the bulk estimation of the whole backlog. And through that, and when we got an established velocity, a version one can project a release forecast. And it's very powerful. We use that to coordinate between dependent teams and also to get feedback for yourself because usually, at least what I'm used to, there is an expectation on a date. By using that tool, you can take action on that expectation. So if you see you're very far off that date, you need to take action. And you need to take action as soon as you get that information. As opposed to in the old days, you took action a couple of weeks before because you wouldn't dare to. Now you take action when you see it happen and you can start a conversation to deal with it. Either negotiate about the date or negotiate about the scope. And those conversations should happen. So I kind of like that. JIRA, this is actually the tool that I was used to. Now I have forgotten how to use it effectively, but I really like JIRA. It's user friendly. It's actually an easy tracking tool, but the way it is set up is they have templates to support Agile. And so it's fairly supportive of Scrum. And I don't know about Kanban, I haven't tried it. Anyone tried JIRA on Kanban? Yeah, we have to do it. Okay. So, sir. Okay. Okay. You can't use it to context. You need it at every damn thing. Okay. They will not come to know if they're like in the same tool in Mac. It's absolutely flexible. But in Mac, if you are like, you know, there are some tools that are limited the way you want to do it, things that I mentioned, that what does the perspective mean to you? Yeah. And for you and me, there are different plans and some basic stuff that, you know, there will be some marketer in the process. Okay. That's a thing. So I was free from the things I can do things. In Mac, this path I had. Interesting. In terms of like, you know, okay, I just need simple stuff to do things. I don't need very complex stuff. Good, valid feedback. Good. Thank you. So I'm, so, and then I'm just fair to say because we're sponsored by Rally here. Rally is also very dedicated to supporting those kind of things. Actually, I use Mantis in the days, but I don't remember exactly how he was. Yeah. Okay. Good. So I think these are the one that are maybe most known. There are more, I know. And there might be some more down in the stalls. So we'd be respectful. I like that there's, but our vendors who care about this. Next part. That's my final thing. I hope I'm good on time. Okay. Yeah. Not really, maybe you guys are. Try to remember. No, yeah, yeah, there are, there are plenty. There's something called scrum. There are some web-based tool that are pretty cool. Sheet was called. Sorry? Ice scrum. Okay. I have to know that, that's probably, I think there are plenty of web-based and they're only web-based. And there's, it was a pretty cool tool which was very supportive or common. I don't remember exactly what it was. Sorry. If I recollect, I'll let you know. I want to find, talk about collaboration. Because I believe that is important to be effective. Especially in our setting now we work across the world. It's unavoidable. You don't always, I like this picture because this is, I like the collaboration nature, collaborative nature of that picture. But you can't always do it like that. But it's our boss sitting there. What are you doing there? You're doing bulk estimation. You have 30 people estimating a full backlog. And it was just amazing. I thought, are you crazy? 30 people doing bulk estimation at the same time? And we did it. It was a bit stressful. You see some people, they prefer playing with the phone. But there were quite a few who were engaged in this. So it worked. But I thought really the point though. When it comes to collaboration, you have to support asynchronous and synchronous. I think the agile guys, we tend to prefer synchronous communication. I actually had, I don't know if my friend is here. I had a session just before lunch where we were talking about email. Why don't you talk about email? We didn't talk about collaboration. And email is there, we can use email. But there are some issues or challenges around email. So I thought of just mentioning that. There are, email is always there, has always been there. But I have noticed and you have probably always also noticed that when an email goes in circle, it tends to lose its effectiveness. And sometimes people react to other things that you want them to react to. So when you see that happen, pick up the phone, talk. Don't wait for these angry emails. But on those tools there are, I like Wiki. And I'm kind of, I feel like Wiki has settled as the say the internet type of tool for developers. There are other attempts, but Wiki is just so natural for us. So we have, and now we have tools like Confluence. We have the original Wiki, it's still there. I think you can, the ctoe.com, that is. I met Ward Cunningham in 2001, my first time. And then he just introduced, let's work together. We should work online. We're in the same room, work online. Why should we do that? I was just blown away. It was just so effective. Because I wasn't imagining, because I thought, oh, then we have to learn this tool. And he didn't provide any training, he just sat there. And was super effective. And I love that nature of Wiki. And you actually are allowed to work with concepts that are not defined. So it's very supportive of that job. So I like the concept of Wiki. And you have Wiki Media, probably not that the framework behind Wikipedia. So that's also there, available, we can use it. And at the time when I made this presentation, I was working with Citrix Online, so I thought it was appropriate. But it still is, I still, I'm not trying to endorse it too much, but I've been exposed to those tools, I know them. And there are other tools. The thing is, you would like to have a tool like GoToMeeting or Skype, where you can, I think the kind of tools you would like to have is a way to share the screen or to demo the thing you're doing. And you may also want to have what we found to be very effective, a way to log into another computer to do a demo on that, because maybe you have a lab, and you don't want to drag all the people to that lab, but you just log on to that computer and show what you have. And GoToMyPC allows you to do that. There are lots of other tools. There are, yeah, we, okay, wow, cool. TVewer, okay, okay, yeah, cool. And of course Skype, Skype is, okay, okay, cool, what? Adobe Connect, okay, cool, very nice, sorry. WebEx, yeah, I'll mention that. They're a competitor to Citrix, but that's okay. They're widespread on, sorry. Microsoft, L, Y, and C, okay, so that works together with WebEx. Sorry? So is that a part of, oh, okay, okay, cool, okay. Join.me, okay, this actually, this wraps up my presentation.