Providing Commitment Dates To Customers

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?

Mantis -> Yoxel Synchronization

Just to follow up on the earlier post:

Bugzilla -> Yoxel synchronization module

Here is more info on integration with Mantis.

Bookmark: Automating and opening up product planning

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

Bugzilla -> Yoxel synchronization module

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!

Yoxel v1.17 with a SALES module is available for download.

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.

Is GANTT chart the real issue here?

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

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!

Due to unexpected bugs and other difficulties

Reading about real life experiences with SCRUM is quite interesting. You see, that compared to theoretical description of the process, you always have unexpected tasks that mess-up even your shortest iteration plans. Software design is quite unpredictable but running a software company with customers is even more so 🙂 .

Check out Tom Harris’ post describing his experience, for example: Scrum Update.

We run into such situations every day. As a matter of fact in our teams we run two queues of requests/tasks:

1. Critical – something you have to jump on right away and fix/implement ASAP (usually some bugs that are show-stoppers for our customers: crashes, major accuracy issues, …)
2. Non-critical (high,medium,low customer urgency) – this is the part of our backlog that we create iteration plans for and execute according to the plans.

Check out my other post on this topic: Urgent vs. Planned
I guess what SCRUM calls ‘velocity’ should help you deal with these situations. You will figure out your velocity over time when somehow handling both critical and planned work in the beginning. When planning for an iteration know your velocity! Or have some other way to account for ‘regular unexpected’.

But even that wont always save you. You will be having times with bursts of unexpected requests. So we do not plan N iterations ahead. We examine our backlog and do full re-prioritization, re-estimation, and collaboration session before each iteration to create detailed plan only for that one iteration. Why bother planning for longer when you know that your priorities will significantly change in the next 2 weeks. 🙂

This brings another challenge – your product roadmap. Does “agile” complicate your roadmap management process? That is a topic for a separate discussion though.

But I think those ‘unexpected requests’ are a useful indicator. If they do not allow you to do your iterations at all then may be it is time to stop and think. Your software may be in a stage when you only want to address the critical requests (maturing alpha/beta releases), forget about the iterations for a while then. Or may be something needs to be changed in your development/testing process and it is high time you seriously looked at Continuous Integration.

Cheers.

Technical reporting with YOXEL SW: HTML, PDF, EXCEL

When it comes to planning or tracking certain activity and communicating its status to involved stakeholders, reporting capabilities of your planning/tracking tools become quite important.

A few examples where I personally benefit from a nicely formatted, printed (or printable) report. Something you can hand out or send to people:

• A daily/weekly meeting with developers where we discuss current most critical (some call them P0/P1) requests. Especially when you have more than one critical request per developer, it is time to sit down all together with a paper report and decide on tactical priorities.
• Release/iteration planning sessions, where you communicate with your colleagues directly. It is very convenient for everyone to have a list of the tasks being planned/implemented in the current iteration. Sure, you could be starting with story cards and a white board but reports is an automated alternative when you are using a tracking tool of some sort.
• How about communicating status of important requests to your customers? That is my favorite application of reports :). If your customers do not have a direct access into your tracking database (btw, Yoxel SW has this capability too) you probably want to send them regularly a report which lists their current support requests, open bugs/enhancement requests, closed ones too. This is a very good way of keeping your customers informed, showing them your progress, and at the same time having constant feedback on content and priorities from them. Guess what, this technical information coming from your bug-tracker is not available in salesforce.com’s database for your sales people but they would love to have a copy of this report before meeting a customer face-to-face.
• Getting a little bit into sales side but still staying technical: pre-sales evaluations tracking. Stuff that pre-sales engineers know about a customer engagement. There are not too many systems actually doing this tracking and such reports are mostly generated manually. These are very important and again contain the technical information your sales guys want to have at their fingertips. For the pre-sales engineers these reports allow to communicate their load to the management and likelihood of a deal moving forward to their sales people.
• I am sure you can think of many more types of reports and their benefits

So you can see that your current bug-tracker or a project management tool contains alot of useful technical information that could be important to anyone, starting from developers to managers, sales, and even your customers. And I am only talking about the technical information: bugs, product requests, support requests, their statuses, user comments, priorities, commit dates … Forget about marketing and sales folks for now that have other stuff to report from their salesforce.com’s, siebel’s, and sugarcrm’s.

Once Yoxel SW essentially is a request tracker combined with a release/project manager it was quite natural for us to try to address these reporting challenges – to create a convenient and flexible enough way of defining and creating reports based on the information about the requests in our database.

1. It all starts with filters. Folks familiar with Jira know what I am talking about. As a user of Yoxel SW you create filters to zoom in on certain sub-sets of requests in your database. Internally a filter translates into an SQL SELECT query. Guess what, you can save and share filters in Yoxel.
2. The next step we have done is we have allowed you to create a report definition. We call it a report template, it defines a structure of a report. Yoxel report can consist of multiple sections: headers and contents. The header is just a line of text, usually preceding a content section. The content section is a filter (one of those that you’ve saved) and ‘order by’ parameter. The template also defines which fields (columns) you want to show in the report. (BTW, Yoxel allows any number of custom fields to be added.) You can save and share the templates too.
3. Now, to actually create a report you select a template, apply additional content control filtering and choose which format you want HTML/PDF/EXCEL. Content control allows you to generate a report where certain information is hidden, which is usually helpful when creating a report for a customer (hide purely internal requests and details, or hide requests related to other customers). Excel format allows you to add final touches to the report content in your MS Excel before sharing it with others.

You can see that the templates make it quite convenient. For example pre-sales engineers and a support team can work out a certain standard report structure to communicate with the customers (current open requests sorted by priority, enhancement requests, cosed items); a product manager could create another template for tracking release progress (requests assigned to the iteration; show fields relevant to progress tracking); a PM or an R&D manager might want to create a template for showing only critical requests. Creation of an up-to-date report based on a template becomes a matter of a mouse click for any member of your team.

Give it a try in our demo account at www.yoxel.com and tell me what you think. Follow the menu ‘SOFTWARE/requests/reports’ once logged in.

Enjoy!

Are you managing your backlog well enough?

A very valid point made by the following post Is Agile Enough? (part 1)

Therein lies the key omission of Scrum (and most other agile methods): The backlog of user stories are taken as a starting point. They are not examined for their “quality”, “completeness”, “cluefulness”, budget impact, etc. The user stories are assumed “good”, and used as an “input” to the Scrum process.

(… good read …)

Does your request tracker allow you to have hierarchical requests so you could be breaking down original user stories and requirements into more detailed tasks suitable for iteration planning?

Does it track the duplicate requests so you could see the most popular requests and prioritize accordingly?

Does it allow you to specify dependencies between requests and respect those in iteration plans and project deadline estimations?

Does it allow your customers selectively (in “controlled by you” fashion) access the request records to give you more feedback regarding the content and priorities?

Check out a demo account at www.yoxel.com to see how Yoxel request tracking system can help you do all that within agile environment.