Good comments, and some skepticism, greeted my article about 6 things that you can skip to accelerate a software project.  Mirko wrote “You are crazy”.  A more serious criticism came from MikeB, who, like many others, works for customers that want fixed specifications with firm time estimates.  He wrote “What timelines do you have? I work for customers who purchase software or software services from us. This is a huge piece of the agile methodology that I don't see fitting in the provider-customer relationship. Customers need to budget as much as anyone does. You just can't tell them that 'no, we're not going to design this' and that 'we'll get it done when we get it done and just keep charging you along the way'.   Find me a customer that will accept that, and I'll retire right now.”

Timelines and budgets, in my opinion, are the easy part.  You can do a good job with a fixed price/budget, and a fixed timeline, if the deliverable isn't fixed.  So how do you get away without promising a fixed deliverable to a demanding client or sponsor?  You fix the important part.  You create a roadmap, a prioritized list of feaures, where the important things are sorted to the top.  You guarantee a minimum level of capability, and then you go from there.

Then, the whole thing fits together.   Agile methodologies deliver releases on a fixed time cycle.  So, they give you a much better chance of hitting your delivery date than non-iterative methodologies.  Your expenses are based on the time required (mostly, cost of labor per week), so if you can deliver on time, your budget is easily fixed at (cost per week) * (number of weeks).  You take some risk by guaranteeing a minimum deliverable, but that's your job.  At some point, you have to step up, and be good at what you do.

The thread is copied below.  At the end, I present our battle-hardened (but not foolproof) Assembla Consulting recipe for delivering a product on a fixed price / fixed time basis.  And, in extreme circumstances, I suggest this simple scheduling algorithm.

posted @ Friday, May 01, 2009 2:51 PM by MikeB
Hrmm - you develop software for a web platform that customers subscribe to. What timelines do you have? I work for customers who purchase software or software services from us. This is a huge piece of the agile methodology that I don't see fitting in the provider-customer relationship. Customers need to budget as much as anyone does. You just can't tell them that 'no, we're not going to design this' and that 'we'll get it done when we get it done and just keep charging you along the way'.  Find me a customer that will accept that, and I'll retire right now.  The Agile approach sounds all peachy - but in the business world... hmm...

posted @ Friday, May 01, 2009 3:08 PM by Andy Singleton
MikeB, I don't understand your comment. Agile or not, you have prioritize the features that you are working on for customers, and tell them "yes, we will do that" or "no, that is not on the roadmap." You have yes's and no's whatever your methodology. 
 
If you give a customer an exact time of delivery to an exact specification, and then miss the date, you are actually causing a worse situation than if you don't give a specific date. Under the agile methodologies that I propose, you do better for this customer in two ways. First, you move faster, so you have a higher probability of hitting any given date. Second, you can get them a release on a specific date, if that turns out to be important, by not committing to a fixed spec. 
 
I usually work with a fixed timeline, fixed budget, and some flexibility on the spec. So, perhaps Assembla's work does fit into the type of customer relationship that you are imagining. 
 
However, there are a lot of customers that like the idea of getting software when it is ready to be released, soon, but with no timeline. That's the policy that Google uses, with their soft launches and endless betas. Google is one of the biggest software companies in the world counted by either revenue or users, so it's clear that they have found a large number of users that do subscribe to their "we'll get it done when we get it done" approach, as long as the basic underlying service continues to work.

posted @ Friday, May 01, 2009 3:21 PM by MikeB
I see your point Andy - or, really, I -want- to see your point. I love the agile concept - however, again, I'm not sure that it works when a customer is purchasing a deliverable product from you. That is, when we're not building a product internally, or as a beta, to be released later for sale to a community (like Assembla and Google products).  
 
Let me try to explain my thinking (correct me where you see me wrong) - So in your case, you can certainly work the agile approach because you know that whatever changes you make to the solution are out of your own pockets. If its a worthwhile change, where you see the potential to increase price or number of sales, you'll choose to add it in. 
 
Contrasting this though with customers coming to you for a specific product to be built specifically for them - they need to know what it is going to cost; they'll require it - 15+ years in this business I've never seen different. Maybe I'm doing somehting wrong, I'm always one to listen to critique...  
 
