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?

Creating a useful product management environment

More development in the area of customizing and integrating bug-tracking and project management tools to create a useful product management environment: Product management nirvana

I have pointed earlier to the effort started at Splunk in my post Bookmark: Automating and opening up product planning . It is quite interesting to see what they are trying to do. Once again, I am just glad that the vision of our project Yoxel Agile Product Management is aligned with what real agile product management teams try to address. Here is what I mean by that:

Think bigger, Think Agile Product Management

Bridging the worlds of PLM and CRM

Bugzilla -> Yoxel synchronization module

Technical reporting with YOXEL SW: HTML, PDF, EXCEL

Project management software is social software

Release planning with YOXEL SW: Starting a new release

Release planning with YOXEL SW: Collaborative planning session

Cheers!

Rolling wave planning compromise.

David @ 37signals is saying, You do not need a product road map:

It’s better to turn customers away than to placate their instincts and lure them in with vague promises. It’s incredibly rare that a single feature will truly make or break your chance with a customer. If your software is a good enough fit, most people can make do without that one or two things that they’d like to see. 

John @ SplicedNetworks is saying, Goodbye Roadmap:

The concept of a roadmap has been thrown out, replaced with list of initial functional features . These features are currently in development, and will be the initial AppOS 4.0 release. AppOS 4.0 won’t be the bells and whistles release initially, instead it will be functional. Features will be expanded and added based on customer feedback , as well as our own use of the product.

These are agile companies talking. I support this concept and I am pretty sure they know what they are talking about. Our backlog is our idea of a road map, it is telling us what could be coming in the future releases (most probably the higher priority items) although you can not really say when exactly and in which order. One or two iterations ahead the situation is much clearer but beyond that not really, it is all driven by the changing market requirements.

But then, even scrum masters keep bringing up the concept of the rolling wave planning, which basically means: lets still try to maintain our road map and long term release plans, even though we’re agile. Isn’t that somewhat contradictory to the iterative “agile” concept which tells you that it does not make much sense to predict that far ahead?

I think Jerry Manas expressed it very well in his comment to  Forced Into ‘Agile’:

But even in the Defense Industry, Rolling Wave scheduling is becoming the norm, where each horizon is planned at a more granular level as it approaches (although the whole project is laid out up front at a higher level). I look at Rolling Wave as a hybrid between Agile and BDUF (and it’s appropriate for most projects most of the time).

So is the rolling wave a vehicle for transition to agile or a means to keep your business/management/VC folks happy (by giving them a plan that wont survive the reality)? What is your take on this issue? Do you create product road maps in your agile environment? Do you use the rolling wave concept? How practical is that? It would be very curious to learn.

Our product Yoxel Agile Product Management  is quite straight forward in this sense. You’ve got your backlog and your iterations, which we also call incremental releases, because for us those are the same (~1month: implementation+testing). No rolling wave with long term release plans and even longer term road map plans. You can start planning next iteration while you’re implementing/testing one and so you will have a good idea for what is coming in a month or two but beyond that your best bet is the prioritized baclkog .

Cheers!

Bookmark: Agile SCM – Review of 2007 and Predictions for 2008

Agile SCM – Review of 2007 and Predictions for 2008, written by Brad Appleton, Robert Cowham and Steve Berczuk. An interesting read.

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

Why do organizations fall back to the old, comfortable waterfall?

Here is another article that I really liked: The (Not-so) Agile Waterfall, by Ken Knapton.

I have recently been made aware of yet another organization that says they are “doing agile” when in fact they are not. They are in fact following almost a text-book example of the waterfall method, but using agile terms such as “iteration” and calling it agile. They define every iteration up front, and lock themselves into dates when each iteration will be completed, even for projects that will last six months or longer. The development team is strictly held to meeting these dates, and product is not delivered until the end of the project. 

And why does this happen? Ken suggest one reason:

As to the question of why organizations fall back to the old, comfortable waterfall, I believe it comes down to a very simple answer: metrics. Upper management likes to have nice metrics to track the progress of their organization, and the easiest metric to track is on-time delivery.

I guess for the same reason some commercial ALM tools lure you into this trap too. They sell their tools to those managers after all. Their marketing works way too well promoting “agile”:

• Check out RallyDev’s demo: slide#2 talks about roadmap, release, iteration planning. What I get from this is that they suggest to plan a release (3-6 times a year) and lock iterations within that plan. I am not exactly sure what good a 4months plan with locked iterations will do if after your first iteration (2weeks to 1month) your customer feedback shows that you need to re-prioritize and change half of the plan. Or, aren’t you delivering functional software to your customers after each iteration for feedback?
• How about VersionOne’s datasheet: One of the key features Drag-n-Drop release and iteration planning. As for agile, I understand iteration planning or just release planning (if it is a short incremental one, equivivalent to an iteration), but together? This probably means again, create a waterfall plan and lock your iterations within it. Is that agile?

In general if you’re trying to be agile you will have hard times planning something far away in the future. Giving dates for your future releases and roadmap milestones is quite a challenge:

Does “agile” complicate your roadmap management process?

Agile roadmap 

Agile roadmap

Here is another great ‘real-life’ story of transitioning to ‘agile’ Agile Team (with personality observation) by Susan Lim. You know I like such stories more than any theoretical discussions on this topic, because it is very individual and it gives very good examples. I learn alot from these myself.

