1
00:00:00,000 --> 00:00:10,680
Well, hello. This is another Atlassian-sponsored screencast showing off the sort of partners

2
00:00:10,680 --> 00:00:14,960
that they have and the different integrations to different platforms to the different Atlassian

3
00:00:14,960 --> 00:00:20,140
products. And today we have a special guest here from Sixth Sense. Would you like to introduce

4
00:00:20,140 --> 00:00:20,460
yourself?

5
00:00:21,080 --> 00:00:25,720
Hi. My name is Jared Richardson. I'm an Agile coach at Sixth Sense Analytics. I'm also

6
00:00:25,720 --> 00:00:29,800
a regular speaker on the No Fluff, Just Stuff Java Tour, as well as a number of other conferences.

7
00:00:30,300 --> 00:00:34,140
And a pragmatic publishing author. So I wear a number of different hats.

8
00:00:34,140 --> 00:00:39,760
So what does Sixth Sense do exactly? We have a login screen here, but what are you guys up to?

9
00:00:40,340 --> 00:00:46,440
Well, Sixth Sense, we're shooting for process metrics. Now, we've got three levels of sensors

10
00:00:46,440 --> 00:00:51,160
where we gather information from. The bottom level, right, the lowest level is on the Windows

11
00:00:51,160 --> 00:00:56,380
operating system where we gather basically task manager. I mean, we're looking at all the

12
00:00:56,380 --> 00:01:02,060
executables that run and how long they're running for. The second level, we talk to DevTools,

13
00:01:02,420 --> 00:01:10,260
Eclipse, NetBeans, Visual Studio, VI, Emacs. And we look at things like how long you're editing

14
00:01:10,260 --> 00:01:14,340
versus in the debugger, when you're running tests versus you're just reading code.

15
00:01:15,000 --> 00:01:20,540
And at the third level, we talk to the enterprise tools. We talk to Team Foundation, Subversion,

16
00:01:21,480 --> 00:01:26,660
obviously JIRA, you know, many issue tracking tools, many source code management tools.

17
00:01:27,000 --> 00:01:33,140
The goal here is to put all that information together, not to be a big brother or, you know,

18
00:01:33,300 --> 00:01:37,640
manager come beat you up because you spent too much time on the web, but to say,

19
00:01:37,860 --> 00:01:44,440
how much time am I spending in the debugger versus editing code? Is that normal? Am I spending too

20
00:01:44,440 --> 00:01:50,080
much time in this area versus that? Is my team getting interrupted constantly? A lot of people

21
00:01:50,080 --> 00:01:55,120
love burn-up charts. We automatically generate tools like burn-up charts to help you with your

22
00:01:55,120 --> 00:01:59,160
project management, to help you identify risk early. We give you reports that help you improve

23
00:01:59,160 --> 00:02:05,340
your estimation. Basically, I guess one of the taglines is we provide an unprecedented level

24
00:02:05,340 --> 00:02:10,480
of transparency and visibility into the development process, into the development lifecycle.

25
00:02:10,500 --> 00:02:11,800
Yeah, why don't we take a look at the tool?

26
00:02:12,260 --> 00:02:16,060
Sure, let's dive in. One of the things I like to tell people, we're looking at our production

27
00:02:16,060 --> 00:02:23,240
server here. So this is live data. First thing I like to point out to people is that I've got

28
00:02:23,240 --> 00:02:28,560
multiple desktops instrumented, or I have sensors on multiple desktops. So if you're on multiple

29
00:02:28,560 --> 00:02:33,720
machines, not a problem. You can pull data from as many different sources as you like. And you'll

30
00:02:33,720 --> 00:02:36,940
notice this one is XP and OSX. This one's a virtual machine.

31
00:02:37,620 --> 00:02:41,880
And so essentially you install little agents or little programs on each of those desktops,

32
00:02:41,980 --> 00:02:42,440
I'm assuming.

33
00:02:42,940 --> 00:02:43,860
That's exactly right.

34
00:02:44,060 --> 00:02:44,800
That sort of gathers the data.

35
00:02:45,420 --> 00:02:49,700
Yep. That's all they do. They just pop up every so often, grab some information, try to send it to

36
00:02:49,700 --> 00:02:53,680
our servers. If you're offline, it just queues it up on disk until you come back online.

37
00:02:55,680 --> 00:03:01,380
We have the concept of workspaces. And there's four different levels of workspaces. The first is

38
00:03:01,380 --> 00:03:06,360
your company or team. So you can see here the Sixth Sense analytics team. Here's our development

39
00:03:06,360 --> 00:03:11,520
team. We have a performance testing group. I've trimmed down what you can see. You can't see our

40
00:03:11,520 --> 00:03:17,420
docs and QA and everything. But that's your first level. You have team or company-wide. The next

41
00:03:17,420 --> 00:03:22,800
workspace we have is the community. And this is, again, where you'd come in and benchmark how many hours

42
00:03:22,800 --> 00:03:28,080
we're working versus how many hours we're editing, testing, debugging, and compare ourselves against

43
00:03:28,080 --> 00:03:34,180
the world at large. The next group we have here, we call them sprints, you know, because we are more

44
00:03:34,180 --> 00:03:39,480
of an agile scrum shop. Some people call this, if they're into the waterfall methodology, you know,

45
00:03:39,500 --> 00:03:44,860
this is a release. You know, maybe this is a six-month release. Maybe this is a two-week iteration