So, how can we give a price tag and at least a close timeline if we start so loosely and allow change along the way. 1) we never know what it will cost us to build it and 2) the customer will never know what it will cost them to have it made. 
 
I know I'm probably in an old school paradigm, but I am able to look outside the box... I just wish I could make more sense of this - I'm even having a tough time explaining it here. But really, I do appreciate your feedback on this as I really do want to visualize this working the way its supposed to. I just haven't found a customer to support it - they have to know how much money they are going to spend - just like everyone else. 

posted @ Friday, May 01, 2009 3:42 PM by Andy Singleton
MikeB, it can work if you assume that the specification is not fixed. At Assembla Consulting we work on fixed cost, fixed timeline development projects, and here is how we quote it.   

First, we make a roadmap, a list of features sorted in priority order. Whenever possible, we pull features apart so that we can deliver a simple feature first, and add to it later.  
 
Then, we read down the roadmap and we draw a line under the minimum feature set that we think will make a useful release. That's our guarantee. We take some risk to guarantee that you will get that much, within a fixed budget and timeline. There should be a high probability of going considerably beyond with the same budget and timeline.  
 
Then, we decide on a timeline that includes a first useful build, a beta release, and usually, a full production release. These timelines range from 8 to 26 weeks, and typically are more controlled by the business schedule than the development team.

Then, we design the team or "level of effort" that we think we need. Admittedly, this requires a rough estimate of the work to be done. The team has a certain weekly cost.  
 
The budget is equal to the cost per week, times the number of weeks. 
 
Then, we work on the roadmap in order. We assume that the roadmap will change approximately weekly if we see opportunities to improve the product. We release daily for the development team, weekly for the client, and to bigger groups on the dates promised. We try not to make a decision about when to release, but instead, discuss who should see the release, depending on its level of maturity.  
 
With this technique, the exact deliverable is not fixed, but you have a fixed budget and timeline, and you always get a useful product.  
 
This method is not appropriate for someone who absolutely requires a fixed spec - probably because their budgeting process is so unwieldy that they only want to go through it once. However, it produces a MUCH more reliable timeline than other methods, and it leaves open the possibility of getting a better product than you initially specified.

posted by MikeB
Very good clarification Andy, thanks. This has spurred a great conversation. I have often wanted to hear how another business owner utilizes this agile approach. I'll take a little time to re-read and further absorb your response - I may reply or may not reply again - but your post allowed me to air something that has been bewildering me for some time. heh  
 
It was particularly useful hearing a response from a business owner and developer, rather than simply from a developer high strung on agile. 

The June 16 release contains some significant changes to the Files tool, plus small improvements to the Tickets and Wiki tools.

New Files User Interface

Our Files tool offers a way to manage the files you upload using Tickets, Images or Messages. The new user interface gives you faster navigation, and batch operations. You can now assign files one or more tags so you can find them with a filter. Apply bulk updates to tags or deletions. Or, find files with the new files search bar.

Improving Menu Speed

Customers have told us how much they like the new Ajax right-click menu on Ticket lists.  They asked for faster loading.  In this release, the links for  "copy link" and "open in new window" will display instantly while the ticket data loads.  In the next release we will use more javascript tricks to pop up the whole menu instantly.

Save Your Hard-Earned Wiki Edits

Some users were very disappointed when they typed a long wiki page, and then lost the content when they accidentally navigated away.  Now, when you try to navigate away from a wiki page you're editing, a message now warns to save your changes.

Video demo 

For a demonstration of the changes, watch the video on Youtube, or below.

Creactive, a company working out of the Czech Republic, is one of many Assembla subscribers working in a language other than English.

The company works on projects in Assembla and sells the applications' services to customers who speak Czech, Polish, Slovak and English. They create e-shops, portals and content management systems and present them to clients like sports companies and clothing retailers.

Creactive began five years ago. Founder Adam Kurzok graduated with a law degree, but he'd dabbled in online business, and what he really felt like working on was, as he puts it, "a really good start-up."

He started Creactive with a graphic designer friend, and at first, that's what the company did - straightforward design. The new webdesign studio adopted the slogan "Where pixels make love." But Creactive expanded its scope and started advising fims using Kurzok's e-commerce knowledge. It then moved on to creating its own applications for other companies.

