If you want to use Yoxel’s product/project management capabilities to plan and track your agile iterations, but are not quite ready yet to switch to Yoxel’s request tracker completely then you should download and install this module.

In general this module allows synchronization with any external web-based bug-tracker (Bugzilla, GNATS, Mantis, Retrospectiva, Jira, FogBugz, …). Besides allowing you to plan&track agile iterations Yoxel will enable GANTT and burndown charts, custom fields, customizable HTML, PDF, Excel reports and various useful dashbords, all using the data from your favorite bug-tracker.

Here is how the synchronization works:

  1. Yoxel connects to an external web-based bug-tracker over HTTP. This way Yoxel can actually connect to your remote bug-tracker, not necessarily running on the same server.
  2. For each bug/report that Yoxel imports it first downloads an HTML bug-summary page. (Here is an example of a bug-summary page: https://bugzilla.mozilla.org/show_bug.cgi?id=341380)
  3. Then Yoxel parses the HTML page of that bug/report and translates it into internal format, then adds it to its database as an external request (a special type).

To enable the synchronization with your external web-based bug-tracker (Bugzilla in this particular case) you need to download an additional module that includes:

  • A modified pear/HTTP/Request.php class to enable the HTTP connection
  • An HTML parser that understands Bugzilla bug-summary page format and translates it into Yoxel format.

The XBTS module is available for download here. After downloading extract XBTS.Bugzilla file and follow the instructions: ‘gzip -dc xbts_v1.17.tgz | tar xvf – XBTS.Bugzilla


This is my 3rd post in the series on “agile product management with YOXEL SW”. The previous two posts were: Release planning with YOXEL SW: Starting a new release , and Release planning with YOXEL SW: Collaborative planning session .

After a successful planning session an iteration plan has been created and agreed upon by all release members, the implementation phase of our project/release/iteration has started.

Thorough planning is very important for the success of your project but that is not all. We all know that software development is not manufacturing but design work and usually things do not go exactly how you planned, you are designing and you are uncovering unforeseen challenges along the way. The important thing is to always have a clear picture of your project status, know if a problem has occurred, what its impact is, and be able to react promptly. By having a shorter term for your incremental release, by having done detailed prioritization of the tasks in the plan (down to the exact order 1,2,3,4,…), and by using estimates you have already tried to minimize your risks. The goal now is to stick to your short term plan and learn as you go.

I believe that being able to track and monitor your project/iteration health in real time, and collaborate pro actively is not less, or even more important than being able to create a good plan. By “real-time” I mean that any time a developer or a tester changes status of his/her request (fixed, % completeness, verified, more_info) the project status reflects that immediately (updates the project summary, re-computes timetables, re-generates charts). In most cases this is only possible when your project tracker is integrated with your request tracker. In our case, YOXEL SW is basically one system all together (release manager + request tracker), plus it can synchronize with your external web-based bug-tracker (Bugzilla/Mantis/GNATS/Jira/FogBugz/…).

One very useful capability is for the project tracker to be able to automatically re-compute its timetable for the remaining part of the project (for not completely implemented or tested requests). This allows you to predict when the project may be finishing.

Monitoring and reacting

Here is how you as a release member/owner could be using Yoxel’s release tracker:

  1. Visit the implementation/testing phase progress panel regularly. For each release item (request/task) in the list Yoxel shows originally planned start and finish dates. Yoxel always compares planned start/finish dates vs. actual start/finish dates (when request status turned into ‘in_work’ and ‘fixed’) and highlights in red those items that do not behave as planned (work has not started yet as planned / work has not finished yet as planned).
  2. For any release item highlighted in red take appropriate action to find out what is going on. Click on the item to get a detailed description of the request and check if the developer/tester has added any comments recently. Contact the developer/tester/manager directly or discuss these requests in an appropriate meeting. Unless the release priorities have changed you should try to stick with the original plan.
  3. Check BurnDown chart to see if your project is constantly making progress. Yoxel draws an ‘accumulated-bars’ chart where for each day during your iteration you see a distribution of requests by states (10 open, 4 assigned, 3 in_work, 2 fixed, 1 verified, …). I know agile teams like this chart but I personally prefer our simple comparison table (see #1 above). Because Yoxel always compares the actual vs. planned dates you will detect immediately that there is a potential delay in your project. With the burndown chart it may take you a few days to notice a trend.
  4. Check Gantts charts to see what Yoxel thinks of the project finish date. Is that acceptable? Once again, the timetable for unfinished requests is automatically recomputed based on current states of all requests (including % completeness), and you will see how certain gantts bars start sliding behind your deadline date if you experience delays with some requests in your queue.
  5. Use release history log panel to collaborate with other release members on topics related to the project. Of cause direct personal interaction is always preferred, but it is still a good idea to capture the topics discussed live in this log so that other people (and distributed team members) could see what was going on.
  6. At some point you may be in a situation when it is pretty clear that some of the requests can not meet your planned deadline. It is your judgment call whether to de-commit the remaining items or violate the release deadline. Most common practice is to continue release work until all ‘must have’ requests are done and de-commit the rest. This all depends on your methodology and your preferences, our release tracker allows you to do both.

Two-phase tracking

Yoxel allows you to track the release work over multiple execution phases. The default project template assumes two phase execution of your plan: ‘implementation’ and ‘testing/acceptance’. This means that release testing phase will start after implementation phase has finished (after 1st code freeze). This assumption should not worry you though because as a release member you can move the tracking to the testing phase any time you like. Such a two-phase approach is used to be a little more conservative during prediction of remaining release work. Many development teams do actually start system testing after their initial code freeze so it is better to plan and account for that.

So once your implementation is done (all requests are ‘fixed’ but not all are ‘verified’) or you have decided to start the testing phase anyway you can move to tracking your testing/acceptance phase. At this point your QA should get heavily involved unless they have not done that yet. The tracking progress panel will look the same, only the comparison of planned start/finish vs. actual start/finish dates will be for the testing work instead of implementation.

Iteration is done

Once your testing phase has finished (all requests are ‘fixed’ and ‘verified’) you will be able to officially finish the release and mark it as ‘done’. Yoxel will take you to a summary/statistics page where you should spend some time looking at the numbers that will help you learn and plan your next release better.

My next post will be dedicated to the summary/statistics page, what you can learn from your iterations and how you can use that knowledge to plan your next iteration better.


Agile business, Agile product, Agile team.

The topic of applying agile methodologies to your business processes seems to have become quite popular these days. The benefits of becoming agile are pretty attractive for software companies and yet many of them still do not clearly understand how they could make a smooth transition and whether this “agile” thing really works. I believe part of the confusion is owing to the fact that most of the information and discussions on this topic focus on software development aspect and forget that the companies are businesses and there is a little more to creating a great product than just code development. I prefer to look at the problem of becoming more agile and adaptive from a slightly higher level, product management (PM) level. PM for me is about product development and coordination of multiple teams and processes (development, customer support, marketing, management, sales). In my opinion agile product management (and product development of cause as its essential part) is what you should consider.

Re-visiting, re-fining and re-prioritizing product requirements, plus soliciting, and digesting customer feedback, for each development iteration, are the key ideas of the agile methodologies. In smaller companies your development team may be the one in charge of all of those functions but as your company grows you will most probably have more specialized roles and teams responsible for market requirement and customer feedback management (product managers, technical marketing, professional services, sales engineering …). Hence the agility of your whole business will depend on how well these different teams can interact with each other and especially with the development team to facilitate relevant development iterations and produce what your customers expect. This collaborative work of multiple teams is nothing else but your product management process. And in my opinion it is a very challenging task to make this process efficient and agile. Unfortunately just a white board and story cards may not be enough.

I strongly believe your company will benefit if it finds an appropriate tool to support its PM process. Ideally you will want to have a magic system that engages your development team, your product managers, your support team, and even customers to enable better collaboration, coordination, and reporting. Such a system should be as attractive to the development folks as to product managers, marketing, sales and management. Sure, it could be several systems but then they had better be all integrating and collaborating well with each other. As of today I do not really know of any standard open interfaces/frameworks allowing different vendors to create product management solutions that could smoothly interact and collaborate with each other (Eclipse may be?), so the choice is still usually a one vendor solution, or better (my own preference) an open source solution.

“Hybrid Agile” methodologies and the tools.

Most of the companies that are serious about their business are already agile. They have figured out a certain process that works well for them (with whatever tools they could find). Such companies may not follow strict SCRUM, or strict XP but they are agile. A hybrid agile methodology is often a real life situation.

For me it is always interesting to learn what kind of tools software companies use in support of their hybrid agile approaches. I like to talk to product managers of small/mid-size software companies and ask them about their current methods and tools: how they manage and prioritize product requirements and backlog of requests; how they plan, estimate and resource allocate/balance for each iteration; how they track project implementation and testing; how they gather customer feedback. In order to substantiate my statement that you should look for better tools let me give you a few examples here of what the companies use currently; you will see that the situation could be better.

Company A:
MS Word and Excel for requirements/prioritization
Wikis for collaborative documentation
Jira for project planning/tracking
Jira for bugs and tasks tracking

Company B:
MS Excel for requirements/prioritization
MS Excel and sketching tasks/stories on white boards for planning/tracking
Scrum plugin for MS Visual Studio Team System

Company C:
MS Excel for requirements/prioritization
X-Planner and Wikis as the collaboration workspace
X-Planner for project planning/tracking
Bugzilla for backlog/bugs and task tracking

Company D:
Shared Google spreadsheet for requirements/prioritization
Omniplan for resource allocation, and project planning/tracking
FogBugz for backlog/bugs and task tracking

Company E,F,G,H,…
MS Excel/salesforce.com for requirements/prioritization
MS Project/basecamphq.com/Excel for resource allocation, project planning/tracking
Bugzilla/Jira/Mantis/GNATS for task tracking

Amazingly enough there is abundance of agile companies that simply use Bugzilla/Mantis/GNATS and MS Excel. It is probably explained by popularity of the MS Excel and open-source bug-trackers (thousands of development teams have standardized their processes on those), lack of knowledge about better alternatives, and the fact that smaller companies tend to spend less money on tools in this area. My personal observations are that although these companies managed to stay agile their current processes could still be improved and accelerated. A number of new generation tools could help them in that:

  1. Smaller teams tend to do fine with just Wikis but in other cases it seems like more than two or three different tools have to be used to support the process properly. A bug-tracker (from R&D side) seems to always be in the picture and a requirements management tool (from PM side, usually Excel) also. Plus various project management, resource allocation, time tracking tools. My problem with this is the lack of integration hence a lot of manual work to keep all the tools synchronized plus perhaps burden on IT to support all those tools and integrate them:
    • Spreadsheet tool (except Google’s) is not a collaborative environment.
    • Sooner or later PM has to manually transfer the data from his spreadsheet to a bug-tracker and also to a project manager/time tracker.
    • Every now and then PM has to update project status manually based on the status of individual tasks from the bug-tracker.
    • Real-time detailed status of projects is not readily available
  2. The reporting capabilities are pretty poor in all these examples or achieved at the expense of significant manual work. Reporting can be extremely important for keeping your management and team members updated and informed. Good paper reports can actually be almost as effective as white boards and story cards during your agile team meetings.
  3. A few companies that have been more flexible and also educated on the available new generation tools for agile methodologies have made their transition to X-planner, MS team SCRUM plugin, RallyDev or VersionOne. Again, that is mostly to support agile development process. This is great! Although I still have a few concerns: these tools enforce a certain agile methodology (SCRUM or XP), new terminology, and may require significant ramp-up/learning time from your development team whereas you may want to do an agile variation of your own that does not disturb your current team specifics so much. Just think how Mozilla, Apache, MySQL, Eclipse projects would react if you suggested to them to abandon their Bugzillas and Mantises and switch to another “agile” request-tracker. The same is true for almost any software company.
  4. Customer feedback is usually managed by product managers, professional services and support organizations. Among the companies I talk to I do not see much adoption of customer feedback management tools although there are some interesting tools out there. IdeaScope seems to be one of them! Its advertised most valuable use seems to be mostly in combination with Featureplan product which may be an overkill for a smaller company, but still. (Featureplan, by the way, also enforces a certain pragmatic framework.)

Any recommendations?

There are some interesting new generation tools designed specifically to support agile methodologies. And yet the real challenge is for the companies that do not feel comfortable with radical changes of their current tooling or are reluctant to abandon their bug-trackers. There are fewer options for these companies (although I may be wrong).

  • Smaller co-located teams probably will not need any specific tools. Wikis and any bug-tracker will be enough. Think about your future though, if you are growing, a day may come when your wiki/bug-tracker environment is not enough to accommodate your team/business dynamics.
  • If your team is bigger, especially if it is distributed, and wants to do a strict SCRUM/XP and you can afford a significant change to your current processes, you should probably go with some of these new tools: RallyDev, VersionOne, X-Planner. They are great! Pick one that addresses your product managers’ and other non-developer’s needs also.
  • The teams that want to transition to or improve the support for their existing agile processes but are not comfortable with radical changes, in my opinion should look for a tool that integrates with their Bugzilla, Mantis, GNATS, Retrospectiva, Jira, … and is designed to be a tool for product managers too. Make sure it has the release/iteration manager that allows you to plan and track your iterations and derive useful statistics.

Yoxel Systems

The project I am involved with, Yoxel Systems , should be a really good fit for the last category mentioned above where you really care about smooth transition or are looking to support your hybrid “agile” approach. We try to create a flexible solution for product managers, field support, and developers that can accommodate a variety of agile methodologies, so Yoxel is also an alternative to RallyDev, VersionOne, X-Planner. On top of the release/iteration management aspect Yoxel tries to be very customer focused providing customer support, product knowledge management, and lightweight CRM capabilities too, all integrated into one product management system.

(Please try our demo accounts at http://yoxel.com)