46
00:03:44,860 --> 00:03:50,300
or a sprint. It's what, you know, whatever methodology you adhere to, that's all these are releases.

47
00:03:50,300 --> 00:03:53,820
Finally, you have the individuals. And you can see some of our developers right here.

48
00:03:54,720 --> 00:04:01,120
So I like to dive in and have a look that Breck is one of our in-house developers. And the first

49
00:04:01,120 --> 00:04:05,660
thing we provide people is a status report. Just like you said, the whole point is to improve

50
00:04:05,660 --> 00:04:11,640
myself, you know, self-micromanagement, as you put it. So we come in and we show what has

51
00:04:11,640 --> 00:04:16,220
Breck completed within the given time frame. Now, another thing I'll show you real quick is that

52
00:04:16,220 --> 00:04:22,480
anytime you have a report, you can go for the last 30 days, you know, relative time, slide

53
00:04:22,480 --> 00:04:26,080
it over here. You know, every report is customizable on that front.

54
00:04:26,300 --> 00:04:31,260
All right. So you can get pretty nicely bound historic data about in there. That's nice.

55
00:04:31,360 --> 00:04:35,000
Squeeze it down to one day, look for 90 days, you know, whatever you're looking for.

56
00:04:35,240 --> 00:04:39,460
The other nice feature I like to point out is our actions. One is you can pull this out

57
00:04:39,460 --> 00:04:44,360
and export the report to PDF. A lot of times people, for any given report we look at here

58
00:04:44,360 --> 00:04:48,660
in a few minutes will want to put this pie chart into an executive summary. Not a problem.

59
00:04:48,780 --> 00:04:53,840
Export it out to PDF, pull it back into any format you'd like. But the other nice feature

60
00:04:53,840 --> 00:04:59,020
is the email the report. About half of our developers work in this office, but about half of them

61
00:04:59,020 --> 00:05:03,620
are scattered up and down the eastern seaboard. So for the people that are off-site, they use

62
00:05:03,620 --> 00:05:08,260
this tool with this feature, with this actual report, to keep their boss informed of what they

63
00:05:08,260 --> 00:05:16,900
do. They open up the email report and they send it to mybossatorg.com and say, this is

64
00:05:16,900 --> 00:05:24,100
my daily status. And then I come in here and say, I want yesterday's date coverage and I

65
00:05:24,100 --> 00:05:29,100
want this sent every day. So I no longer have to worry about sending my daily status report.

66
00:05:29,300 --> 00:05:33,000
I could send it to my boss. I could send it to myself. You could log into the application

67
00:05:33,000 --> 00:05:37,300
and get it there. This is a lot more useful with some of the team-wide metrics, if I want

68
00:05:37,300 --> 00:05:42,740
the weekly status for where my project is at. But it's, I schedule any report, I can have

69
00:05:42,740 --> 00:05:46,500
it fired off. For the individual status report, Brett can see what he finished for this time

70
00:05:46,500 --> 00:05:52,340
period. So here's ID 3996, rules created by users. We provide some key information here.

71
00:05:52,400 --> 00:05:57,660
We look at the estimate versus the actual. So in this first case, it wasn't estimated.

72
00:05:58,000 --> 00:06:04,660
Oops, that was our fault. But then he spent 9.25 hours on it. The next item was estimated

73
00:06:04,660 --> 00:06:10,360
at 8 hours, took 4. So we came out 44% ahead. So this is what we're shooting for. Let's look

74
00:06:10,360 --> 00:06:15,460
for what we really missed up on our time estimates for. Coming out ahead, not worried about that.

75
00:06:15,520 --> 00:06:20,720
That's good. But where did we fall behind? It shows you when he closed a given task.

76
00:06:21,700 --> 00:06:25,420
Then we scroll down. Work in progress is where you've committed code, but you haven't closed

77
00:06:25,420 --> 00:06:29,460
out the feature. There's usually one or two things where you've checked code in, but you

78
00:06:29,460 --> 00:06:34,700
haven't finished it up. So that's a good way to find out that either I forgot about something

79
00:06:34,700 --> 00:06:39,460
or that maybe one of the testers reopened an issue on me. I need to go back and look at

80
00:06:39,460 --> 00:06:44,960
it again. We look at where people, you know, we show you, where did you spend your time?

81
00:06:45,420 --> 00:06:51,800
Brett spent 26% of his time editing code. Awesome. 10% looking at code, 7% watching the build.

82
00:06:51,840 --> 00:06:56,980
I like to tell people, how many places have you worked where you say the build is slow? We need

83
00:06:56,980 --> 00:07:01,540
to retool the build. We need to tweak it, tune it. We need to buy faster hardware. And that's a

84
00:07:01,540 --> 00:07:06,580
very nebulous argument. Why does it need to be faster? Because it's too slow. Well, we get you

85
00:07:06,580 --> 00:07:07,880
past that. That's right.

86
00:07:07,880 --> 00:07:13,760
Brett spent 7% of his time last week. Now, 7% is actually not bad. I've seen teams where they spent

87
00:07:13,760 --> 00:07:20,760
25% and 30% of their time watching the builds. Now, then I can put a return on investment,

88
00:07:20,900 --> 00:07:25,700
I can put a dollar amount on how much you can save by making the builds run faster.