It was in creating these applications that Creactive needed project management help. The company first used simple wikis to work on group projects, but they ran into the usual problems of wiki collaboration. Then, a year ago, they came to us.

"Assembla connects crucial things for every project and is a great time-saver," says Kurzok. "It enables one person to have the overview of his project, documentation and back-up in one place."

The company now makes applications for clients while working on its own projects at the same time. Like Project Lunchtime, Creactive's catalog of nearly a thousand Czech restaurants' menus. Over 4,000 people visit the site daily to decide where to eat. The site features a tool that lets restaurants promote themselves, and Kurzok plans to expand the service to let customers book reservations and order food online.

Creactive makes its projects in Assembla, and clients sometimes view them as watchers, such as when e-shop users submit tickets with the support tool.  "Our basic philosophy is to make thing easier yet more effective," says Kurzok. "Assembla helps us this way."

When I started Assembla, Rentacoder was the first place that I advertised to find programmers, and I was not disappointed.  They have a huge number of talented contractors on their list.  Three years later, we are still working with some outstanding core team members that responded to that advertisement.  So, it's not a coincidence that our online workspaces fit perfectly with the Rentacoder idea of on-demand, global teams.  It's a privilege to be able to announce that Assembla is now officially providing workspaces for Rentacoder projects.

The Rentacoder integration demonstrates some interesting features of Assembla that other users can learn from, including the affiliate plan, branded portfolios, and user-defined configurations.  I'll discuss that below.

First, I will suggest some ways that you can adapt Rentacoder to an agile process.  When you post a job on Rentacoder, "coders" respond with fixed-price bids.  You select a coder by evaluating the price and track record of a coder, and start work on the fixed price job.  Rentacoder does arbitration to resolve any disputes about when the work is done.  This type of fixed-price bidding is great for small jobs, but it isn't very agile. 

We don't recommend doing fixed-price work, since that fixes your specification too early.  In our recommended process, you try working with "coders" for a week, and then ask them to join the long-term team if that works well, and typically pay hourly.  Rentacoder offers a couple of special features to make this work.  I used to buy a "bulletin board" advertisement from them.  You pay for this advertisement in advance, and then you aren't obligated to use the Rentacoder bidding and payment system.   However, I have just received word that Rentacoder will be soon be supporting hourly payments, which will work great with an agile process.

Let's look at some of the secrets of this integration.

User-defined configurations

We defined some template workspaces with custom configurations, and added them to the catalog with the tag "rentacoder", as you can see here.

Branded portfolios - Branding

The Rentacoder configurations are part of the Rentacoder branded portfolio, so they get a nice customized header, style, and link, like this.

Portfolios - Automatic permissions

In order to provide arbitration services, Rentacoder needs access to all communications between the client and the coder.  This helps them check to see if the client requested something new that wasn't in the bid, or if the coder offered something.  Assembla solves this problem because new Rentacoder spaces automatically become members of the Rentacoder portfolio.  The arbitrators are team members in the portfolio space, and they have read access to the member projects.  When the Rentacoder phase of the project is done, the project owner can remove the portfolio link, and work privately.

You can use this feature of Assembla user-defined configurations to accumulate proposals, contest submissions, or budget requests in a portfolio, and review them.

Affiliate Program

UK-based Web design and marketing company Jojet is doing exactly what Assembla was first designed to do - building and managing an agile distributed team.

Note: This is our first post from guest writer Ryan Menezes, who will be profiling Assembla users with good ideas about how to use the system.

Jojet has been using Assembla for around 18 months. Jojet is what CEO Joel Hughes calls one of the "good guy" web firms - it uses white hat SEO and actually takes web standards seriously.

Jojet used hardly any remote work between its formation in 2001 and when it started with Assembla. Joel had freelanced a ton earlier in his career, including private contracting to ready firms for Y2K, so he realized that sticking to in-house work held Jojet back. But proper remote development needed source control. He began researching project management services till he found the one he wanted.

"Assembla just came out tops," says Joel. "And still does."

