 I had a bit of a surprise when you saw the HP logo on the conference, hi Dean. Okay, good to see you again. So again, coming back, there's a few that were surprised. How many of you knew that HP has software products? Can I have a show of hands? Wow, we have quite a good representation. So I was thinking that probably you'd be surprised that we're here. Usually when you talk to people and you say, well, I'm with HP Software, they're going to say, really, HP does software since when? So in my case, for 10 years, I've been with HP for 10 years. And to start from scratch, my name is Victoria Voynichescu. I'm a product manager in HP Software. I'm here with Roy Neuriel, who is the chief functional architect for my product. And we have two goals that we want to accomplish today, hopefully very quickly. One is to make you aware that we have been doing Agile for a long time in HP Software. And it was an unbelievable story, and we have many things that we've learned from that, and we want to share. Roy has another presentation on Saturday about that. And the second one is that we have a pretty cool new product called HP Agile Manager, an Agile project management tool. It's been out for 15 months now. And not only is it new and modern, but it has great integrations with QC, the best in the industry, with HP PPM, and also with a whole bunch of development tools, IDEs, source control management, and build tools. So those... Oh my God. Oh, that's amazing. We have three people. Right. Because this is the new kid on the rock. We just want you to take a look at it, be aware it exists. We have a demo booth downstairs, and hopefully it will be appealing enough for you. So what we have in mind today... In my role, this is a role that I've been in for the last five, four years. But prior to that, I have been a developer, like many of you, I guess. You know, the telecom industry, real-time operating system, databases, et cetera. I've been a manager in R&D. I've been a key manager. I've been doing Agile for seven years, started off in small teams. Everybody collocated, picking notes, beautiful stuff, beautiful stuff. And then we realized that that doesn't work, and we have to scale it to large teams. And now in HP software, you know, thousands of developers. So I think we learned our lessons. And this product is a product that came from our experience. And it's also a product that we've been using to build it, right? So we use the product to plan and track our work as we are building the product. So a lot of it went into this. The way we plan to do it, I don't know how good the resolution is, so and so. Okay, so I'm going to talk about the regular Agile capabilities and the cool stuff there. And Roy is going to talk about the integration with the dev environments and what you get from that because it's a new fresh perspective to add the Agile project management tools. Maybe before we start, a short question. How many people over here are, I don't know, a program manager or project managers? If you can raise your hands. Okay. How many people are from the development side? Developers, developer managers. Excellent. Cool stuff. The others are, I guess, something in between, right? So QA guys or other managers that, okay. Right. So the main capabilities of the tools are obviously triggered a deep persona that Roy just mentioned. So in the product backlog, which is where we start our journey, we have a hierarchical view of the work on things, features, and then user stories or defects. So you can see here in my backlog that I have a list of themes. For each of the themes, I have the level of completion in the backlog. And as you mouse over all this stuff, you're going to get a lot of summary information. In this case, you see the number of user stories in that particular theme. What is the total defects, the total story points, how much is done. And here, just by clicking on this link, you're going to get to the actual features that are part of that theme. And for the features, you're going to see pretty much the same level of information. So if you're ever done MI with these particular items. Just Victor, I want to share one more thing with the audience. So I don't know how we used to have our products that were not that appealing from a UX perspective. I can share with you that for that product, we have a dedicated UX team that is working with us and making sure that our product is much more intuitive for customers. It's really easy to start and to join and benefit and find the functionality in the product. And again, we will be more than happy to get your feedback if something is missing, or if you see that the functionality is not intuitive. Overall, the feedback is very positive from what we're getting from our customers. Sure. If we get to the backlog items, the user stories or defects that are part of the backlog item for this product, I can see that I have a lot of information for them. But my main purpose in this view is to look at my new items and start assigning them to a new release. On the run side here, you have your releases. And the cool thing about these releases is that you have not only the start and date, but you have your estimated capacity. If you're going to use the same themes that you used in previous releases, it's pretty much the same number of sprints, etc. You'll know how much stuff you can pull into this release. And pulling is what you do. You'll just click on an item and just move them to a release. This is how easy you do, and obviously you can do bulk assignments, etc., etc. And as you do that, you're going to see where you are. Like in this instance, for instance, I see that I'm over. I've over planned this release. I put too much items in it. But this is how much of my release it's already done at this point in time. So if I go to the release itself, I'm going to move into a different tab, which is this time, the Release Management tab. And what do I have here? I have my release backlog. Again, for each of the items in the release, a lot of information who's working on them. For instance, in this case, I have all my new items because what I'm trying to do here is to plan the release by pulling items into different sprints, different themes. And again, the interface is very flexible. You can move from sprints, themes. Notice very importantly, I have a bunch of applications that I'm working on and I see them all because I'm in a management position. But otherwise, my team members would only see the application that they're interested in. Data segregation for multiple applications within the same database schema. What is the purpose for that? To show the dependencies across all of these user stories. Many of you are working with dependencies. Number two, to be able to show in the dashboard releases that are composed of items from various applications. Our own product is made out of three applications. We show the release as items coming to the release from various applications. So again, here we have these items. I'm going to look at the ones in New State. Obviously, I can rank them according to priority. And on the right-hand side, I have my teams. For each of the teams, I have obviously the projected velocity. I know how much work the team can do. And I'm just going to click and drag an item and assign it to a particular team. And you can see already, I have some items assigned to this team. And I'm just going to go, obviously, in the real world, you're going to see that teams are usually a little bit overallocated. You're going to get warnings and exceptions when that happens. But this would be what you do to plan items from your release into your sprints and themes. And with that, you know, we can move to a particular sprint and theme. In this case, let's say that we are in Spring 7 for Team Blue. And we already see the backlog for this particular sprint for my team. And on the right-hand side, pretty consistent in types of view, now you see the team members and their capacity. And how much of their capacity. Like for instance, this team member is definitely overallocated. I put too much stuff on him. But the other ones have capacity. So if I have an item that I want to assign to somebody, I click and drag that item just like I did before. I see how much of their work is already finished here. And for each of these individual user stories or defect on the bottom of the screen, I'm going to see the tasks associated with them and the level of completion and how much time has been spent on the task. And also the acceptance tests that have been created for each of these user stories. And when I actually work in that sprint, I can have a different view of that sprint, which is definitely the task board. Everybody works with task boards. You know how to do task board. You know, for instance, here I have all my user stories, the level of completion for each one of them. And on the lane, I have all the tasks associated with the user story. It's very easy to create new tasks. It's very easy to do a lot of actions for that particular user story. So let me show you how, for instance, I'm creating a new task or maybe two. Let's say that I'm creating a new coding task and then I create a new validation task. I'm going to try to be very, very fast here. And as I create these two new tasks, they're going to show here when I can go in and assign easily this task to a particular member of my team. Let's say that I want to assign this task to one of my developers. I can color code this task to show that it's a development task. I'm going to say that this is the number of hours that I want to work on this task. So as I do that, then as I move the task into, let's say, in progress and start working on it, I'm going to come here on a daily basis and say, well, today I spent maybe three hours, four hours on this task. This is how much is remaining. And the level of completion of user story is updated with all the time updates. So when all my tasks, for instance, are completed, I move them into the completed state. As each of the developers and testers are, sorry, doing their work, I'm just trying to move very, very fast on this. Oh, let me just assign this to somebody because it's an orphan task. How do I, I'm sorry? Yes, it's the members doing that. But what I wanted to show you here is I move all my tasks into completed. There's a built-in definition of done and it's a very cool one because it says, you know, your task has completed. Is this user story done? And I'm going to say, sure, my user story is done. But there's stuff in the back end that says, hey, you have user acceptance tests that have not been run or have failed. You have open defects. Unless you override your definition of done. And soon enough, you'll see that we have also stuff coming from development, which is unit test coverage, pass rate that is built into the definition of done as well. But one more comment. I can tell you that this, in our R&D, we're using that view when we're doing our stand-up meetings. And basically we are playing with those tasks around. And as a developer, I can come and say, I need more time for that exactly to do what you mentioned. At the epic level, let me show you how I'm getting there. So we're just trying to make this as short as possible because we only have 15 minutes. Sure. Yeah. Through the states, yes. Through remaining hours to zero. It assumes that you just don't want to go through. Okay. So I completed all the remaining hours and now I'm moving to complete. Is it going to be moved to the complete? Yes. There are teams that are not using this, I mean, the time estimations or the time work. So you can put it at zero and then you can actually run through it. There are teams that are not using those estimation in order to, I mean, it really depends how the team is working and we wanted to give the flexibility for the team. So I hope it answers your question. If not, come later on and I will answer that. I wanted to show you now. And this is happening. So as the teams do their own, you know, spring planning and pull stuff into their sprint, et cetera. At the end of the planning session, you have a PMO who's looking around and saying, what have we done now? Like, do I know, like each of the scrum masters know what's going on, but do you know the big pictures? And that's why we introduced what we call a planning board. And let me just move the resolution here so you can see more. So in the planning board, we basically have lanes and columns and colors as a third dimension. And you can show whatever it is that you want to show in the planning board. You customize it. You save it as a favorite. But what an example of what you'd see, you know, for each team, you'd see the work that's allocated sprint after sprint after sprint. And you can see here defects as well as user stories represented in different icons. But here, for instance, on the third dimension, on the color dimension, I chose to represent my teams. Let's say I can represent priorities. I can represent features. I can represent whatever I want there. But it will give me an idea of how good my planning is when it executed sort of siloed in different teams versus what I want as a PMO of the scrum of scrum. Right now, if I look at it and say, hmm, look, I'm stretching this feature over so many sprints. Why do I do that? Why don't I want to finish this feature sooner? So maybe I can pick a piece of work and move it to an earliest sprint or move it to a different team just so I make sure that I'm completed whenever I want to get this completion. This is one of the features the most used by our teams just because it gives them the ability to do the QNAP at the end of the planning session in the spread. Another cool thing that we do, and it's related to the same planning and execution and tracking, is the storyboard. This is basically Kanban. What we do here, we give you the opportunity to customize your lanes and your board. For instance, here you see that while we added two new lanes and in the planning session we have defining the specs, reviewing, doing the usability review, etc. Then this you can customize, you can define the work in progress limits just like you saw in the previous session. And this board is customizable at the team level. Each team can pick whatever it is that they want to see in the states in the board. But the idea is that ultimately they're all aligned across the same metrics. So somebody, a PMO for instance, can report on the teams consistently because they're all aligned on the same metrics. And the beauty of it is that we can execute both in pure Kanban where you don't have sprints anymore, just one release with flow of data. But we also execute in Scramban. So each sprint you can still execute in your planning board and for each of these user stories, if you open the user story, you can still break it down into tasks and you do the things as you always have done that. So this is a thing that will help you with your customizations. Everybody wants something customizable. Another very cool feature that is related to agile execution is the sprint closure. You get to the end of your sprint. It's the last day you run your retrospective. What you want to do as a scramb master, for instance, is to see, OK, what have I done this sprint? And you can use it throughout the sprint, not just at the end. This is my planned work, right? This is what I took on at the beginning of the sprint. How much of it is done? How much of it is still to be completed? And this is what I've added throughout the sprint as I discovered more work that needs to be done. And this, I'm looking at the status of my defects. I'm looking at the status of my user acceptance tests. How many have passed, failed, or I haven't even done them. I'm looking at the completion of my user story. So I have a big picture of everything that happened in my sprint. And as I close my sprint, I list in the retrospective the things that went all well. And I can list here a multitude of things, the things to improve. But more so, I can create action items directly into my retrospective, a list of action items, like you see here on the right. Some are done. Some will carry with you sprint after sprint. And also very interesting, if these action items mean that I need to write some software, for instance, for my continuous integration, I can turn them into backlog items and they will be allocated to the next sprint automatically. So more so, let's say that I'm here at the end of my sprint and this is showing me the work that is not completed. What do I do with this work? Right here in the sprint closure, I have the opportunity to pick each of these user stories. And as I pick them, I can roll them to the next sprint. I can unplanned them all together from my release or sprint. I can split the user story and keep whatever's done here and move the unfinished task to the next sprint and I'll finish them in the next sprint. So I have a lot of opportunities to clean up my plate. And as I said, you don't have to do it only on the last day of the sprint. You can look at this throughout the sprint and see what you need to do. It's just a very good way of viewing your work during the sprint. So I'm already late, very, very quickly. I'm going to pass this to Roy to show you more on the integration with the development tools. But just so you are aware, we have a customizable dashboard and a whole bunch of widgets out of the box that you can add to your dashboard, you know, broken into applications, into widgets for the defects, for Kanban, for sprint, for whatever it is, as you can see, this is pre-existing reports that you can add to your dashboard and more so, you can create your custom graphs and add them to the dashboard. And with this, let me pass it on to Roy to talk to you about the development stuff. So it's going to be really quick because we really don't have a lot of time. And you must be hungry. And you're probably the only one who is holding you to eat your lunch. Just two things that was important for me to mention. That solution is basically a SaaS offering that we provide. We shift our development process from a waterfall, we move to Agile, but when we move to deliver that software as a service, we move to continuous delivery. And we made a big change inside R&D in the way that we develop software. I would be more than happy to share it with you after that because we don't have a lot of time. But the main point that I want to emphasize is that we are getting the feedback from the customers and we can deliver new content on very short cycles. So we are looking forward to hear your feedback. A few things that might be very interesting for you as a project manager or also as a dev manager. You take the time estimation that you mentioned, you see the progress that went during the spring, but do you really know what's going on down there, what the developers are working on? So basically some of the capabilities that we are showing here give you a full visibility on what's happening in your project. So what you can see over here, that's a release summary that shows you how many user stories and defects were delivered, how many code coverage of your unit tests you have, and the success ratio. Where's the scroll over here? We synchronize all the user stories and defects into QC. We bring back from QC the direct coverage of user stories and defects. So no matter what testing you did, if you continue to leverage this in agile and we'll show you into agile manager the direct coverage for everything there is. So it's really hard to show that right now. I cannot scroll down. However, what you can see over here, that's what we delivered. You can see over here what really we worked on. So you can see the defects. So basically what you can see over here, those are the defects that we delivered in that release. You can see the code changes. So what you can see over here, which is very interesting, you can see how many user stories we worked on, how many defects we worked on, and how many tasks that were not assigned the developer worked on, how many code they committed that they didn't link to either a user story or a defect. And this is something that you probably would like to check and understand what the development team worked on. It can help you to make a better risk on what you need to test and what activities you need to learn in order to understand what the development team are working on. In addition, you have an overview of the build status and you can drill down into it and see what really happened during the release. So you can see over here all the pipeline, all the builds that were run during that time frame. And you have a very interesting view of what happened. You can see per each build how many defects, how many user stories, and how many code that wasn't linked to a real defect or user story. That actually goes towards implementing the story and some for fixing defects. But there's the rest of it, which is of interest to everybody starting with the dead manager, K-manager, chemo. And refactoring is a wonderful thing in agile. But if you refactor and you don't know how to test that, because there's no test cases associated with it, the risk is very, very important. So that's why we're showing you, maybe it was refactoring. Maybe it was, you know, sometimes you don't really finish the story by getting out of the street. And the person there in the next street, we're going to check in some more code. That's what we want to provide visibility into. If there's code that's not necessarily associated with anything, you should know about it and you should follow up with it and see what you want to do. What action like that you want to make. It's a matter of time to explain you the concept. We are connecting all the dots of all the artifacts that actually happened during the agile development. The code, the user story defects, the test activities that are done. And we can show you, slice and dice all the information and give you a better visibility on what's really going on and traceability of what's really going on in your development project. This is just one of the capability. We don't have a lot of time. Can I start working on right now if I want to do functional testing? But also, what is my unit test coverage and pass rate for this particular user story? If it's 20% and pass rate is zero, am I going to bother even taking it into functional testing? Or am I going to discuss with my development and maybe do a better job of that? You can see who are the committers, who actually made a change. You can actually see the real change. And from here, we are connected to the source control and you can dive into. I will not open it now for a question because we need to, and I don't want to hold everyone from... But I'm here. I'm not going to lunch. Anyway, so that was really fast to show you. We don't have a lot of time. We encourage you to come to the booth and to see a full demo. We'll be more than happy to show it to you. If you have any question or suggestion, both Victor and me are here until the end of the conference. And we encourage you to come and talk with us. Have any questions that you have, we're here. We are excited from that product. We really love it. So we hope that you too. Thank you.