89
00:07:25,700 --> 00:07:30,140
So that's an interesting example of, like, figuring out how you guys would track metrics. I mean,

90
00:07:30,140 --> 00:07:32,320
how does it figure out that you're watching the build?

91
00:07:33,020 --> 00:07:37,500
Well, in this case, it's looking at one of two things I would suspect. One, it's either

92
00:07:37,500 --> 00:07:42,460
looking at an Eclipse build, where you're doing an incremental build. But more than likely,

93
00:07:42,560 --> 00:07:47,640
this came from Ant, because we actually watch Ant as one of the dev tools we instrument. And so

94
00:07:47,640 --> 00:07:49,920
we can see that you're running a build from within Ant.

95
00:07:50,400 --> 00:07:55,540
So it'll search out for the, like, Ant logs or something like that, I guess, if you have

96
00:07:55,540 --> 00:07:59,700
that turned on, and find a begin and end time when you do something. Or just, I guess,

97
00:07:59,700 --> 00:08:02,220
even when you're executing it would be even snazzier.

98
00:08:02,660 --> 00:08:07,340
It does it live. It does it while Ant's executing. Our sensors are all open source. We have

99
00:08:07,340 --> 00:08:12,780
a website up we call SixthForge. I believe it's SixthForge.org. But every sensor we have,

100
00:08:12,840 --> 00:08:16,400
we've open source, so that there's no question about what we collect or how we get to it.

101
00:08:16,480 --> 00:08:16,680
Right.

102
00:08:16,680 --> 00:08:21,420
But we do some pretty snazzy stuff with the sensors. It's pretty cool. Most of it's,

103
00:08:21,780 --> 00:08:26,280
a lot of it, like the Java tools, such as Ant and Eclipse, are all written in Java. So our

104
00:08:26,280 --> 00:08:29,720
sensors are written in Java, and they all run cross-platform, just like the original dev tools.

105
00:08:29,720 --> 00:08:33,680
And then we kick down here, and we actually look at the work by file. So again, this is Breck looking at

106
00:08:33,680 --> 00:08:37,320
what you did, or what he did. So he can see that in principle,

107
00:08:37,340 --> 00:08:45,440
Google.java, he spent 1.75 hours that day. Fixed unregistered task, 1.57. I'm actually surprised

108
00:08:45,440 --> 00:08:50,520
there's no Groovy in here. There we go. He spent a little bit of time on some Groovy files.

109
00:08:51,140 --> 00:08:56,300
This is really useful. One of the uses for this report, and a report that we have coming in a

110
00:08:56,300 --> 00:09:00,720
couple iterations, is designed for people who are starting to have Scrum Daily meetings.

111
00:09:01,360 --> 00:09:04,580
And when you come into a Scrum Daily meeting, you're supposed to answer three questions,

112
00:09:04,580 --> 00:09:09,620
right? What did I do yesterday? What are the problems I had? And what am I going to do tomorrow?

113
00:09:10,320 --> 00:09:14,720
This report, in its new form, will be designed to answer that first question,

114
00:09:15,100 --> 00:09:19,360
what did I do yesterday? So you print out the report, you bring it with you.

115
00:09:20,160 --> 00:09:25,100
You can see where you worked and you didn't check it in. You can see where you actually committed the

116
00:09:25,100 --> 00:09:30,480
files. So what did you almost get done? What did you check in? There'll be a space at the bottom for you to

117
00:09:30,480 --> 00:09:34,980
fill in your notes. You know, what was I doing yesterday? What did I finish yesterday?

118
00:09:35,480 --> 00:09:36,220
So this will be

119
00:09:36,220 --> 00:09:40,780
designed to assist, especially when you're first getting started in the Scrum Daily meetings.

120
00:09:42,300 --> 00:09:44,680
And again, you could always change this to a

121
00:09:44,680 --> 00:09:47,380
weekly iteration and make it a weekly report as well.

122
00:09:47,720 --> 00:09:48,360
Yeah, that makes sense.

123
00:09:48,360 --> 00:09:50,800
Yeah, it's great to have little training wheels like that.

124
00:09:51,320 --> 00:09:51,840
Or, you know,

125
00:09:52,780 --> 00:09:55,400
whether it's just for training or just ongoing, right?

126
00:09:55,460 --> 00:09:57,560
The less you have to think about your sort of reporting,

127
00:09:57,680 --> 00:10:00,960
the better you can spend your time thinking about something more important than,

128
00:10:01,160 --> 00:10:04,500
I've got to prepare my memo for the morning Scrum or whatever, right?

129
00:10:04,560 --> 00:10:05,960
You could just use the tool to do it.

130
00:10:06,520 --> 00:10:10,260
That's what it comes down to. The reason we have the tool that we wrote it in the first place.

131
00:10:10,360 --> 00:10:13,540
I mean, some developers don't like that we gather information, you know,

132
00:10:13,600 --> 00:10:15,140
quote unquote, looking over my shoulder.

133
00:10:15,380 --> 00:10:19,820
But the question I have for those developers, do you want to spend your time filling out status sheets?

134
00:10:20,360 --> 00:10:22,700
You know, I don't want to do weekly status emails.

135
00:10:22,700 --> 00:10:24,780
I want to have the machine gathered automatically.

136
00:10:25,620 --> 00:10:28,020
They say a good developer is a lazy developer.

137
00:10:28,180 --> 00:10:29,540
A good engineer is a lazy engineer.

138
00:10:30,060 --> 00:10:32,800
The more I can push off on the machine, the happier I am.

139
00:10:33,320 --> 00:10:36,220
One of the things I love about our product is we have a burn-up report.

140
00:10:37,000 --> 00:10:39,080
Some people are very familiar with the burn-ups.

141
00:10:39,560 --> 00:10:40,320
Some people aren't.

142
00:10:40,660 --> 00:10:43,840
A burn-up traditionally has two pieces of information on it,

143
00:10:44,000 --> 00:10:45,160
and ours adds a third.

144
00:10:45,920 --> 00:10:47,800
The two pieces of information you get,

145
00:10:47,880 --> 00:10:49,680
one is the blue line, which is your scope.

146
00:10:50,020 --> 00:10:52,280
In this case, we'll talk to the JIRA,

147
00:10:53,040 --> 00:10:58,440
and we'll pull the information out for every task that is attributed to a given sprint or release.

148
00:10:58,900 --> 00:11:00,720
And all we do is add up your estimates.

149
00:11:01,300 --> 00:11:05,340
When you have a given set of estimates, that's how many man hours you've committed to.

150
00:11:05,700 --> 00:11:09,720
So you can see here, over the course of the project, that blue line is climbing.

151
00:11:10,120 --> 00:11:11,620
This is classic feature creep.

152
00:11:12,000 --> 00:11:14,060
We started out with 200 man hours,

153
00:11:14,580 --> 00:11:17,380
and, you know, maybe at the beginning we were just adjusting estimates.

154
00:11:17,440 --> 00:11:18,580
I can excuse that.

155
00:11:18,700 --> 00:11:21,320
But when we get two weeks into the project,

156
00:11:21,800 --> 00:11:24,680
and then we jump to almost double the number of man hours,

157
00:11:25,220 --> 00:11:29,060
it's pretty clear somebody's chunking in more features.

158
00:11:29,640 --> 00:11:32,320
One of the things I really like about the burn-up

159
00:11:32,320 --> 00:11:36,260
is I can put this in front of a traditional, non-technical manager.

160
00:11:36,880 --> 00:11:39,520
And if we pretend that the graph ends right here,

161
00:11:40,740 --> 00:11:43,260
is there any way the dev team is going to be able to catch up

162
00:11:43,260 --> 00:11:45,220
with a graph that's climbing like this?

163
00:11:46,200 --> 00:11:47,200
They can't get there.

164
00:11:47,380 --> 00:11:49,020
But you can see it.

165
00:11:49,200 --> 00:11:53,540
It's no longer a, you shouldn't add features because I don't want you to,

166
00:11:53,800 --> 00:11:55,900
or it hurts my feelings.

167
00:11:56,140 --> 00:11:59,440
We're putting numbers to it, and we're letting them visualize it.

168
00:11:59,820 --> 00:12:03,860
And then the nice part here is that it's just importing all of this in from JIRA, right?

169
00:12:03,900 --> 00:12:07,340
So you don't have to go load all this into the Sixth Sense product.

170
00:12:08,000 --> 00:12:08,400
Absolutely.

171
00:12:08,560 --> 00:12:10,500
We pull the metrics out of your existing tools.

172
00:12:11,020 --> 00:12:13,780
So we don't want you to have to double enter the data.

173
00:12:13,920 --> 00:12:15,740
You don't want to have to double enter the data.

174
00:12:16,420 --> 00:12:19,300
Like I said earlier, right, the good engineer is a lazy engineer.

175
00:12:19,680 --> 00:12:22,380
I want to have to enter it one time and be done.

176
00:12:23,380 --> 00:12:25,900
So we're just scraping it right out of the existing tools.

177
00:12:26,360 --> 00:12:33,820
The third piece of information we have here that most people don't even have access to is the actual time.

178
00:12:34,460 --> 00:12:41,080
So every time a developer checks in code to subversion, you know, whatever tool you're using, Perforce, ClearCase,

179
00:12:41,800 --> 00:12:48,500
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.

180
00:12:49,180 --> 00:12:54,960
Then you close out the JIRA ticket, 1, 2, 3, and on our server side, we put all that together.

181
00:12:55,620 --> 00:12:58,220
And we say, okay, ticket 1, 2, 3 is closed.

182
00:12:58,700 --> 00:13:02,300
This is how many files went into it, and it was checked in by Joe.

183
00:13:02,440 --> 00:13:09,600
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.

184
00:13:09,900 --> 00:13:14,460
And we add it up, and we say for this feature, Joe spent 17 and a half hours.

185
00:13:15,020 --> 00:13:17,100
And that's where the actual time comes from.

186
00:13:17,680 --> 00:13:17,780
Right.

187
00:13:17,780 --> 00:13:19,440
You know, what's the classical wisdom?

188
00:13:19,580 --> 00:13:21,340
I take the time you give me for a feature.

189
00:13:21,700 --> 00:13:22,280
You're a developer.

190
00:13:22,420 --> 00:13:23,320
You tell me three days.

191
00:13:23,500 --> 00:13:26,960
So I'm going to multiply it by two and a half, and then we're only 30% late.

192
00:13:27,460 --> 00:13:27,720
Right?

193
00:13:27,840 --> 00:13:30,480
I mean, that's – I want to get past that.

194
00:13:30,560 --> 00:13:40,260
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.

195
00:13:40,540 --> 00:13:42,240
But, I mean, I can see the trend here.

196
00:13:42,880 --> 00:13:44,600
Really early, I can see the risk.

197
00:13:45,060 --> 00:13:49,740
I can see this feature creep is going to prevent me from ever catching up.

198
00:13:50,240 --> 00:13:55,040
So, you know, whoever was adding these features in, they called them on it, and they stopped here, and it branched off.

199
00:13:55,420 --> 00:14:00,620
You notice the original set of features here, if they had been left, that's how much they got done.

200
00:14:01,620 --> 00:14:04,020
You see how it sort of lines up along here?

201
00:14:04,160 --> 00:14:04,860
Right, right, right.

202
00:14:05,240 --> 00:14:08,520
The originally scoped project was achievable.

203
00:14:09,040 --> 00:14:11,940
It wasn't until the feature creeped that they blew it out of the water.

204
00:14:12,120 --> 00:14:16,200
Everyone just got giddy with adding new functionality right at the start.

205
00:14:16,900 --> 00:14:20,120
Well, it's either a non-technical customer or a non-technical manager.

206
00:14:20,580 --> 00:14:27,420
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.

207
00:14:27,420 --> 00:14:29,020
You can add more things in here.

208
00:14:29,140 --> 00:14:34,900
You know, we want you driving the process, but we have to take some things out, too, or we can't hit it.

209
00:14:35,220 --> 00:14:45,800
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.

210
00:14:46,140 --> 00:14:47,360
You thought you were being clever.

211
00:14:47,560 --> 00:14:49,080
You know, you thought you were getting something for nothing.

212
00:14:49,560 --> 00:14:52,620
Truth is, you just made a lot of things get not done that you were expecting.

213
00:14:53,040 --> 00:14:53,420
That's right.

214
00:14:53,540 --> 00:14:59,020
So this is – I love this because whether you're technical or non-technical, you can understand it.

215
00:14:59,080 --> 00:15:00,240
You can get your head around it.

216
00:15:00,860 --> 00:15:07,340
And with our email function, I can have this in the inbox of every stakeholder and potentially every developer once a week.

217
00:15:07,340 --> 00:15:09,980
Behind the burn-up, we have our project task detail.

218
00:15:10,320 --> 00:15:14,420
Now, this particular sprint's finished, so there's nothing in the recent activity table.

219
00:15:15,140 --> 00:15:16,260
But I love this report.

220
00:15:16,500 --> 00:15:18,580
It's tasks by difference from estimate.

221
00:15:18,760 --> 00:15:20,640
This is what I call your estimate errors.

222
00:15:21,420 --> 00:15:23,600
So for a given task, revamp the UI.

223
00:15:24,280 --> 00:15:25,940
Estimate was 16 hours.

224
00:15:26,540 --> 00:15:27,720
Actual was 34.

225
00:15:27,940 --> 00:15:28,220
Oops.

226
00:15:28,540 --> 00:15:31,320
We had an 18-hour delta, almost over 100%.

227
00:15:31,320 --> 00:15:31,960
Right.

228
00:15:31,960 --> 00:15:40,520
This report is designed to let whoever's doing the estimating, whether it's the developer, the project manager, what did you miss?

229
00:15:41,060 --> 00:15:43,800
You know, you can see here, here's the things we didn't bother to estimate.

230
00:15:43,980 --> 00:15:45,280
That sort of blows the schedule.

231
00:15:46,140 --> 00:15:47,320
Here's the things we estimated.

232
00:15:47,420 --> 00:15:48,700
Two hours took six.

233
00:15:49,140 --> 00:15:50,440
Four hours took nine.

234
00:15:50,440 --> 00:15:54,040
But the goal here is just to see where did we miss it.

235
00:15:54,760 --> 00:16:02,320
And again, because we're measuring the actual, not just three days and then guesstimate that three days was three eight-hour days.

236
00:16:02,700 --> 00:16:05,360
You know, we see how much time went into a feature.

237
00:16:07,740 --> 00:16:09,760
So there's the difference from estimates.

238
00:16:09,760 --> 00:16:13,420
We are really adding more in the estimation area as well.

239
00:16:13,900 --> 00:16:28,860
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.

240
00:16:29,360 --> 00:16:31,080
But last time we were 2.8.

241
00:16:31,140 --> 00:16:32,960
Before that we were 10.3.

242
00:16:33,300 --> 00:16:34,120
We're getting better.

243
00:16:34,660 --> 00:16:37,980
So the whole goal here is to give you the feedback to get better at what you do.

244
00:16:38,380 --> 00:16:40,020
Well, let me kick up and show you this last report.

245
00:16:40,180 --> 00:16:42,060
I saved this one for the end because it's my favorite.

246
00:16:42,560 --> 00:16:43,660
This is the dev report.

247
00:16:44,040 --> 00:16:45,080
Debug, edit, view.

248
00:16:45,740 --> 00:16:57,220
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.

249
00:16:57,800 --> 00:16:58,820
And here's what I look at.

250
00:16:59,000 --> 00:17:01,580
The edit ratio to the debug ratio.

251
00:17:02,160 --> 00:17:05,140
Right now we're looking at two to one, three to one.

252
00:17:05,580 --> 00:17:09,320
So for every six hours spent editing we get, what, two hours debugging.

253
00:17:10,040 --> 00:17:10,280
Right.

254
00:17:10,680 --> 00:17:21,180
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.

255
00:17:21,860 --> 00:17:31,440
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.

256
00:17:31,840 --> 00:17:33,960
The problem is they don't have test automation.

257
00:17:33,960 --> 00:17:40,520
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.

258
00:17:41,440 --> 00:17:44,900
So that's a huge return on investment cost.

259
00:17:45,100 --> 00:17:48,640
When the team's walking through a debugger line by line, they're not adding features to your product.

260
00:17:48,760 --> 00:17:49,560
You're not making money.

261
00:17:50,160 --> 00:17:50,260
Right.

262
00:17:50,500 --> 00:17:59,660
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.

263
00:18:00,140 --> 00:18:03,260
Again, ten to one, which is where you want your team to be.

264
00:18:03,700 --> 00:18:06,480
The other side of that is if your view ratio gets too high.

265
00:18:06,860 --> 00:18:15,640
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.

266
00:18:16,520 --> 00:18:18,540
And there are a lot of different things you can do to address that.

267
00:18:18,900 --> 00:18:21,860
I love the peer code review to try to share expertise.

268
00:18:22,440 --> 00:18:24,580
There's peer programming to try to do that same thing.

269
00:18:24,580 --> 00:18:29,120
If the code is in too big of chunks, you use this metric to drive your refactoring effort.

270
00:18:29,640 --> 00:18:31,960
Maybe the code is too big for people to get into their head.

271
00:18:32,040 --> 00:18:33,440
You have 15-page routines.

272
00:18:33,860 --> 00:18:38,420
So you want to trim those down to 15 one-page routines that people can look at, understand, and move on.

273
00:18:39,700 --> 00:18:41,640
So anyway, there's the debug chart.

274
00:18:42,060 --> 00:18:43,220
It's one of my favorites.

275
00:18:43,320 --> 00:18:46,500
Let's kick away from that and talk more about JIRA integration.

276
00:18:46,620 --> 00:18:47,000
How's that?

277
00:18:47,240 --> 00:18:47,860
Sounds great.

278
00:18:47,860 --> 00:18:55,180
All right, let's log out of this instance and log into this one, which is a different machine, different box.

279
00:18:56,520 --> 00:18:58,680
Actually, you know what?

280
00:18:58,740 --> 00:18:59,880
Let's just stick with this one.

281
00:19:00,580 --> 00:19:01,460
Let's close that out.

282
00:19:02,040 --> 00:19:02,780
Come over here.

283
00:19:03,360 --> 00:19:04,440
Sixth Sense has a desktop.

284
00:19:04,900 --> 00:19:06,820
Now, we mentioned some of the sensors earlier.

285
00:19:07,000 --> 00:19:10,280
So this is looking at my local host instance right here.

286
00:19:10,980 --> 00:19:14,180
We've got a little Jetty engine or Jetty server that runs locally.

287
00:19:14,880 --> 00:19:16,940
And I can look at – there's two different things we're going to look at.

288
00:19:16,940 --> 00:19:20,160
One is the sensor manager, and then we're going to look at the sensor task manager.

289
00:19:20,820 --> 00:19:26,220
So if we look at the sensor manager, this is everything I've got installed on this machine.

290
00:19:26,580 --> 00:19:28,160
I've got an ANT sensor in place.

291
00:19:28,280 --> 00:19:29,060
I've got Eclipse.

292
00:19:30,820 --> 00:19:32,020
Emacs is instrumented.

293
00:19:32,140 --> 00:19:33,380
Firefox, JIRA.

294
00:19:33,660 --> 00:19:34,240
You get the idea.

295
00:19:34,300 --> 00:19:36,140
I mean, a lot of different things going on in here.

296
00:19:37,820 --> 00:19:45,740
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.

297
00:19:45,920 --> 00:19:47,460
So I put the sensors down here.

298
00:19:47,520 --> 00:19:50,340
Now, a couple of these are enterprise sensors, like JIRA, for instance.

299
00:19:50,500 --> 00:19:52,800
This is not – it's not hitting my desktop.

300
00:19:53,000 --> 00:19:53,740
It's hitting a server.

301
00:19:54,580 --> 00:19:57,400
But in order to do that, I've got to go to the enterprise tasks.

302
00:19:57,820 --> 00:20:00,660
Let's go over there and look at what it looks like to scrape a JIRA.

303
00:20:02,140 --> 00:20:08,600
I have two different enterprise tools here, the subversion sensor and the Sixth Sense Dev JIRA.

304
00:20:09,300 --> 00:20:10,700
So let's go look at the settings.

305
00:20:10,860 --> 00:20:12,140
You have a set of properties, right?

306
00:20:12,220 --> 00:20:14,680
You've got to have the URL for a given JIRA.

307
00:20:14,760 --> 00:20:15,680
Let's copy that out.

308
00:20:15,680 --> 00:20:18,960
We've got JIRA user, password, Sprint 7.

309
00:20:19,700 --> 00:20:21,260
This is telling it where to go.

310
00:20:21,920 --> 00:20:23,460
And let's just verify that that's valid.

311
00:20:24,420 --> 00:20:25,460
Verifying it's good.

312
00:20:26,180 --> 00:20:32,480
You'll have a user map, which maps your JIRA accounts to your local Sixth Sense accounts.

313
00:20:32,720 --> 00:20:33,120
All right.