Since then, the company's ammassed a whole circle of freelancers in the UK and abroad. One worker, who Joel hired right around the time he signed up with us, lives in nearby Cardiff. He still does a load of work for Jojet, but he and Joel have only met in person once.

It's been a good year for Jojet. They began working with Underwood Insurance right when they signed up with Assembla. The site now comes up as number one on Google for several of their key phrases. Before Jojet stepped in, it appeared nowhere in the first ten pages of listings.

Another client, Learning Providers, bagged more than 20 new paid registrations in a short period after Jojet redid their site. Earlier, they had managed no new subscriptions for a year and a half.

Joel doesn't want to host his own project management apps any more than he'd want to host his own email or DNS servers - the admin overhead would cost him way too much. That's why he tried online subversion repositories, and he found we offered the most features. He likes how we handle the SVN side, and he calls ticketing a key part of Jojet's development procedure. Our "killer feature" though, says Joel, is support.

"When something was wrong it got fixed sharpish!" says Joel. "More than that, Andy Singleton and Jeff Carl have both taken the time on previous occasions to listen to my concerns or listen to my ideas for new features. That is cool."

In the next year, Joel sees the company growing even more. Turns out that right before talking to me, he was writing a job description for a new recruitment ad, trying to grab even more new developers and designers.

Yesterday's release has the usual small improvements, along with some bigger changes to speed editing of Tickets, manage subprojects, and private Wiki and Message posts.

New Privacy Settings

For months, the top user request on feedback.assembla.com was about control of customer permissions.  We have implemented this in three layers.  First, we created a role called "Watcher" that you can use for customers.  Second, we implemented tool-by-tool permissioning, so that you can let watchers see some tabs, but not others.  Our users continued pressing the discussion, asking for a private setting on individual wiki pages and messages.

Now, if you are working in a space that has a paid subscription plan, you can select a "Private" setting when you create a wiki page or a message. When you view the wiki page or message, you will see a red banner reminding you that we won't display it to watchers or non-team members.

Manage tickets in subprojects

This was another frequent request.  Do you have multiple teams working?  You can now use the Portfolio tool to add subprojects (portfolio members) to the project that holds your main ticket list.  You can create filters and do searches that show tickets from your master project and all of your subprojects.

Tickets Get Faster

Improvements this week speed the way you work with tickets.

1. Fast popup editing. Right click on a ticket in a list or filter. A pop-up menu will let you directly edit it, reassign it, re-prioritize it or change its status.
2. Faster form editing. Click on the Edit tab in a ticket page, and the Edit form swaps instantly into place. It's faster, and it keeps the history and other attributes handy.
3. Faster list navigation. Buttons on the top of a ticket page take you to the previous or next ticket, without needing to return to the main ticket list. 
4. Faster association. You no longer have to scroll through a list of existing tickets when associating an old ticket with a new one. Instead, type in the first few letters of the ticket's name. A drop down menu will offer the ticket your'e want.

Copy Your Space!

You may not have known that you can copy an entire space, as a template for a new project. Through the admin tab, you can now place a copy button in your space's header. We also allow you to restrict copying if you want to.

Video demo

For a demonstration of the changes, watch the video on Youtube, or below

My presentation on cloud hosting providers - "Compare and Contrast" at Boston Barcamp attracted a good crowd, including some guys with expertise in Google App Engine and Microsoft Azure.  I divided the cloud hosting world into two main categories.  Category one is hosts that give you individual servers, like Amazon EC2 and Rackspace.  Category Two is the hosts that give you a scaleable cluster of services, like Google App Engine or MS Azure.  When should you commit your business to one of these models?

First, I will review how servers came to be concentrated in big datacenters, where they are now in the process of becoming virtual or "cloud" servers.  In the beginning (1994/5 for me), Internet businesses would set up servers in their own offices.  You had to beg, beg, beg your monopoly phone provider to pull a wire into your office.  If that worked, you had the problem that power would go out on hot summer days and your servers would go down.

Co-location

