Well, hello. This is another Atlassian-sponsored screencast showing off the sort of partners that they have and the different integrations to different platforms to the different Atlassian products. And today we have a special guest here from Sixth Sense. Would you like to introduce yourself? Hi. My name is Jared Richardson. I'm an Agile coach at Sixth Sense Analytics. I'm also a regular speaker on the No Fluff, Just Stuff Java Tour, as well as a number of other conferences. And a pragmatic publishing author. So I wear a number of different hats. So what does Sixth Sense do exactly? We have a login screen here, but what are you guys up to? Well, Sixth Sense, we're shooting for process metrics. Now, we've got three levels of sensors where we gather information from. The bottom level, right, the lowest level is on the Windows operating system where we gather basically task manager. I mean, we're looking at all the executables that run and how long they're running for. The second level, we talk to DevTools, Eclipse, NetBeans, Visual Studio, VI, Emacs. And we look at things like how long you're editing versus in the debugger, when you're running tests versus you're just reading code. And at the third level, we talk to the enterprise tools. We talk to Team Foundation, Subversion, obviously JIRA, you know, many issue tracking tools, many source code management tools. The goal here is to put all that information together, not to be a big brother or, you know, manager come beat you up because you spent too much time on the web, but to say, how much time am I spending in the debugger versus editing code? Is that normal? Am I spending too much time in this area versus that? Is my team getting interrupted constantly? A lot of people love burn-up charts. We automatically generate tools like burn-up charts to help you with your project management, to help you identify risk early. We give you reports that help you improve your estimation. Basically, I guess one of the taglines is we provide an unprecedented level
2:05of transparency and visibility into the development process, into the development lifecycle. Yeah, why don't we take a look at the tool? Sure, let's dive in. One of the things I like to tell people, we're looking at our production server here. So this is live data. First thing I like to point out to people is that I've got multiple desktops instrumented, or I have sensors on multiple desktops. So if you're on multiple machines, not a problem. You can pull data from as many different sources as you like. And you'll notice this one is XP and OSX. This one's a virtual machine. And so essentially you install little agents or little programs on each of those desktops, I'm assuming. That's exactly right. That sort of gathers the data. Yep. That's all they do. They just pop up every so often, grab some information, try to send it to our servers. If you're offline, it just queues it up on disk until you come back online. We have the concept of workspaces. And there's four different levels of workspaces. The first is your company or team. So you can see here the Sixth Sense analytics team. Here's our development team. We have a performance testing group. I've trimmed down what you can see. You can't see our docs and QA and everything. But that's your first level. You have team or company-wide. The next workspace we have is the community. And this is, again, where you'd come in and benchmark how many hours we're working versus how many hours we're editing, testing, debugging, and compare ourselves against the world at large. The next group we have here, we call them sprints, you know, because we are more of an agile scrum shop. Some people call this, if they're into the waterfall methodology, you know, this is a release. You know, maybe this is a six-month release. Maybe this is a two-week iteration or a sprint. It's what, you know, whatever methodology you adhere to, that's all these are releases. Finally, you have the individuals. And you can see some of our developers right here. So I like to dive in and have a look that Breck is one of our in-house developers. And the first thing we provide people is a status report. Just like you said, the whole point is to improve
4:05myself, you know, self-micromanagement, as you put it. So we come in and we show what has Breck completed within the given time frame. Now, another thing I'll show you real quick is that anytime you have a report, you can go for the last 30 days, you know, relative time, slide it over here. You know, every report is customizable on that front. All right. So you can get pretty nicely bound historic data about in there. That's nice. Squeeze it down to one day, look for 90 days, you know, whatever you're looking for. The other nice feature I like to point out is our actions. One is you can pull this out and export the report to PDF. A lot of times people, for any given report we look at here in a few minutes will want to put this pie chart into an executive summary. Not a problem. Export it out to PDF, pull it back into any format you'd like. But the other nice feature is the email the report. About half of our developers work in this office, but about half of them are scattered up and down the eastern seaboard. So for the people that are off-site, they use this tool with this feature, with this actual report, to keep their boss informed of what they do. They open up the email report and they send it to mybossatorg.com and say, this is my daily status. And then I come in here and say, I want yesterday's date coverage and I want this sent every day. So I no longer have to worry about sending my daily status report. I could send it to my boss. I could send it to myself. You could log into the application and get it there. This is a lot more useful with some of the team-wide metrics, if I want the weekly status for where my project is at. But it's, I schedule any report, I can have it fired off. For the individual status report, Brett can see what he finished for this time period. So here's ID 3996, rules created by users. We provide some key information here. We look at the estimate versus the actual. So in this first case, it wasn't estimated. Oops, that was our fault. But then he spent 9.25 hours on it. The next item was estimated at 8 hours, took 4. So we came out 44% ahead. So this is what we're shooting for. Let's look
6:10for what we really missed up on our time estimates for. Coming out ahead, not worried about that. That's good. But where did we fall behind? It shows you when he closed a given task. Then we scroll down. Work in progress is where you've committed code, but you haven't closed out the feature. There's usually one or two things where you've checked code in, but you haven't finished it up. So that's a good way to find out that either I forgot about something or that maybe one of the testers reopened an issue on me. I need to go back and look at it again. We look at where people, you know, we show you, where did you spend your time? Brett spent 26% of his time editing code. Awesome. 10% looking at code, 7% watching the build. I like to tell people, how many places have you worked where you say the build is slow? We need to retool the build. We need to tweak it, tune it. We need to buy faster hardware. And that's a very nebulous argument. Why does it need to be faster? Because it's too slow. Well, we get you past that. That's right. Brett spent 7% of his time last week. Now, 7% is actually not bad. I've seen teams where they spent 25% and 30% of their time watching the builds. Now, then I can put a return on investment, I can put a dollar amount on how much you can save by making the builds run faster. So that's an interesting example of, like, figuring out how you guys would track metrics. I mean, how does it figure out that you're watching the build? Well, in this case, it's looking at one of two things I would suspect. One, it's either looking at an Eclipse build, where you're doing an incremental build. But more than likely, this came from Ant, because we actually watch Ant as one of the dev tools we instrument. And so we can see that you're running a build from within Ant. So it'll search out for the, like, Ant logs or something like that, I guess, if you have that turned on, and find a begin and end time when you do something. Or just, I guess, even when you're executing it would be even snazzier. It does it live. It does it while Ant's executing. Our sensors are all open source. We have a website up we call SixthForge. I believe it's SixthForge.org. But every sensor we have,
8:12we've open source, so that there's no question about what we collect or how we get to it. Right. But we do some pretty snazzy stuff with the sensors. It's pretty cool. Most of it's, a lot of it, like the Java tools, such as Ant and Eclipse, are all written in Java. So our sensors are written in Java, and they all run cross-platform, just like the original dev tools. And then we kick down here, and we actually look at the work by file. So again, this is Breck looking at what you did, or what he did. So he can see that in principle, Google.java, he spent 1.75 hours that day. Fixed unregistered task, 1.57. I'm actually surprised there's no Groovy in here. There we go. He spent a little bit of time on some Groovy files. This is really useful. One of the uses for this report, and a report that we have coming in a couple iterations, is designed for people who are starting to have Scrum Daily meetings. And when you come into a Scrum Daily meeting, you're supposed to answer three questions, right? What did I do yesterday? What are the problems I had? And what am I going to do tomorrow? This report, in its new form, will be designed to answer that first question, what did I do yesterday? So you print out the report, you bring it with you. You can see where you worked and you didn't check it in. You can see where you actually committed the files. So what did you almost get done? What did you check in? There'll be a space at the bottom for you to fill in your notes. You know, what was I doing yesterday? What did I finish yesterday? So this will be designed to assist, especially when you're first getting started in the Scrum Daily meetings. And again, you could always change this to a weekly iteration and make it a weekly report as well. Yeah, that makes sense. Yeah, it's great to have little training wheels like that. Or, you know, whether it's just for training or just ongoing, right? The less you have to think about your sort of reporting, the better you can spend your time thinking about something more important than, I've got to prepare my memo for the morning Scrum or whatever, right? You could just use the tool to do it. That's what it comes down to. The reason we have the tool that we wrote it in the first place. I mean, some developers don't like that we gather information, you know,
10:13quote unquote, looking over my shoulder. But the question I have for those developers, do you want to spend your time filling out status sheets? You know, I don't want to do weekly status emails. I want to have the machine gathered automatically. They say a good developer is a lazy developer. A good engineer is a lazy engineer. The more I can push off on the machine, the happier I am. One of the things I love about our product is we have a burn-up report. Some people are very familiar with the burn-ups. Some people aren't. A burn-up traditionally has two pieces of information on it, and ours adds a third. The two pieces of information you get, one is the blue line, which is your scope. In this case, we'll talk to the JIRA, and we'll pull the information out for every task that is attributed to a given sprint or release. And all we do is add up your estimates. When you have a given set of estimates, that's how many man hours you've committed to. So you can see here, over the course of the project, that blue line is climbing. This is classic feature creep. We started out with 200 man hours, and, you know, maybe at the beginning we were just adjusting estimates. I can excuse that. But when we get two weeks into the project, and then we jump to almost double the number of man hours, it's pretty clear somebody's chunking in more features. One of the things I really like about the burn-up is I can put this in front of a traditional, non-technical manager. And if we pretend that the graph ends right here, is there any way the dev team is going to be able to catch up with a graph that's climbing like this? They can't get there. But you can see it. It's no longer a, you shouldn't add features because I don't want you to, or it hurts my feelings. We're putting numbers to it, and we're letting them visualize it. And then the nice part here is that it's just importing all of this in from JIRA, right? So you don't have to go load all this into the Sixth Sense product. Absolutely. We pull the metrics out of your existing tools. So we don't want you to have to double enter the data.
12:13You don't want to have to double enter the data. Like I said earlier, right, the good engineer is a lazy engineer. I want to have to enter it one time and be done. So we're just scraping it right out of the existing tools. The third piece of information we have here that most people don't even have access to is the actual time. So every time a developer checks in code to subversion, you know, whatever tool you're using, Perforce, ClearCase, when you check it in, we'll ask you to put in a comment that says this code goes with feature, you know, 1, 2, 3. Then you close out the JIRA ticket, 1, 2, 3, and on our server side, we put all that together. And we say, okay, ticket 1, 2, 3 is closed. This is how many files went into it, and it was checked in by Joe. So then we then go look at Joe with the data we gathered from his desktop, from Eclipse and NetBeans and VI, you know, whatever tools he uses. And we add it up, and we say for this feature, Joe spent 17 and a half hours. And that's where the actual time comes from. Right. You know, what's the classical wisdom? I take the time you give me for a feature. You're a developer. You tell me three days. So I'm going to multiply it by two and a half, and then we're only 30% late. Right? I mean, that's – I want to get past that. I mean, this sprint, I mean, looking at this burn-up chart, I'll take us to another report in a minute now that I'm sort of wandering off on the estimation bit. But, I mean, I can see the trend here. Really early, I can see the risk. I can see this feature creep is going to prevent me from ever catching up. So, you know, whoever was adding these features in, they called them on it, and they stopped here, and it branched off. You notice the original set of features here, if they had been left, that's how much they got done. You see how it sort of lines up along here? Right, right, right. The originally scoped project was achievable. It wasn't until the feature creeped that they blew it out of the water. Everyone just got giddy with adding new functionality right at the start.
14:16Well, it's either a non-technical customer or a non-technical manager. But the beauty of this is you can put this in front of that non-technical personality and say, look, we hit what we thought we could hit. You can add more things in here. You know, we want you driving the process, but we have to take some things out, too, or we can't hit it. And whether you want to look at the rate of addition of features versus the rate of development or what we were actually able to accomplish versus what, you know, because you added them after the fact. You thought you were being clever. You know, you thought you were getting something for nothing. Truth is, you just made a lot of things get not done that you were expecting. That's right. So this is – I love this because whether you're technical or non-technical, you can understand it. You can get your head around it. And with our email function, I can have this in the inbox of every stakeholder and potentially every developer once a week. Behind the burn-up, we have our project task detail. Now, this particular sprint's finished, so there's nothing in the recent activity table. But I love this report. It's tasks by difference from estimate. This is what I call your estimate errors. So for a given task, revamp the UI. Estimate was 16 hours. Actual was 34. Oops. We had an 18-hour delta, almost over 100%. Right. This report is designed to let whoever's doing the estimating, whether it's the developer, the project manager, what did you miss? You know, you can see here, here's the things we didn't bother to estimate. That sort of blows the schedule. Here's the things we estimated. Two hours took six. Four hours took nine. But the goal here is just to see where did we miss it. And again, because we're measuring the actual, not just three days and then guesstimate that three days was three eight-hour days. You know, we see how much time went into a feature. So there's the difference from estimates. We are really adding more in the estimation area as well. We're adding in the next few iterations of our own development cycle some estimation error ratios that will go on a given iteration or sprint so that you can say in the last sprint we were 1.34 times slower than our estimates.
16:29But last time we were 2.8. Before that we were 10.3. We're getting better. So the whole goal here is to give you the feedback to get better at what you do. Well, let me kick up and show you this last report. I saved this one for the end because it's my favorite. This is the dev report. Debug, edit, view. I can come into a team and based on this chart I can tell you whether the team is familiar with the technology they're working with, whether they have automated testing, whether they're new or experienced. And here's what I look at. The edit ratio to the debug ratio. Right now we're looking at two to one, three to one. So for every six hours spent editing we get, what, two hours debugging. Right. On a bad team, well, I won't say a bad team, on a team with no test automation, and especially without a continuous integration product behind it, the debug edit ratios go to one to one. So if a team spends a week writing new code, somewhere down the road they'll spend a week actually making it work, and they'll do it in a debugger line by line by line. The problem is they don't have test automation. When you see a team with a good CI suite and a good test suite behind it, the debug edit ratio goes to about ten to one. So that's a huge return on investment cost. When the team's walking through a debugger line by line, they're not adding features to your product. You're not making money. Right. But if we can put a CI system, again, continuous integration in place with a good automated test suite to get the feedback to the developers quicker, the debug time literally drops. Again, ten to one, which is where you want your team to be. The other side of that is if your view ratio gets too high. If the team is spending a lot of time doing what I call code diving, reading the code to try to understand it, then they either don't know the technology, they don't know the code base. And there are a lot of different things you can do to address that. I love the peer code review to try to share expertise. There's peer programming to try to do that same thing. If the code is in too big of chunks, you use this metric to drive your refactoring effort.
18:29Maybe the code is too big for people to get into their head. You have 15-page routines. So you want to trim those down to 15 one-page routines that people can look at, understand, and move on. So anyway, there's the debug chart. It's one of my favorites. Let's kick away from that and talk more about JIRA integration. How's that? Sounds great. All right, let's log out of this instance and log into this one, which is a different machine, different box. Actually, you know what? Let's just stick with this one. Let's close that out. Come over here. Sixth Sense has a desktop. Now, we mentioned some of the sensors earlier. So this is looking at my local host instance right here. We've got a little Jetty engine or Jetty server that runs locally. And I can look at – there's two different things we're going to look at. One is the sensor manager, and then we're going to look at the sensor task manager. So if we look at the sensor manager, this is everything I've got installed on this machine. I've got an ANT sensor in place. I've got Eclipse. Emacs is instrumented. Firefox, JIRA. You get the idea. I mean, a lot of different things going on in here. If I looked at specific categories, if I want to add sensors, I can automatically have it scan the machine, see what you want to hit, or I can go for manual. So I put the sensors down here. Now, a couple of these are enterprise sensors, like JIRA, for instance. This is not – it's not hitting my desktop. It's hitting a server. But in order to do that, I've got to go to the enterprise tasks. Let's go over there and look at what it looks like to scrape a JIRA. I have two different enterprise tools here, the subversion sensor and the Sixth Sense Dev JIRA. So let's go look at the settings. You have a set of properties, right? You've got to have the URL for a given JIRA. Let's copy that out. We've got JIRA user, password, Sprint 7. This is telling it where to go. And let's just verify that that's valid. Verifying it's good. You'll have a user map, which maps your JIRA accounts to your local Sixth Sense accounts.
20:32All right. So this is, you know, map point A to point B. And finally, when do you want this thing to run? Now, we don't want to run continually. You know, we're trying to keep down the load on the servers. So we generally pop up at midnight and run the task. Right. And as we were saying earlier, it's only reading things out of JIRA. It's not writing things back to it, right? Absolutely. Absolutely. So if we were to come over here and you were saying, how do we make a project? Right? I logged in here. Greg Burnell is our CEO. And I logged in as Greg because he's got admin rights on the production box. As all CEOs should. Yeah, that's a really good point. Let's ditch Greg. I actually hit the wrong box there. Yeah, I'm logged in as Greg on this box. I'm over here in my demo box now. Perfect. So I would come in to, I was in settings. You know, let me show you so there's no question. Somebody's going to want to do this at home, right? You're going to want to do this. So I log in. And here's my desktop. I'm going to come up to the settings link. I'm going to go into settings. And then over on the left-hand side, you're going to see, you know, my main settings, team, projects, attribution. We're dealing with projects right here. Right. So for a given project, one, he can see everything out there. Open, closed, number of sprints floating around here. But here's, you know, nice little wizard to walk you through. Let's add a project. So the project name is going to be the Cody Sprint. And start date, let's go with a nice calendar. Let's, heck, let's start it tomorrow. I fear it may end up more like a potato bag race. Well, you never know. The team will go for six, you know, you can be on sales. I'm going to have a, there we go, marketing. There you go. It's a, and for the tracking system, man, we can go for the JIRA. The JIRA is where we want to come from.
22:34So it runs through here, pulls the data out. Now, this particular box is a little bit off from the, actually, I hit the box I didn't realize I was hitting. We're actually doing this on production. So it's pulling from the developers in here how much time they work every day. Now, I picked the wrong team. I picked the marketing team. I should have done this dev, and it would have been even better. But the average amount of time for these people are 5.3 hours a day. Right. So for the team I picked, I can schedule them eight hours a day, but history tells me I'm only getting 5.3. So good luck, you know. Let's kick over to my demo box where I can get away with a little bit more. Let me sign out as myself again. Log back in as Greg. Because Greg's admin everywhere. And dash back into settings because I can show you a little bit more on this box than I can on that one and not get in trouble. On this box, we still can have sprint code. And we'll go with the same, you know, start and end dates. Don't really matter unless you, we do have it set up. The team's already booked for this time period. So let's go out a month. And we are changing that so that you could have the concept of a team that's multitasked for people that are bouncing around. And here, you asked how we got the team. This is the JIRA team. Right. That makes sense. Now, you'll notice on this instance, you're not seeing the choice of all the different source code management systems. Right. That's because on this instance, I've only got one system set up, which is the JIRA. Right. So if you're in an environment where you have five different JIRAs or five different products, we'll give you the choice. If we know there's only one, you know, why put the drop down there? We're just going to pick it for you. Right. Just to make it a little easier. So here we go next. It's doing the same thing it was before, calculating estimates and velocity. Yeah. Because it's a demo box, we don't have the time. So let's just say done. And let's go down here to Sprint Coté. And the first thing it's going to say is no tasks are on this project.
24:35Let's add some tasks. So this is if we wanted to come in and put in some criteria for what we pulled out of the JIRA, this is how we'd break it out. So in this case, let's pick Project. And let's say Project is Sprint 7. And there are the tasks that fall into this. Right. And it's another sort of area where you can map different criteria for pulling things in. Absolutely. Like we've seen in other areas. So there we go. Is there any, you know, we've made a run through the product. I've actually created a project for you based on JIRA data? That's right. Yeah, no, I think that's interesting stuff. It's always, there's a continuous cycle, it seems, in software development between people wanting a lot of metrics and then people resisting a lot of metrics, right? And I've gotten the sense over the past few years that we've realized that it's actually nice to have metrics for things. And it's good to have, but more importantly, it's good to have metrics that don't create a lot of more hassle to get, right? And that's always been the problem in the past is, like, I remember there was, like, the, I forget the name, but, like, the personal software process or something where you were supposed to, like, keep a little paper and pen notebook and, like, write down all this stuff. Right. Yeah, that's just not really feasible unless you're extremely attentive, whereas having some little agent monitor for you seems a lot more attractive. It is. I mean, you need to work with people that you trust, right? This is something that someone could use to, quote, unquote, big brother you. But if you're working with somebody that's going to do that, you should leave anyway, right? Right. I don't have time to sit there with a piece of paper and write it all down. Then I don't have time to look at it and extract the trends. I don't have time to copy it up from my manager. This does it all for you automatically. That's right. Well, that's exciting. Well, thanks for spending this time to show us this. It was pretty cool. I enjoyed talking with you today.