The point of having two plans, long term release plan (or roadmap plan) and a short term iteration plan comes up all the time with agile/SCRUM. (Agile Hallmarks post brings this topic up again and again, accompanied with very neat diagrams and chars.) I believe it is quite challenging to follow your roadmap. Sure you can create it as your management and marketing books tell you but will you be able to follow it exactly? If the market requirements change swiftly, will it make sense to follow it? In my case, having prioritized backlog gives me an idea of my overall roadmap but it is also quite flexible, because the iteration plans are really the ones that align that roadmap with current market situation. I have written down a few more thoughts on this topic before:

Does “agile” complicate your roadmap management process?

This O3 magazine article is even saying “Goodbye Roadmap”:

http://o3magazine.com/pastissues/issue7/

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.

Areas to improve for your software projects

A very insightful analysis indeed, by Carl Rogers in his post A little insight into our customers’ process capability …

With tons of useful graphs. A few things that I notice from the graphs:

1. The most challenging problems that software projects face are: Delayed Delivery, Cost overruns, Poor Requirements, Unclear/Imprecise Business Objectives, Poor Communication, Lack of Testing
2. Importance of software development process in building applications: hight for the most teams
3. Use of software development process: In-house grown is the most popular one especially for smaller teams, compared to others like MSF, SCRUM, …

Clearly known agile methodologies emphasizing incremental delivery and frequent customer feedback management focus on solving #1 challenges and must be the only right way to go.

For the most part this survey results seem to be in agreement with the other survey that I mentioned earlier, done specifically for agile methodologies: Agile Project Management Tooling

The only major difference I see is that in Carl’s results the in-house/hybrid methodology and MSF are the most popular ones whereas in the other survey it is SCRUM and XP.

PS: Here is another article that seems to be quite relevant to the topic of the problematic areas for software projects: The Absent Product Owner anti-Pattern

Yoxel v1.16 in the news!

This is the first time our project got some coverage in press. And it is a very pleasant surprise because I had no idea the article was coming out in O3 magazine (Issue #7):

Issue #7: Agile Product Management

John Buswell, the author of the article, contacted me yesterday, just a few hours before the press release with some last minute questions. The bonus for me was to find out that his company had been using Yoxel for 6 months now and was quite happy with it.

John, your article made my day! I could not hope for a better review of our products coming from an unknown and hence objective user. I also learnt quite a bit about our own products from your article, like for example why our approach is so unique and different – “highly business and customer focused”. I was trying to express this in my blog but I believe you did this much better with your article.

————————————————————————————-

For those who had a chance to read the article I wanted to add a few comments here, a few clarifications.

1. When John is talking about the release/iteration planning process in YOXEL SW

In the planning stage, tasks (or requests as they are called in Yoxel) are added to the plan. The requests are assigned to a particular component of the project. Each request is then classified as either an enhancement to existing code , or a completely new development. … Once this is done, you can later go in and add the details to each step.

he describes a quick way of creating a list of tasks with brand new requests. I would like to add that the release planner also is linked to your backlog (requests and bugs you have filed before) and you can easily include any of those into the list too. There are buttons [add existing request] and [add request by number]. You can include bugs into your plan this way too.

2. Regarding the estimates:

The estimate tab generates time estimates based on all the data entered for a particular release .

Essentially all your developers and testers enter their estimates for the tasks in your list/plan and the planner uses these to estimate the project end date and suggest more balanced resource allocation.

3. About the common approach:

YOXEL IT is very similar to YOXEL SW . In fact the ticketing system is practically identical to the request system used for Yoxel SW , and the IT project system is pretty much the same as the Yoxel SW release management.

This is very true. The heart of Yoxel is a scalable and parametrized workflow and request tracking engine. It takes little effort to create yet another tracking system (software, IT, sales, evaluations, KB, …). The base code (the RequestTracker class) is always the same and sure the UI looks somewhat similar for all the trackers.

4. About YOXEL KB

The knowledge base only applies to the software module.

Actually all menus in Yoxel portal are customizable so one can easily add the KB tab under IT section/module and add categories related to IT too. You may find _menu.inc files that control all the menus under individual sub-directories, although at the moment we have not yet documented them.

5. John had a good tip on securing Yoxel /includes directory.

Depending on your Apache configuration, you will probably have to secure up some of the directories within the Yoxel package . In particular, you will want to secure up the includes, not only with file system permissions , but also in the apache configuration.

I would actually recommend securing all .inc files, not just the /includes dir. A few of those (like _menu.inc and _help.inc) are spread out in other directories:

<Files *.inc>
Order allow,deny
Deny from all
Satisfy All
</Files>

6. MySQL:

The database is called local_yoxe ldb2. You will need to create this with MySQL: create database local_ yoxeldb2;

Actually you do not have to worry about this. The first time you connect to Yoxel portal it creates the database automatically.

—————————————————————————————-

I think this is all I wanted to add. Other John’s tips are quite useful, I will incorporate them into our README (installation instructions) file.

Enjoy!

PS: And by the way, Yoxel v1.16 was released on Aug 17 with more enhancements to our dashboards engine. Please, come check it out in our demo account at yoxel.com.