Anybody serious started moving servers to datacenters where they could get "co-location".  The datacenter brought in multiple high-speed network fibers, and provided backup power generators, and a rack.  You brought in the machinery, and stuck it in a rack.  This was OK if you were willing to wait for vendors to deliver your equipment, and if you lived close enough to the datacenter to visit and crawl into the rack.  There are still a lot of people that do this.  It seems slow and painful, but it gets you exactly the network topology and equipment that you want.

Here, you already see one of the main tendencies of the hosting business.  There is an advantage to going with bigger providers who can build huge datacenters that have big power systems, big network pipes, multiple datacenters for emergencies, and can absorb or deflect DDOS attacks.

Server Rentals

In the next phase, you could call the hosting vendor and rent a server that the vendor would own and stick in the rack, on as little as one hour's notice.  That saves a lot of time and energy.  I would guess that most people who are moving to "cloud" or virtual hosting are moving from this model.  The rental model can be more economical if you need a fixed set of servers.  However, it has problems with reliability.  If a server goes down, it takes some time to fix it or replace it, and you are relying on the inconsistent expertise of the host admins.  Essentially, you need to buy two of everything to get hot swaps.  We've seen problems ranging from "your ethernet cable pulled out" to "Our power room exploded and 9,000 servers are down."

Get a Server: Virtual hosts

When Xen server virtualization became available, you could order a virtual server.  The menu of servers fromt these first generation providers looks very similar to the menu for the non-virtual rentals.  You can select from a fixed set of operating system configurations and "slice" sizes.  However, you can get the servers a lot faster, and you can get smaller slices, and in most cases you can save images and swap instances on the fly.  These hosts can be considered "Cloud" hosts because they will deliver a server on demand.

Get Your Server:  Virtual hosts with custom images

In the following generation, you can build your own server images, and save them in a catalog.  Obviously, this gives you a bigger menu of configurations that makes it easier to get started.  The most important impact is that it speeds the process of replacing servers or expanding your sever cluster.  You no longer need to have two of everything.  You also get an API for starting and stopping server instances, so you can have scalability in your server count, or automated hot swaps. 

Amazon was the first vendor to provide this level of handling for virtual server images, including a catalog, and they dominate this business now.  At Assembla, we are intending to use custom server images to provide workspaces for popular development platforms that include instant-on staging servers with pre-configured continuous integration.  I have talked to a number of other virtual hosting providers, and most of them do not support a catalog of customized server images.  It's an important capability.  There seem to be some obstacles to implementing it.  In any case, I think all virtual hosting vendors will eventually offer a catalog of images.

Most production systems involve a cluster of servers with different images connected in a particular topology.  This ranges from a simple app+db cluster to the 6 server types we need to run Assembla.com.  There are vendors that sell management software to manage these clusters on server-based virtual hosting, and Sun is showing a prototype of their service which includes a graphical editor for building and deploying clusters.

Get a scalable cluster of services: Google app engine, MS Azure, Appforce, Morph, AWS

All of the above hosts will sell you a server.  You are responsible for deciding how many servers you want, and configuring the servers.  The next emerging category of cloud services doesn't sell you a server.  They provide you with services that run on a cluster of servers, which they maintain and configure.

The upside of this approach is scalability.  As long as you follow their rules, they can run your application or service request on any of their servers, and they have a lot of servers running.  For example, with Google App Engine you build a stateless application that can respond to a web request by starting fresh and looking in Google's "datastore". Google can run this type of stateless application anywhere on their vast network of servers, and you get an app that can handle any load.

Amazon Web Services (AWS) is also a big player in the services business.  They offer scalable services for data storage, computation, queuing, etc.  There are also third party services like Morph and Heroku that build on the Amazon platform by organizing servers into services.  Salesforce.com has a relatively mature offering that they call the Force.com platform. Microsoft is launching the Azure Services Platform, which gives you servers and services that are almost, but crucially, not quite, like your installed windows servers.

The downside of this approach is that you have to follow their rules.  This category of services is emerging, not emerged.  The rules can be quite strict, and the services are incomplete.  For instance, some services allow you to build apps that use database data, but cannot save files.  Google apps have to be stateless, and written in Python or recently, a subset of Java.  These restrictions are necessary if you want scalability, because the servers in clusters are all the same.  They aren't configured with your special stuff.

