My customers mostly were very reasonable, they would ask to provide a commitment date for a deliverable right away but would also be ok if we postponed the date later, as long as we communicated the change of plans to them early enough. Their own plans depended on our commitment dates and they wanted to be sure we were not forgetting about our agreements (I am only talking about bugs and enhancement requests here). Sounds like it should be quite easy to satisfy your customer, file all these customer requests in your internal request/bug tracking system and keep the customer informed on the progress. And yet it was really difficult to keep up with this seemingly simple process of providing commitment dates and timely updates.

The first problem was getting a date from R&D. Most R&D organizations are not driven by due dates, they are driven by release plans (where promises to customers don’t always win strategic marketing targets and other priorities). So, you can get commitment dates for the requests scheduled for the next release (1,2,3-6 months from now, depending on the methodology used) but only once the release planning has happened, which means  you get the opportunity to find out  ETAs of your customer requests only once per 1,2,3-6 months. Well, customer is already not very happy, has to wait for so long just to get the commitment. This vendor release based scheduling does not go along with the customer request/commitment based scheduling. Plus, you have waited for 1,2,3-6 months for the release planning to happen just to find out that only 1 or 2 of your 10 customer requests have been scheduled for the release. Well, I am quite disappointed also, I don’t have the commitment date for 9 out of 10 requests and my customer was hoping to find out the dates for all 10.

You could say your R&D needs to use a SCRUM/agile methodology, run 2weeks to 1month sprints/iterations and then they will be able to provide commitment dates more often (every 2weeks to 1month). Agreed, but, how many iterations ahead can you plan without defeating the purpose of the “agile”? Probably not more than 2 or 3, so again the chances are I will still be only getting a commitment for 1 of my 10 requests per 1,2,3-6 months.

So this is the reality, you only know more or less what features you will deliver in your next product release (iteration, if you use agile). As 37signals say “planning is guessing” and your next release is probably your best guess. Beyond that, who knows how requests will be prioritized?

But how do you reconcile this with the customer’s desire to see commitment dates for all its requests even if some dates are meaningless and will be re-negotiated in the future? The customer basically wants our best guess date for all its requests, including those that do not get into the next release. That is a challenge, don’t you think? One may say, “then give them arbitrary date” for those ‘beyond the release’ requests. And may be that is what we should do. Not giving any date is an option too I guess. But I am thinking, can we do anything better for our customer?

So the idea is the following, may sound quite crazy, but I still want to throw it out there. Usually once a request is filed in a request/bug-tracker it is assigned to a developer right away, in most cases to the right developer who will actually be working on it once the time comes and either “blocker” urgency or the release plan says, “go”.  At the moment planning is a prerogative of a few chosen product/marketing managers who plan for the whole team and it may become quite complex, so they can’t deal with more than a bunch of most important requests. But how about empowering everyone on the team to plan? Lets say we give everyone a powerful work-hours calendar (that predicts time-off, meetings, maybe additional statistically derived unavailable time) to plan his/her own tasks. Come on, the requests are all already assigned to the developers, don’t you think they would not be able to stack them up in this smart calendar with their best guess time estimate for each to come up with a reasonable ETA for all the assigned requests? The chosen ones can help the developers with priorities (they know the business goals better) but,  in theory, all requests (and I mean all that you find in your bug-tracker or better all that have ever been asked to be scheduled, not just the subset selected for the next release) can be scheduled easily as long as you de-centralize the planning and let everyone schedule his/her own work. And the ETAs will be more accurate this way, I am pretty sure, because everyone knows their own stuff better.

Now, consolidate all these individual schedules, and pick the top N requests that you want in your release, see where your release deadline draws the line. The best thing is that any request “beyond the release” has been scheduled also and has the best guess ETA. I would really be happy to relay that to my customer, that is the best guess he was asking for all along. What is even better, every time there is a new request in the system it trickles down into developer’s personal work-hours calendar where he/she plans it right away (may be reshuffles a few other tasks to accommodate changed priorities). We have all requests re-estimated and re-planned, we have our best guess for all of them, and the commitment date can probably be shared right away with the customer. Actually the scheduling developer sees right away which commitments he breaks when adding a new task to his calendar. At this point maybe we can re-negotiate the priorities with our customer? That is the power of de-centralization!

