Friday, August 28, 2009

Simple Pricing of ScrumPad Explained

Although our pricing model is simple, it maybe confusing to some of you at first. This is because we are so used to seeing the traditional SaaS pricing plans that we don't even think about better alternatives. Before I explain our pricing model, let's see what a traditional SaaS pricing model looks like.

Traditional SaaS pricing model is usually designed as a matrix of features and levels of plan with progressively higher price. For example, let's see the pricing page of Github, a popular version control system built on top of Git as SaaS. What do you think of the plans? There are 7 different plans differing along 3 attributes- number of projects, amount of disk space, and of course, number of users ("collaborators" as they call them). Here comes the difficulty in choosing what plan is the right plan for me. Hmmm... I have 4 projects and probably will not have more than 5 any time soon. I guess "micro plan" should be good enough for now. Right? Wrong. It would not work because it only allows 1 user and I currently have 12 users. I actually need to get the "large plan." But wait a minute, then I would be overpaying since it is for 25 users and 50 projects. Until I get to that point, which may never happen, I have to bear the pain of overpayment. If you are not confused (and probably a little unhappy since you have to overpay) already, try to determine how much disk-space you would need. The large plan comes with 6 GB disk space. Pretty good, right? What if you start to hit the disk space cap before you ever use up your number of users and projects quota? Man that would add to our pain even more.

Don't get us wrong. Github is a great service. We would have used it if we were not in a pickle to select the right plan for us...:-) Github is not the only one with this problem. This is the case with all SaaS offerings.

Enter our world. ScrumPad is priced as per user per day basis. That is it. So, there is just one data to deal with for you to make the decision. If you think the price per user per day (which is equivalent of $21/month/user) is reasonable for you, you sign up. You never have to worry about disk space, number of projects, bandwidth (data transfer) etc. etc. Now consider our "auto discount" policy. We apply appropriate discounts to your invoices every month based on your average number of users in the month. You don't have to even ask ahead of time. You can now sleep well at night knowing that you are always paying for the exact number of users you currently have. Your number of users can grow and shrink on projects. You do not have to upgrade to add more users, and downgrade when you don't need them. With traditional SaaS pricing, you could end up paying more just because you forgot to downgrade.

Additionally, we put ourselves on the line by invoicing you at the end of the month (unlike everybody else). Not only that, we do not automatically charge your credit card (in fact, we do not even take your credit card information. That is handled by Amazon). Instead, we ask you to explicitly pay us every month. If you are not happy with our service in any month, we allow you to ask for waiver. This is because we want you to use it every day. We want you to actively help us shape our service that you love to use everyday. Not just pay and forget about it. We want you to pay us for the right reason, not because you prepaid us.

Finally, we plan to continue to bring to you more and more value added features at the same price.

We would love to hear from you what you think about our pricing model and policy.

Monday, August 24, 2009

ScrumPad affiliate program is live

We are excited to announce that our affiliate program is now live. This is our way to share the success with our ScrumPad community. If you are using ScrumPad and or have reviewed ScrumPad and think it is a tool that others should take a look and use, we encourage you to become our affiliate and start spreading the words for ScrumPad.

We wanted to make it simple. Anyone, individual or a company, can signup. When you signup you get an "affiliate id." After signup, just start referring people to ScrumPad, and let us take care of the rest- from keeping track of who you referred, and how much your refferal bonus is, to automatically paying you when it is due. It is that simple.

When you refer someone to signup for ScrumPad, and if they put your affiliate code in during signup, we credit you for that referral. You just need to make sure they put your affiliate code as a referrer. Alternatively, you could download our "affiliate badge" that you can put on your site(s). Anyone clicking through your site to ScrumPad and eventually signs up, your affiliate id gets automatically populated and you get credit for that new user of ScrumPad.

We have a very strong reward program for our affiliates. You get 50% of the first month's subscription fees paid by your referred client, and continue to earn 5% of subsequent monthly subscription fees for as long as they use ScrumPad. Isn't that cool or what?

We pay out your earned referral bonus at the end of every month when you accrue $100 or more. The only condition is that you have to have an account with Amazon. We process payments through Amazon FPS (Flexible Payment System).

You can check your affiliate account balance anytime by logging into you account as an affiliate from our site.

We hope you like our affiliate program and join.

Sunday, August 9, 2009

Reality check for Agile projects- working sofware over comprehensive documentation

We all have an ideal view of the world surrounding us. That is OK as long as we are aware of the real world and know how to rationally deal with it. We as agile practitioners have our own view of an ideal world. Last year I attended Scott Ambler's session on "Agile in Practice" at Agile 2008. In this talk, he challenged the common concepts and shared his findings. I found this talk very insightful and would encourage everyone to listen to this. In fact, it inspired me to write this series on Agile ideal views of the world.

I will talk about some of the "aspects" of this ideal agile world in a series of blogs. Last time I talked about "project management (PM) tool vs. no tool." The topic today is "documentation on Agile projects." This is third in the series.

The common perception about Agile projects in the market is that Agile teams follow cowboy coding and hence do not document. The myth about "no documentation" goes so far as that some see this as an incentive to adopt Agile and escape "over documentation" of the traditional waterfall projects. However, this couldn't be further from the truth. This misconception to some extent stems from misinterpretation of the Agile manifesto that says-
"Working software over comprehensive documentation"


The intent of this manifesto is to underscore the importance of "working software" and risk of "comprehensive documentation." This does not encourage us to do away with documentation altogether. I hope we all agree that the primary goal of any software project is the "working software," and the secondary goal is to support on-going maintenance and enhancement of this software. Scott Ambler refers to it as "to enable the next effort." We all know that cost of development is only 20% of the total cost of ownership of a software. To contain this cost and associated risks, we need "right documentation."

A few of the issues with the traditional documents are,

1. Documents are static. They are a snapshot in time. Hence, they quickly get out of sync with actual working software. Outdated documents increases project costs and risks.

2. Documents are created too early. Traditionally documents like requirements, architecture, design documents are created early in the project. As the project progresses, the requirements, architecture, and deign morphs. Either documents become stale or the cost of maintaining documents increases.

3. Documents are bulky. We tend to use Word doc, Excel, Power Point and the like to create our documents. They are disconnected island of information. To keep them in-sync with each other requires a lot of effort. As a result, we see a lot of repetition (wastage). It is also difficult to link information across all documents at the appropriate level using these old-school tools. For example, individual requirements to rules to test cases to decisions to etc. etc. It is difficult to browse the right related information just-in-time and just-in-place.

DDJ (Dr. Dobb's Journal) partnering with Scott Ambler ran a survey on how much documentation Agile and non-agile teams are doing. The result reveals that Agile teams are more likely to model than a non-Agile team and equally likely to create documentation.

Here are a few things I suggest to become Agile with documentation.

1. Certainly, no documentation is not Agile.
2. Find a way to implement a continuous, collaborative documentation (Wikipedia model). For example, allow end users to evolve and enrich user manuals as needed, when needed. Allow developers or support engineers to update architecture document or operational manual.
3. Delay documentation until it is requested. I call it "just-in-time documentation."
4. Keep the documents nearest the location of use (context sensitive). I call it "just-in-place documentation." For example, technical API documentation within the source code. Use tools like NDoc/Java Doc/RDoc to extract APIs accessible from IDE. User manual should be embedded through out the software.
5. Use Wiki or Wiki style tool to cross link different elements of documents to form a Web of interrelated information. I call it "accessibility of documentation."
6. Determine what to document based on frequency of use and number of consumers of the information. Importance of a document can be calculated by multiplying frequency and number of users. This could be used as a surrogate for a real ROI. The higher this number, the higher the ROI from the document. In other words, only document information that will be used by at least a group of people on a regular basis.
7. Use appropriate format for documenting information at hand. I call it "comprehensibility of documentation." For example, use "As a , I want ...., so that...." for documenting requirements. Use "given ..., when ..., then ..." (BDD style) to document acceptance tests. Use state machine diagram to document a stateful processing of data.

Scott Ambler goes in depth about documentation on Agile projects. I would encourage everyone to read the article.

Yes, documentation is a sticky topic. It is difficult if not impossible to strike a balance between amount (over vs. under vs. no) and quality (useful vs. redundant, correct vs. stale) of documentation.

What type of documents are you creating on your Agile projects? What tools are you using?