Clearly, these services will become more complete and ever more compelling.  That is going to force buyers to make some decisions.  You can move a server to a new host, but you typically can't move a service.  How much do you trust these vendors?  How much are you willing to invest in a product that can only run if one of these vendors supports it?  Is Google always not evil?  Does Microsoft have a stable business model? Will Salesforce.com jack up their already high prices, or just compete directly with a successful service?

Entepreneurs are also going to have to ask themselves what services are going to be the domain of the big players that run the datacenters - Amazon, Google, Microsoft, Sun/Oracle - and what services will run as value-added applications suitable for startups.

I think that as the "service" providers get more mature, there will be some portable standards and open source solutions, which will make it easier to move not only servers, but services, and that will drive adoption.  For example, Amazon compute service are based on Hadoop, and open source framework that you can run on other hosts.

Please let me know if I missed something in your area of expertise.  Thanks.

I found two interesting things in this review of a new book Senior Leadership Teams.

The author says:

People assume, for example, that teams that work well together are better and more productive than those that don't. "The cause-and-effect is the reverse of what most people believe: When we're productive and we've done something good together we feel satisfied, not the other way around," says Hackman.

This is an important thing to remember.  Teams do not work well and feel good because the team members like each other personally.  Teams work well and get along when they succeed with shared goals.  This observation drives two of the listed recommendations.  The first recommendation is to set "compelling" direction.  People need to sign on and share the goal.  The second recommendation is be "ruthless" about team membership and kick people off if they don't contribute.

The other interesting point is about "deviants" - people who often disagree with the other team members.  Great word, "deviant".  The author thinks that deviants often bring up good points, and that "teams with deviants outperformed teams without them."

Today's release comes with the usual package of small improvements, and some bigger features that are worth reading about.

Affiliate plan - make money, give away discounts

The new Assembla affiliate plan pays a 25% commission to users who refer new subscribers.  You can also give away a $5 discount, just by giving potential subscribers your login name as a referral code, or by referring them with an HTML link tagged "?afflilate=<your login name>".  You will find details about the Affliiate plan in the new "Affiliate Program" and "Affiliate Earnings" pages of the Money tab in your user/start tab bar.  It takes only one click to agree to the Terms and Conditions, and then you can start giving out the discounts - here.

Activity Stream for all your spaces

Get real-time view of activity in all of your spaces.  Observant users have probably noticed the new Stream tab on the user/start tab bar.  Use the right sidebar to follow and unfollow events from particular spaces, get a report on one space, or navigate to a space.  Tell us what you think.  If you like it, we might use this page as a simpler, more active, default user/start page.

Hide the Team tab in Support spaces

We got a good response from users that tried our Support tool - here - to collect support requests and tickets.  Many users configured the Support tool to be visible to watchers or public users, and they wanted to hide the Team and Stream tabs.  Originally, we didn't offer permission settings for those tabs, because they are permanent features of every space, and not optional tools.  In this release, we give you a permission setting that will hide the Team tab.  We are not providing an option to hide the Stream tab, because we need to guarantee at least on visible tab, and we hide the non-permitted events from visitors, and we need to give every user a chance to edit his email alert settings on the sidebar.  This change should free you up to show the Support tool to more customers.

Videos

We organized our screencam videos here in the new Features section.  They illustrate workflows like "Space Creation and Configuration", and "Time Tracking and Reporting", as well as individual features such as Portfolio, Messages, and Wiki.  We will enhance this list soon with the most important workflow: how use Assembla Tickets in agile development.

Sign up for a beta test of the Private installation

Our Plans page mentions an installed version of Assembla, the Private installation, and we have heard from a number of people that need an installed product to meet security requirements, or for customization.  Our first few installations were challenging.  It's not easy wrapping up a scalable online service with more than a dozen servers and processes. 

So, we made a VMWare image with everything installed and ready to run.  And, we built an installer application so that you can configure it in minutes.  And, we moved the home page to a wiki so that you can customize your message to users.  And, we added a process dashboard so that you can see what is going on with all of the bits whizzing around.  We're getting ready to offer this complete package with unlimited workspaces, full source code, and a perpetual license.  We could use your feedback.

If you want to try the Private install beta release, sign up by filing a ticket here.