I would call this “continuous re-estimation” or “continuous re-planning”. You don’t wait until the next release planning session, developers re-plan their tasks as soon as priorities have changed or new tasks got assigned. May be you don’t even need release planning with such a model, because you always have your best guess schedules ready and up to date.

What do you think?

Just to follow up on the earlier post:

Bugzilla -> Yoxel synchronization module

Here is more info on integration with Mantis.

Here is an interesting post by Christina Noren, Automating and opening up product planning. Yet another example of a team trying to hack and integrate a few existing tools to build a useful product management flow. The problem I have been describing in my earlier post, Think bigger, Think Agile Product Management. Seems like many teams face the same inconvenience and some new, more integrated tools could help.

So the experiment: We’re hacking Jira, our bug tracking system, in order to automate the entire product planning and marketing process and facilitate real-time communication back to customers, internal stakeholders and even the community at large via our public roadmap. 

This means that we setting it up to automatically bring enhancement requests from our SugarCRM system into a PM work queue within Jira; asking PMs to enter call reports and market datapoints; linking all of these to problem statements;

What I especially like about this post is that it confirms our efforts with our project Yoxel Systems. Yoxel is exactly that integrated system: request tracking, release planning/tracking, key CRM capabilities, and even customer portals! And if you really like your Jira, Bugzilla, Mantis, GNATS, Yoxel can connect to them too.

Customers with enhancement requests tracked through the support portal will be able to see how they’ve been triaged, how the problem has been interpreted, and what requirements are at what stage of delivery to meet the request.The public roadmap will be maintained in real time, with the potential for drilldown into more of what’s behind each listed feature. 

Once again, Bridging the worlds of PLM and CRM  seems to be creating value and helping you build better products.

Check out our demo accounts as http://yoxel.com

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

Enjoy!

Release v1.17 (http://yoxel.com) has a bunch of new capabilities and I am quite excited to list a few of them here:

  1. YOXEL SLS (an experimental suite for sales teams), that has been only available in our on-demand version, is now included in the open source version. You get two subsystems: sales forecast tracking and product evaluations tracking. Many other CRM products have forecast/opportunity tracking solutions but you will not see many good product evaluations tracking solutions. We would like to think that ours are quite unique and powerful, plus they become integral part of the whole product management solution:

    Bridging the worlds of PLM and CRM

  2. Profile editing capabilities added for customer/contact logins. Besides entering contacts information only on your side (correct name/email/password/opt-out options/…), the traditional CRM way, you can now rely to some degree on the contact itself. Certain fields have been opened for your contacts, that have login access privileges, for editing. This kind of makes it CRM 2.0 – more interactive relationship with your customers and better feedback management :).
  3. CVS and basic Subversion integration is enabled though email comments support. Besides capturing email responses related to requests and attaching them to the request history/log, Yoxel in a similar way now can attach your commit messages coming from CVS or Subversion.
  4. Responding to a request from one of our users, support for Retrospectiva external bug-tracker has been added too. Now it is possible to configure Yoxel to import requests from one of these bug-trackers: Bugzilla, GNATS, Mantis, Retrospectiva. For a smooth transition to “agile”!
  5. … other more specific capabilities and bug fixes …

Ejoy!

PS: And please send us your feedback.

Scott, thank you for your comment to my earlier post GANTT in agile environment. I wanted to respond to it but could not find a short way of doing that so here goes another full-blown post. A comment like this would probably get lost in the comments section.

Is it GANTT or is it MS Project?

Here is an excerpt from Tate’s article which sort of says that even with agile (I even think more so with agile) you still do prioritization, estimation, resource assignment, … So it is not just my words.

