BT

Does Agile Promote Perpetual Beta?

by Vikas Hazrati on Oct 12, 2010 |

Agile software development promotes teamwork, collaboration, and process adaptability throughout the life-cycle of the project. More often than not, this also leads to a lower time to market with a minimum marketable feature set. New features are slipped in every iteration and the product often remains in perpetual beta.

Practices like continuous integration and continuous production often affect the product lifecycle and give the organization much greater agility. As Tim O'Rielly commented

...The open source dictum, "release early and release often" in fact has morphed into an even more radical position, "the perpetual beta," in which the product is developed in the open, with new features slipstreamed in on a monthly, weekly, or even daily basis. It's no accident that services such as Gmail, Google Maps, Flickr, del.icio.us, and the like may be expected to bear a "Beta" logo for years at a time.

Project smart suggested that Agile methodologies and perpetual beta go hand in hand.

Instead of delivering software that has all the knots and bolts in place according to its original design, the highest priority is satisfying the need of the customer with a simple but working version. The adage, "in perpetual beta" also applies to agile method; software improves with every iteration until all the "nice to have" features are in place.

Mike Loukides suggested that having the product in perpetual beta not only takes away a lot of pressure but also helps in encouraging creativity. According to Mike,

The perpetual beta, first formulated as “release early, release often,” is one reason behind the success of many open source projects over the years.

In their whitepaper on transitioning to Agile, OutSystems suggested that the cornerstone of all Agile techniques is interative and incremental flow which resembles perpetual beta. Since customers are a part of the Agile team, they help in shaping the system by adding bits of functionality every iteration.

However, not everyone is amused with the concept of perpetual beta. 'Getting Real' by 37signals, warns against the excessive use or longer duration of the beta tag. According to them, companies must decide how long it is really necessary to remain in beta before it starts becoming just an excuse for a weak application

Jeff Atwood suggested that perpetual beta is becoming a very disturbing trend. According to Jeff,

Perhaps the most troubling trend is the perpetual beta. So many websites stay in perpetual beta, it's almost become a running joke.

Mat Scales commented that perpetual beta is nothing but lack of confidence on the part of developers. It is a faint attempt to show that developers are still innovating. However, more often than not, it is a signal to say that there could be potential issues with the application but that is fine.

Thus, though releasing in small increments is useful for the development team and the customers, however, the team should be cognizant of the duration that they want to stay in beta. If products continue to use the beta tag to shield their weakness then soon the “perpetual beta” may lose its popularity.  

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

true by mohd yaqub

This is true and perpetual Beta is Good

Good or bad? Depends on the company and application we're talking about! by Michel Ozzello

Hi Vikas,

This is a great collection of information on this topic! Thanks.

Overall I agree that the perpetual beta concept is a good thing since it means the application is constantly growing and improving.
On the other hand I also agree with the comments by Jeff and Mat, about the overuse of the perpetual beta and the loss of confidence it gives users.

What one should do is look at the type of application and company we're talking about.

If we're looking at the product of a company (which can be licensed to paid subscribers), then the Perpetual Beta can indeed have a negative impact on the perception of users. It gives them the idea that the company is not sure if their product is working at 100%, and the Beta tag is like a safety net: "If we're in beta, no one will mind with an occasional bug, low performance or system crash!".
This is wrong and a bad growth strategy.

However, if we're talking about an enterprise application, built inside a company to address a specific business need, then the concept makes a lot of sense. Usually, internal applications don't bear the Beta tag, so there is no marketing involved here. The application is rolled-out once it offers the right level of functionality to be of value for the business.
After the company is rolled-out to the business user's base, It will start receiving feedback for new features and change requests.

Let's assume the It department is using an agile methodology with a 4 week sprint. If the IT team can fit those requests and feedback into the maintenance backlog of the application, and release a new version every sprint, then you can consider the application to be in perpetual beta.
In this case, the users will not look at the application as something that is unstable and incomplete. Instead, they will look at IT as a team that takes their feedback seriously and is committed to deliver the solution they really need. In this case, we shouldn't say the application is in Perpetual Beta, but instead say that it is "Evergreen" - always evolving and always up to date, effectively serving the business and users as their needs change, and never becoming obsolete.

Would you agree?

Re: Good or bad? Depends on the company and application we're talking about by Mike Jones

Michel,

I completely agree. I am with OutSystems and we talk about a development cycle where our customers schedule regular maintenance sprints once an application has gone live to react to change requests. These are usually 2 week sprints where we pick up incremental changes thus keeping the end customer very happy with their application. When the change is too large we then suggest the customer prioritize the need and then define a full project to accomplish the task. The result is what we like to call Evergreen applications - they keep up with business change and age very slowly if at all.

Beta might not be such a bad thing by XebiaLabs XebiaLabs

Vikras, this is an interesting perspective on agile methodologies. Constantly updating an application does leave it in perpetual beta. Rather than releasing application XY 1.0 and then XY 2.0, the two blend together as continuously automated upgrades blur the lines between versions. Instead, there are hundreds if not thousands of versions, each with minimal differences and updates from the previous. However, rather than looking at this as a negative thing, we think it’s important to realize the benefit this offers to end-users and IT departments alike. End-users no longer have to wait for the next version of an application, and can even influence how their application runs because adjustments are constantly being made to the application. IT departments, similarly, reduce their workload through tools like deployment automation that can continually upgrade and modify the application to keep it up to date instead of having to do all this by hand. Would you agree?

Re: Good or bad? Depends on the company and application we're talking about by Vikas Hazrati

Hi Michel, i really like the term "evergreen". Largely I agree with your analysis. I think for SaaS applications it might be harmful to stay in beta for a long time. I however see the case where SaaS applications start in the beta phase for a short time, allow early adopters concessions to try their application before they shed their beta tag(for e.g. bookMyHours.com) and then open up as general availability. And all of this should not happen over a span of 5 years. There should be a healthy duration to get from beta to GA and that should not be 2 weeks and not a year either. Thoughts?

For internal applications, you are right there is not even a need for the beta tag.

Re: Beta might not be such a bad thing by Vikas Hazrati

True continuous integration and continuous production are essential. Any tools / techniques to help with those are helpful too.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT