 Hello everybody. This is back-to-back presentations. Maybe the only time during the conference, so I have a half hour, so this will be a bit of a lightning talk, but I'm going to keep it high level for that reason. Hopefully a while of time for questions as we go, or at the end, but if not, you can meet me pretty much the rest of the conference anytime. So I'm Steve Wolf. I'm with Rally Software, and I'm also channeling a partner of mine, a colleague of mine at Rally named Larry Maturoni. Is anybody here familiar with Larry and Larry's research work on agile metrics, agile analytics? Well, I will give you a little bit of an insight into what he's working on as part of our research efforts and how we're looking at helping teams improve with agile. Now one thing I would do want to say is that we are working at Rally on what we call a performance index framework, and this is what Larry's work is largely based on. And the basic idea is to, we could talk all we want about how to measure team performance, but what we're trying to do is do research with our large number of customers around how they're performing, looking at their data and coming up with key outcomes, key metrics that we can use to help all teams using agile improve. So the question is why? Why do we want to measure? Why do we want to see how we're doing at an agile level? How many of you are familiar with the saying culture eats strategy? Has anybody ever heard that one? Basic premise, no one's heard that one. The basic premise of that is that no matter what kind of plans you lay out, no matter what your strategies are, the cultures of the people doing the work is going to really dictate how well that ultimately goes. If the teams aren't motivated, if they're not engaged in the work, I wouldn't say they're going to purposely sabotage it, but the effect will be that you're not going to have the outcomes that you're ultimately shooting for. So it's important that when you look at measuring agile, because it's such a team oriented approach to getting software developed and done, that you build these measurements with them in mind. In fact the whole idea here is that give them measurements to help them complement what they already know, put into terms that they can now see and visualize how am I really doing these insights that I have? Are they working? Ultimately let them make the decisions on the ground. We empower agile teams. We give them business ownership, we give them responsibility for solving customer problems directly. We need to give them the measures now to see how they're doing with that. So that said, there are some ways that you can misapply agile metrics. We call them the 7 Deadly Sin. Some of this is the outcome of Larry's work that I mentioned earlier, as he starts to look at some of the bad practices as well. We've all heard about the dark side of metrics. What we're trying to do is avoid that and give you a little bit of a break.