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.

Installable vs. Hosted

This 37signals’ post started a long thread of interesting comments Ask 37signals: Installable software? Quite insightful opinions although mostly leaning towards the hosted SaaS approach.

It would be highly unlikely that we’d sell installable software. This question is actually more about business than it is about software. 

• We’d be a different company
• Hosted = Controlled development and deployment environment
• Installable = Lots of room for things to go wrong
• Backward compatibility headaches
• Upgrade cycles

And then also this interesting follow up  Installable vs. Hosted , by Kevin Dangoor, in defense of installable software.

However, I think for a many apps, quite a few potential customers will be left behind by only offering a hosted version.

I’ve seen a number of products start off with one approach and then add the other. I can name two off the top of my head that started off installable and added a hosted option.

Our experience is quite opposite, we have started with a hosted version and later added an installable one. We distribute a free open source version of our product so if you study and de-bug our code it is fine with us, that only helps us make it better 🙂

The SaaS model was a good start, it helped us to mature our product and test the market. It is a significant part of our offering. One of the main reasons though vendor companies choose SaaS model is because it is easier for them. You do not have to worry about all those bullets expressed by 37signals. Is it always a good model for your customer? Not always, if you start paying more attention to your data security and privacy.

Our SaaS/OnDemand version offers a number of free services and we do not lock-in your data (you can always take it and move to your own server). And still, we see that more users prefer to download our open source version and install it on their premises (even though it takes some of their precious time). I bet the data security (in our case we are talking about release/project/feature plans) and in some cases compliance with Sarbanes-Oxley Act plays significant role in their decision making process. We are not Google or Salesforce so we did not expect that everyone would trust us with their critical business and customer related data so we went for an installable version too. And it has been quite rewarding: more users, more useful feedback, our code improved significantly, even the article in O3 magazine.

Our software is riding on UAMP (Unix,Apache,MySQL,PHP) stack which makes it easier to produce the installable version of our product. The release and testing process actually makes our SaaS solution (http://yoxel.com) much more robust. It was quite a challenge and alot of work to create a proper development infrastructure and to start producing the installable version but now after over a year of releasing it I should say it is not that hard anymore.

There are many advantages for a vendor to use SaaS model but here are a few that I personally like in the installable open source software model too:

• More potential customers who otherwise would be concerned with SaaS
• We are not responsible for the security and privacy of customer servers/data
• You can test at a few selected beta-sites before rolling out new version to everyone
• Our users help us make our software much better by seeing our code

We really like our SaaS model too. Would the trust/security/privacy issue be easily solvable this would be just enough, I think. But at the moment the combination of hosted and installable makes alot of sense to us. Appliance is a good model too, unfortunately we have not reached that stage yet. A good example is SugarCRM which offers all three models!

Enjoy!

http://yoxel.com

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

Yoxel v1.18: License Management System (LMS)

 Yoxel v1.18 is available for download with a significant extension to YOXEL SLS (for sales) suite: License Management System. You may ask, “Why YOXEL SLS?” – when the focus of the project is agile product management. The reason is that our active users encourage us more and more to link into CRM world and as I wrote before this seems to make alot of sense: Bridging the worlds of PLM and CRM

So what is this License Management System?

Think of it as of yet another flavor of Yoxel request tracker. The requests ask to cut a license (produce a license file) for a customer, deliver it to the customer, and confirm that it is installed successfully. That is what your customers and eventually your sales people request internally from your R&D, Support, or IT team (whichever is in charge of your license cutting process), and if you have many customers and many such requests you’d better keep it all organized. So there is a certain workflow for the requests (customization is of cause possible), and here are the main states of the default workflow:

• State ‘open’ – a sales guy files a request. At this point the sales can help by specifying required details: license server platform, hostid, list of individual feature keys and their parameters (#keys, expiration dates, …).
• State ‘assigned’ – the request gets automatically assigned to a technical owner of the account (your support or sales engineer). This person will cut the license himself or work with other department to get the right license file.
• State ‘generating license’ – the technical owner is working on generating the license. He will generate the license file externally and then attach it to the request. We have also provisioned a feature-set construction panel and hooks for running external license-generators (require some customization work) so that license cutting itself could be done from Yoxel too. So the owner simply constructs the feature set from available keys and then presses button ‘save’ – the license is generated and the file is attached to the request.
• State ‘license ready’ – the license is ready so it can now be sent to the customer
• State ‘verified’ – the customer has confirmed that the license has been installed and is working.
• State ‘closed’ -the request has been complete!

Purchase Order Tracking?

In many cases each license request is a result of a purchase order (PO) that has come in from a customer. This means that the a $$ amount could be associated with each request too. We have provisioned a field (booking) for that but in this 1st version of the LMS we would like to stick to the technical side of the license tracking and generation mostly. Your feedback on the PO part would be very appreciated.

Feature set construction

Besides pure tracking capability of the LMS another key part of the system is license key management. License files are usually constructed as a set of individual keys, each enabling a certain product or feature. People that use Macrovision’s FlexLM are very familiar with the concept of Time Based Licenses (TBL) and license files that are sets of those feature keys. So the LMS allows you to define all your available keys, their descriptions, and their fee information. Then at a license submission stage or license generation stage one can easily construct/modify a set of required keys and use that for license file generation.

Once-off, TBL, and billing/maintenance fees

There are many different software licensing schemes: charge once per installation, bill periodically as long as the product is in use, get a payment ahead of time for a license that will expire (TBL), … We have tried to accommodate a few popular strategies. You can associate all this fee related information with any key that you define. Then when a feature set is constructed, that is when you specify a desired list of keys, #keys, expiration dates the LMS computes for you final once-off amount, pre-payment TBL amount, billing/maintenance amount. This is meant to be used as a worksheet mostly, to have a good idea of what kind of fees your license file is entailing. The actual booking amount entered for a request is up to the sales person (ideally it is the once-off fee + the TBL sub-total). The worksheet also informs you of planned billing schedule.

Check it out

So the 1st version of LMS is available for you to try at our demo accounts at http://yoxel.com and for download. I am sure it is not perfect yet and requires quite a few useful features to be added, we have some interesting ideas and will be enhancing the system in the next releases.

v1.18

To see what else is new in v1.18 please visit our news section at http://yoxel.com and explore our demo accounts.

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.

Why I choose FreeBSD over Linux :).

This quote, that has been around for a while, is quite funny:

“BSD is what you get when a bunch of Unix hackers sit down to try to port a Unix system to the PC. Linux is what you get when a bunch of PC hackers sit down and try to write a Unix system for the PC.”

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.

Yoxel v1.13beta is available

We released our next open source version v1.13 on Monday. This LAMP based software is available for download at SourceForge and FreshMeat, see www.yoxel.com for details.

The package includes 3 products:

• YOXEL SW – Agile software product management
• YOXEL KB – Knowledge Base / Q&A management
• YOXEL IT – IT project management

Check out our demo accounts at www.yoxel.com to see what Yoxel Systems is all about.

Release tracking with YOXEL SW: Monitoring iteration progress

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.