314
00:20:33,680 --> 00:20:35,780
So this is, you know, map point A to point B.

315
00:20:36,080 --> 00:20:37,920
And finally, when do you want this thing to run?

316
00:20:38,560 --> 00:20:40,000
Now, we don't want to run continually.

317
00:20:40,300 --> 00:20:42,160
You know, we're trying to keep down the load on the servers.

318
00:20:42,400 --> 00:20:45,020
So we generally pop up at midnight and run the task.

319
00:20:45,260 --> 00:20:45,480
Right.

320
00:20:45,980 --> 00:20:50,600
And as we were saying earlier, it's only reading things out of JIRA.

321
00:20:50,600 --> 00:20:52,300
It's not writing things back to it, right?

322
00:20:52,680 --> 00:20:53,000
Absolutely.

323
00:20:53,380 --> 00:20:53,700
Absolutely.

324
00:20:54,180 --> 00:20:58,080
So if we were to come over here and you were saying, how do we make a project?

325
00:20:58,640 --> 00:20:58,840
Right?

326
00:20:58,880 --> 00:20:59,660
I logged in here.

327
00:20:59,980 --> 00:21:01,160
Greg Burnell is our CEO.

328
00:21:01,620 --> 00:21:05,340
And I logged in as Greg because he's got admin rights on the production box.

329
00:21:06,060 --> 00:21:07,680
As all CEOs should.

330
00:21:10,540 --> 00:21:12,440
Yeah, that's a really good point.

331
00:21:14,200 --> 00:21:15,640
Let's ditch Greg.

332
00:21:17,780 --> 00:21:19,460
I actually hit the wrong box there.

333
00:21:19,460 --> 00:21:20,880
Yeah, I'm logged in as Greg on this box.

334
00:21:20,960 --> 00:21:22,480
I'm over here in my demo box now.

335
00:21:22,800 --> 00:21:22,920
Perfect.

336
00:21:23,040 --> 00:21:25,600
So I would come in to, I was in settings.

337
00:21:26,640 --> 00:21:29,720
You know, let me show you so there's no question.

338
00:21:29,840 --> 00:21:31,380
Somebody's going to want to do this at home, right?

339
00:21:31,440 --> 00:21:32,300
You're going to want to do this.

340
00:21:32,340 --> 00:21:33,060
So I log in.

341
00:21:34,280 --> 00:21:35,540
And here's my desktop.

342
00:21:35,780 --> 00:21:37,220
I'm going to come up to the settings link.

343
00:21:37,780 --> 00:21:39,020
I'm going to go into settings.

344
00:21:39,620 --> 00:21:46,100
And then over on the left-hand side, you're going to see, you know, my main settings, team, projects, attribution.

345
00:21:46,180 --> 00:21:47,500
We're dealing with projects right here.

346
00:21:47,680 --> 00:21:47,920
Right.

347
00:21:48,700 --> 00:21:53,080
So for a given project, one, he can see everything out there.

348
00:21:53,220 --> 00:21:56,120
Open, closed, number of sprints floating around here.

349
00:21:56,500 --> 00:21:58,660
But here's, you know, nice little wizard to walk you through.

350
00:21:58,760 --> 00:21:59,580
Let's add a project.

351
00:22:00,420 --> 00:22:04,640
So the project name is going to be the Cody Sprint.

352
00:22:07,640 --> 00:22:10,180
And start date, let's go with a nice calendar.

353
00:22:10,480 --> 00:22:12,520
Let's, heck, let's start it tomorrow.

354
00:22:12,880 --> 00:22:15,540
I fear it may end up more like a potato bag race.

355
00:22:16,200 --> 00:22:17,000
Well, you never know.

356
00:22:18,760 --> 00:22:22,940
The team will go for six, you know, you can be on sales.

357
00:22:23,080 --> 00:22:24,580
I'm going to have a, there we go, marketing.

358
00:22:24,780 --> 00:22:25,300
There you go.

359
00:22:25,440 --> 00:22:31,500
It's a, and for the tracking system, man, we can go for the JIRA.

360
00:22:31,800 --> 00:22:32,940
The JIRA is where we want to come from.

361
00:22:34,240 --> 00:22:36,820
So it runs through here, pulls the data out.

362
00:22:37,260 --> 00:22:45,400
Now, this particular box is a little bit off from the, actually, I hit the box I didn't realize I was hitting.

363
00:22:45,500 --> 00:22:46,800
We're actually doing this on production.

364
00:22:47,000 --> 00:22:51,540
So it's pulling from the developers in here how much time they work every day.

365
00:22:52,280 --> 00:22:53,160
Now, I picked the wrong team.

366
00:22:53,220 --> 00:22:54,060
I picked the marketing team.

367
00:22:54,100 --> 00:22:55,880
I should have done this dev, and it would have been even better.

368
00:22:56,220 --> 00:22:59,840
But the average amount of time for these people are 5.3 hours a day.

369
00:23:00,080 --> 00:23:00,300
Right.

370
00:23:00,560 --> 00:23:07,180
So for the team I picked, I can schedule them eight hours a day, but history tells me I'm only getting 5.3.

371
00:23:07,460 --> 00:23:08,340
So good luck, you know.

372
00:23:08,380 --> 00:23:11,280
Let's kick over to my demo box where I can get away with a little bit more.

373
00:23:12,440 --> 00:23:14,220
Let me sign out as myself again.

