19. Which one is yours?
XPM Lite
XPM Standard
XPM Premium
20. Thank you
Laura Aguiar
laguiar@genexususa.com
#XPM
xpm@genexususa.com
http://www.genexususa.com/xpm
Editor's Notes
XPM is a project management tool that was developed inhouse by Genexus USA to improve our project management practice
Since this presentation is about tools it is important to think about “when do we know a tool is good”? And in order to know that we really need to know more about the problem we are trying to fix (click) A tool needs to help me achieve my final goal but it needs to let me do it in the right way in order to be good.
Talking about good tools… in the GeneXus community we are lucky because we have the best development tool out there. Not only it allows us to do our goal – which is develop applications – but it allows us to do it in a very productive way. Benchmarking numbers indicate that we develop 5 times faster and maintain 20 times faster than with other development tools
So, if you see those numbers and you use GeneXus, you probably can’t help but to ask yourself “is that realistic for me”? How fast are we developing with Genexus? We – in Genexus USA- are no different and we asked ourselves this question and we think the numbers apply to us. Thanks to GeneXus and a team of more than 17 years of experience with it, we develop much faster than our competitors
After that the question that follows that is… how do my projects compare? It was this question – or the answer to this question - 3 years ago, that worried us and prompted us into action. Back then our projects were not even close to 5 times shorter, or 5 times cheaper, or we were making 5 times more money than everybody else. We had in our hands a tremendous advantage – we were 5 times faster than anybody else while developing - but we were not making the best of out of it.
All our projects had a similar curve like this – we were super productive during development, but all the other phases suffered. Very early in the process we were “almost done” and it took us too long to complete a project. We did a lot of analysis back then, and we want to share what we identified as our problems, because it helps understand some of the reasons behind XPM.
Our projects start normally with a Requirements Document that defines the scope of the project, and a project plan that defines the calendar and the budget. So to get started we had to interact with 3 different tools: Word – to create the initial requirements document that the customer signed MS-Project – to summarize the tasks described in the document and estimate them, so we could provide a budget and estimated timeframe for the project An issue tracking system – where we define again the tasks so they can be communicate and assigned to the team. We also needed to parse the document, so each person could focus only on what was relevant to them This initial setup was time consuming – a lot of copy & pasting - but it happened only once per project, so we did not think this was a big issue in itself. What was a big issue was that our tools did not help us in keeping things updated. All the back & forth about requirements – between developer questions, analysts clarifications, etc. were recorded in the issue tracking so they were mixed with other audit information of the task in the issue tracking. And since nobody likes to do the same work twice, most of the time once the issue tracking was updated with last decisions, the final specification the document was not… therefore our documentation that initially was a good one, started to get outdated pretty quickly.
This was an issue because when the tester got in the picture, he needed to get information from two different sources Read the documentation in word for each task assigned to him Read the history of comments to get the most current version of the specs Many times things got lost and testers reported issues that were not bugs, they just got the old version of the requirements. This was a source of delays and frustration. Once we started testing, the other reason why things started to get delayed was also related to the mix of many tools that did not integrate: Testers reported issues in the issue tracking system The manager had to bring those issues into the plan in MS-Projects so right prioritization could be done between fixing bugs and continue with the original scoped features, once things were re-organized, assigned, etc. the manager had to reflect that into the issue tracking so developers could know about the new tasks and priority changes. In order to prioritize, and also to provide customer feedback, the manager also needed to know how the project was doing according to the plan, so now we needed to consolidate into MS-Projects the information of hours reported in - yet another system -, in order to get the advance indicators from MS-Projects. This phase included a lot of manual work consolidating information from different sources – many times this was not done as frequently as it should and we learned about problems when it was too late…. Our manager was putting a lot of hours in the project, but not getting expected results.
When hitting UAT things use to got more complicated because now we need to manage different environments that advance in parallel We’ve been using GXServer since the day it was released it is a great tool that has made our lives so much easier and now handling versions and collaboration is so much easier than before. But the server does not solve automatically the problem of promotion – in the sense that if we have 2 issues in the test environment and one gets approved and the other is not – the server on its own does not know how to handle that. Somebody has to go in and select which objects can move forward to the next environment and which ones have to be stopped there until fixed. So now, we had a new role, the “gatekeeper”, which was somebody from the development team that dedicated a lot of time to this task – keeping the environments updated and keeping track of what objects were ok to be in which environment in an excel spreadsheet If the customer had to comply with regulations like Sox in regrads with their environment management, then the gatekeeper had to use also the customer’s tools which basically duplicated the effort. When it was time to deploy we did not had any tools to support that – except another check list in excel.. The manager was still dedicating a lot of time moving information from one system to the other – now with additional tasks related to promotion and environments, and bugs reported by users from UAT – and managing expectations because at this point typically there are a lot of things that users want to change from the initial scope and the manager had to see how to squeeze that into a project that very tight on deadlines – if not late already
At the end of the day, things did not fit together and we felt like if we were hammering a screw All the tools we used – individually – were good, but it took too much work to make them work together We still managed to complete our projects successfully, but at the cost of low margins and high human cost. We needed something that allowed us to work in a more organized and professional way.
So that was back then, and our answer to all those problems was XPM.
Now many things that we do are similar – stepwise- but they happen automatically For example our projects start pretty much the same way with a project plan and a requirements document But now, we automatically xpmize the requirements document and that creates the tasks in XPM with the corresponding documentation associated. Once we have the tasks in XPM we download them from MS Project and we work on our plan, when we are happy with it we impact it automatically into XPM as well. Because now all of this is automatic we shorten up the time it takes from the initiation documents to the time when analysts and developers can get involved. When we xpmize the document, we can choose if we want to do it in Word – as an attachment to the workitem – or if we want to publish it automatically in a wiki. The wiki for us has proven to be the easiest way to share and collaborate on the documentation, so now the developers update the documentation when a decision is made and therefore we reduced the number of incidents reported from testing due to poor documentation.
How do we improve our ability to organize the work while managing different conflicting interests (develop new functionality, fix bugs, add modifications that customers want, etc)? With a (work)List What is so special about this list? There is only one list. This list includes EVERYTHING that needs to be done from the beginning to the end of the project, since requirements till deployment. XPM has the planned tasks and the issue-tracking with incidents reported from end users in the same list, also all the tasks that need to be done in regards to deployment (the old check list in excel) or tasks related to gather documentations, etc.. Every task that will consume hours from the team is in this list. The list is highly accessible. Everybody interacts with the worklist from their natural environment with minimum interruptions. Developers will interact with their worklist from within the GeneXus IDE – they can see their tasks, report the hours it took to complete them, access the documentation, everything without having to get out of the development environment. We also have a windows application that pretty much can be used by anybody that does not have a “natural” environment. The manager can interact with the list from MS Projects, etc. Because interacting with the list is a natural thing we get to the next good thing about this list which is that the list is That it is always Current , because as soon as a new incident is reported it becomes part of the list, as soon as somebody finishes a task it is updated in the list, etc. And when we say “current” we don’t refer only to whether the task is there or not, we are talking about all the information that the tasks implicates: its status information, its documentation, its estimation, real hours that it has take so far, etc. And because we have *all* the information centralized by the worklist, and it is current, we have all the information we need to prioritize right there, which makes it much easier, and priorities are reflected also in real time. This allows us to see how we are doing and adapt our plan much quicker than before which allows us a process that follows the incremental development that we do with Genexus.
Before we spend many hours compiling data to get really little information. Now, thanks to XPM now we easily can access the information, it is there when we need it and the information is relevant and it is complete – with looking at the project in XPM we can easily see how we are doing, understand if we are off track and take corrective actions. Probably the best way for you to see about this is to see an example… (Demo) More information and more transparency builds up trust in the process. If later down the road there are things that delay the project, customers will be much more understanding because it is not like they learn about the problems the day before we were supposed to go to production. This information and transparency allows them not only to be aware, also they can participate in the decision – Thanks to this our services are more professional, and the manager work is more focused on the decision making and less focused on information gathering. The manager can manage the team, make decisions, work priorities with the customers, etc. so they can focus on what adds value instead of compiling and copying and pasting information
When is time to start working with multiple environments, XPM also makes our lives easier… XPM Premium includes environment management So it integrates with GXServer in order to associate the GeneXus objects with the tasks that originated it. This expands the information that we had in our worklist, so an XPM workitem not only knows the requirement, the plan, estimates, etc. but also the GeneXus objects associated with it… so now we know for each requirement which GeneXus objects are involved.. And now when a tester approves an item, XPM can select automatically which objects can be promoted, and if the tester rejects an item XPM will not allow those objects to be promoted until fixed. Now we can finally say goodbye to the consolidated-manager or the gatekeeper… basically that person whose role was to keep track of objects that needed to be included in each release, create the version in the server, do the merges, etc. Now XPM talks with GeneXus and the GXServer and all this is done automatically – the Build KB can be created automatically, and it can be specified and compiled automatically every night as well. When we have a list of tasks that we want to promote to do a Test Release, XPM will automatically promote the GeneXus objects to the test environment, it will rebuild the installation – if there is a reorg it will create a backup of the database and then run it automatically – and will let us know when it is done…. So managing environments is something that happens on its own now thanks to XPM And as extra-points, because we have the link between the GeneXus objects and the requirements, if an object is modified we can get the list of all the requirements that use it, and therefore we know what needs to be retested. This facilitates the testing and give us more confidence when it is time to make a decision on whether to make a modification or not (i.e. will we have the time to re-test everything that could break potentially?)…
At the end of the day, because all the pieces fit, we managed to get improved customer satisfaction – because now they have more information, we are better in meeting deadlines and they can participate in the decision making since early in the project We have a high productivity from start to finish And our team is happier – because now we can plan deadlines that are realistic and we don’t need to run as much, plus we get to focus on the tasks we really like, those that add value – whether it is developing, or testing, or managing – we spend most of the time doing those things and very little in administrative tasks
Not only we are more productive,, we also improved. Because now we can identify our problems – and we have the information to learn about them -. And when we do, we can share that knowledge or encapsulate in templates, so when one project manager learns everybody benefits from that knowledge.
If you have to choose a tool to manage your projects You can use Excel – but it is not designed to help you in this type of process, and the benefits will be lower than the cost, as there will be a lot of time spent in compiling information and making sure it is correct You could also have a set of tools that work well for a specific part of the problem – like an issue tracking, MS-Projects and some document sharing tool… and you would be better off, but still doing a lot of manual work, like we were 3 years ago On the other hand, you could use a tool that was designed specifically to manage software projects, and thanks to XPM have a highly productive process from start to finish – which makes it the perfect complement to GeneXus.
There are 3 flavors of XPM Lite – includes the list management, documentation, hours report, etc. XPM lite is targeted for projects that benefit from better organization but don’t do estimates. This version includes the integration with Word, Genexus and the Wiki Standard – on top of what Lite includes, this version focuses on estimation and planning – and control of real vs estimated. This version includes the MS Project extension. Premium – adds integration with GXServer and Environments management
