This post started as an answer to one comment posted by Harry, but then I thought it was better to publish this in the main-stream, so it does not get lost in the comments section that currently is not being used that much.
XPM & qControl
Harry: How does XPM relate with qControl
[Note: qControl is the tool that we currently use for issue-tracking]
XPM supersedes qControl. In truth XPM was developed from qControl but we changed the name and not just the version because in many ways it is a different product. It has a more flexible/open design, a complete redesign of the UI, etc -. We will stop using qControl soon.
XPM & SCRUM
Harry: How can we merge this technology (XPM) with agile methodlogies (ie SCRUM)?
XPM is not tied to a specific methodology though it is influenced by the methodology that we follow in-house to track our projects, so it does support an agile-development process. The issue-tracking module in XPM really allows you to use the methodology that you want (though you will not see labels that are related to that methodology, i.e. in XPM we have a "work-item list" insted of SCRUM'S "backlog").
Our idea was to create something that is open enough that it supports different scenarios/methodologies. If your team follows SCRUM you would need to do some mappings between SCRUM concepts and XPM's - for example in SCRUM you might define that a task in the backlog has a low fidelity (i.e. it is a 'vague wish') that would prevent this task to be part of the 'sprint-backlog', until it is properly defined etc. In XPM you would handle this with different statuses of the work-item (i.e. if it needs to be specified it will be in status 'To-Specify', if the functionality is not really clear and cannot be specified yet because it is a vague wish it would be in status 'To-Review' etc.. The list of possible statuses in XPM can be defined so the descriptions and the steps are up to you)-.
Similar to SCRUM, each item in our work-list is really anything that needs to be done (i.e. software functionality, marketing, non-functional requirements, etc). You can define work-item types and categories to classify them in case you want to assign the work-items based on that. We do have the idea of priorities that can be used to define what's in the sprint or what's in the product backlog.
XPM allows all the team members to participate and gives different rights to different roles - so for example you could have the Product Owner and Business Owner or the Scrum Master (those would be your roles) with the ability to update priority but do not give that ability to Scrum-Team-Members.
We also have the idea of releases that include all the Work-Items that are ready to be deployed depending on the environment (i.e. release for testing, release for QA, release for Prod). We do not associate the work-items with a specific sprint but we could do so and maybe it is actually a good idea, because currently we know what we deployed and when, but many times the work-items that are reopened and maybe it is interesting to see by cycle which work-items were new and which ones re-opened from a previous sprint/cycle.
I never participated in a SCRUM team so personally I'm not familiar with the tools they use. I know that there's probably nothing that prevents you from following this methodology using XPM but I do not know if there's anything that would facilitate its use that we don't do (i.e. A very important part of the SCRUM process is the backlog grooming, so maybe assign tasks to different team members depending on the type of task (marketing plan, test, functional-spec) is something that is very important for a SCRUM-tool and XPM does not have this ability. Currently XPM allows you to route tasks depending on the status (i.e. if the item has to be specified it goes to the team member that knows how to specify, if it has to be programmed it will go to the default developer, if it has to be tested to the default tester, etc .. and of course the defaults can be overruled).
I you are aware of features that a SCRUM tool 'must have' and you want to share that with us, we will be more than happy to consider them and if possible include them in our initial release
XPM & The Gaps
Harry: I have been thinking about how I can improve my own PM tasks, but I always end up needing a tool that is either unavailable or not cost-effective. I am hoping XPM can fill the gaps.
We felt the same way and that is why we were convinced that we needed to build our own tool.
The gaps that we experienced the most were the gaps between the methodology/concepts to the actual practice using the tools available. In the sense that currently our team members need to work and then go to QControl (our current issue tracking software) to record on that they worked (i.e. a developer programs an issue and then goes to QControl to change the status of the issue to indicate that it is completed, etc).
Everybody in our team reports hours in qControl but we do the value-analysis in MSProject so we need to export the hours-reported in qControl and enter it in MS-Project to be able to have status reports regarding the plan. We need to keep these two tools in synch so that MS-Projects has all the issues reported in XPM and so that XPM has all the dates/information that is calculated by MS-Projects.
We write specs in MS Word or in the wiki and then we manually indicate the link to the documentation in the issue. We have some information in qControl (the tracking notes) and some information in the documentation and sometimes we need to integrate or maintain both in synch.
There are lots of tools to do different parts of the work but no real integration to become one seamless task to you our daily job.
To improve our methodologies and manage better our projects we need information, but we needed to find a way so maintaining that information did not become more costly than the value of it. For that we needed to make it easy for every team member to provide the information.
We wanted for every member to provide all the information the team needs right from the place they spent most of their effort. If I'm a developer, I work on my KB, that is where I code, therefore right from there I should be able to see my task-list, to indicate when I’m done, commit my changes to others and from his effort the system should be smart enough to know which issue is ready, which objects were changed for that issue and how long it took (or at least suggest it). We were able to do all this in XPM thanks to the integration features in XML. The integration with Genexus and with the GXServer for us are one of the best features of XPM (even though you can use XPM to manage a team using other development tools, as you can use any issue-tracking tool).
A similar thing happens with the project managers. One of the main tasks of the project managers is to write requirements, specifications and other documents. So in this task there two main objectives combined write and share. Somehow it seems that those objectives are mutually exclusive. Great tools to write like Word are not very good for sharing and collaborating in documents. Tools like the wiki that are great for collaborating are not that great to write. So again integrating we want to have the best of both works. We want to be able in write in powerful word editor like MS Word but publish in tools like the wiki. So we are planning in adding the ability to 'wikify' a document automatically so you can write the documents in MS Word and let XPM “wikify it” by creating automatically the wiki-page (or pages) and link each work-item with its wiki-page.
Basically we want to integrate, coordinate and track all the work that we do from the place we are more comfortable in (or we spend most of our time). For sure there are more gaps that we want to bridge, and we hope to do so in the future (i.e. the process of going from design/diagrams to specs/work-items). Also in this regard we welcome any ideas that you might want to share :)
No comments:
Post a Comment