374
00:23:14,360 --> 00:23:15,460
Log back in as Greg.

375
00:23:16,240 --> 00:23:17,680
Because Greg's admin everywhere.

376
00:23:18,480 --> 00:23:27,200
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.

377
00:23:28,160 --> 00:23:30,720
On this box, we still can have sprint code.

378
00:23:31,920 --> 00:23:34,480
And we'll go with the same, you know, start and end dates.

379
00:23:34,480 --> 00:23:37,780
Don't really matter unless you, we do have it set up.

380
00:23:37,940 --> 00:23:39,500
The team's already booked for this time period.

381
00:23:40,340 --> 00:23:41,760
So let's go out a month.

382
00:23:42,420 --> 00:23:48,080
And we are changing that so that you could have the concept of a team that's multitasked for people that are bouncing around.

383
00:23:48,480 --> 00:23:50,180
And here, you asked how we got the team.

384
00:23:50,300 --> 00:23:51,160
This is the JIRA team.

385
00:23:51,500 --> 00:23:51,740
Right.

386
00:23:51,800 --> 00:23:52,360
That makes sense.

387
00:23:52,480 --> 00:23:57,680
Now, you'll notice on this instance, you're not seeing the choice of all the different source code management systems.

388
00:23:58,220 --> 00:23:58,360
Right.

389
00:23:58,400 --> 00:24:03,140
That's because on this instance, I've only got one system set up, which is the JIRA.

390
00:24:03,800 --> 00:24:04,000
Right.

391
00:24:04,000 --> 00:24:10,460
So if you're in an environment where you have five different JIRAs or five different products, we'll give you the choice.

392
00:24:10,980 --> 00:24:13,900
If we know there's only one, you know, why put the drop down there?

393
00:24:13,940 --> 00:24:15,040
We're just going to pick it for you.

394
00:24:15,140 --> 00:24:15,480
Right.

395
00:24:15,680 --> 00:24:16,900
Just to make it a little easier.

396
00:24:17,760 --> 00:24:18,820
So here we go next.

397
00:24:18,880 --> 00:24:21,900
It's doing the same thing it was before, calculating estimates and velocity.

398
00:24:23,720 --> 00:24:24,120
Yeah.

399
00:24:24,180 --> 00:24:26,100
Because it's a demo box, we don't have the time.

400
00:24:26,200 --> 00:24:27,000
So let's just say done.

401
00:24:28,000 --> 00:24:30,020
And let's go down here to Sprint Coté.

402
00:24:31,740 --> 00:24:35,500
And the first thing it's going to say is no tasks are on this project.

403
00:24:35,640 --> 00:24:36,780
Let's add some tasks.

404
00:24:37,740 --> 00:24:43,980
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.

405
00:24:44,580 --> 00:24:46,120
So in this case, let's pick Project.

406
00:24:46,800 --> 00:24:49,020
And let's say Project is Sprint 7.

407
00:24:49,840 --> 00:24:51,580
And there are the tasks that fall into this.

408
00:24:51,800 --> 00:24:52,120
Right.

409
00:24:52,120 --> 00:24:57,980
And it's another sort of area where you can map different criteria for pulling things in.

410
00:24:58,540 --> 00:24:58,980
Absolutely.

411
00:24:59,200 --> 00:25:00,080
Like we've seen in other areas.

412
00:25:00,460 --> 00:25:02,260
So there we go.

413
00:25:02,620 --> 00:25:05,120
Is there any, you know, we've made a run through the product.

414
00:25:05,280 --> 00:25:08,180
I've actually created a project for you based on JIRA data?

415
00:25:08,300 --> 00:25:08,740
That's right.

416
00:25:09,620 --> 00:25:12,280
Yeah, no, I think that's interesting stuff.

417
00:25:12,500 --> 00:25:21,060
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?

418
00:25:21,760 --> 00:25:27,320
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.

419
00:25:27,780 --> 00:25:34,080
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?

420
00:25:34,140 --> 00:25:45,160
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.

421
00:25:45,620 --> 00:25:45,900
Right.

422
00:25:46,060 --> 00:25:54,660
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.

423
00:25:55,420 --> 00:25:56,020
It is.

424
00:25:56,140 --> 00:25:58,400
I mean, you need to work with people that you trust, right?

425
00:25:58,460 --> 00:26:02,120
This is something that someone could use to, quote, unquote, big brother you.

426
00:26:03,020 --> 00:26:06,760
But if you're working with somebody that's going to do that, you should leave anyway, right?

427
00:26:06,920 --> 00:26:07,120
Right.

428
00:26:07,720 --> 00:26:10,980
I don't have time to sit there with a piece of paper and write it all down.

429
00:26:11,080 --> 00:26:13,860
Then I don't have time to look at it and extract the trends.

430
00:26:13,940 --> 00:26:15,680
I don't have time to copy it up from my manager.

431
00:26:16,260 --> 00:26:17,700
This does it all for you automatically.

432
00:26:18,080 --> 00:26:18,580
That's right.

433
00:26:19,000 --> 00:26:19,600
Well, that's exciting.

434
00:26:20,500 --> 00:26:22,940
Well, thanks for spending this time to show us this.

435
00:26:23,040 --> 00:26:23,700
It was pretty cool.

436
00:26:24,220 --> 00:26:25,440
I enjoyed talking with you today.