When you have a granular, ever-changing list of software requirements (or features or enhancements or whatever) and the team prioritizes and commits to just a few of those each iteration AND the team then organizes their own way of delivering those requirements in the space of a few weeks or less, it is really, really hard to make a Gantt Chart.

You keep the list of tasks (features and enhancements) using some tool today, Excel, MS Word, MS Project, Bugzilla, right? The cost of maintaining the list is always there, regardless of whether you want GANTT or not. If your tool of choice can generate GANTT chart automatically for you then the incremental cost of doing that is ZERO. And if you use MS Project to manage the list then you would not have a problem with GANTT, I believe. But are you using MS Project to manage the list?

The reason people say creating GANTT is expensive, I think, is because they actually maintain the list of tasks in one tool and generate GANTT in another tool (e.g. MS Project). Now, that is a real head ache, I could not agree more! Entering manually all tasks, information about resources, durations, dependencies, every time any of those change in your master list, just to have a GANTT chart? I would not do that, and naturally I would say that GANTT is not worth it. In my opinion the real issue we’re complaining about GANTT is that a typical project management tool (like MS Project, dot Project, Omni Project, you name it) is not designed to be a good tool for a software product manager and it is very painful to maintain a list of changing project tasks in it. I have a feeling that often when people say “GANTT chart is not useful”, they really express their dissatisfaction with MS Project because it is not the right tool for doing their software product management.

Traditional PM tool is not the right choice

Why is not a traditional PM tool convenient for software product management and people prefer to just use Excel or Wiki and make GANTT chart an “escape goat” (I mean discard it and blame it)?

  • Because it is not connected to your request/bug tracker (your backlog) where most of the product requirements, enhancements, bugs are already filed, estimates entered, and task statuses available, plus available resources defined (even with their specific specializations; think Bugzilla, Product/Component -> Owner relationship)
  • Because it is not a collaborative environment and you have to do all the input and tracking work yourself whereas you could be benefiting from other people’s input.

  The PM tool for a product manager should be a collaborative environment

If you start using a PM tool that is designed for collaborative product management on top of a request tracker which is used by your support, development and QA teams, you will see how much easier it becomes for you. Even the cost of maintaining your blackog and feature lists (the effort and time you as a PM personally invest daily) minimizes because most of the input and status tracking happens without you even knowing about it. Duplicate efforts to input and track data on your side are minimized (sometimes absolutely removed) and the cost of maintaining the project status up to date is spread out among all the team members hence your personal effort significantly decreases.

Back to GANTT charts

In such a collaborative environment where your whole team contributes to the project planning and status tracking, an accurate GANTT chart with the real-time detailed information incorporated in it is suddenly becoming a quite attractive alternative to your burndown chart, in my opinion.

And even with agile teams I would not discard the importance of providing accurate status information to your managers. They do like GANTT charts, don’t they? Any additional level of clarity within your company can only help to succeed with your projects.

Lightweight defect tracking

August 10, 2007

Adam Bullied writes about an interesting tool Pownce that helps him speed-up the work and communication during the final phases of releasing v1.0 of their new product: Some New Tools.

I don’t want to be sitting around filling out CR entries, assigning them, forcing developers to read them, re-assign, etc, etc… It would kill our momentum.

So, each morning, we compile our list for the day for development to work through (in true “agile” like style) and that includes notes we have logged / passed back and forth to one another using Pownce. It’s been insanely helpful for speed and completeness.

Take a look, it could be useful for your team too.

Stop reading here if you do not want to hear my biased opinion/ad for Yoxel 🙂

If you check out our demo account at www.yoxel.com you may notice that we have implemented a mechanism that allows you quick status updates and team communication during iteration work. The ‘history’ panel which can be found under [SOFTWARE]|sw releases|summary|<pick an active iteration> is exactly that. So here is an alternative for you which will do what Adam is talking about plus it will allow you to stay within your request-tracking/product-management environment and log all the communication.

Actually Adam’s description gave me a few ideas on how we could enhance the capability and make it more useful :). Thanks Adam!