We released a new version of Assembla.com today, with the following changes and improvements.

Tickets

Ticket Notifications: We changed the way that users get email alerts about tickets.  These alerts are important for a team that works together in real time.  However, an active project can generate so many of these emails that many users start ignoring them. The optional hourly report did not have enough information.  The optional "subscribe" strategy in ticket settings was confusing.  We have replaced all of these email options with "Follow a ticket." 

• If you follow a ticket, you get instant emails about it.
• Tickets that you follow have a red star  (assigned to you) or yellow star  (followed by you) before the summary.
• Tickets that you do not follow have a gray star .  Click on the star to follow or unfollow.
• If you create a ticket, or are the assigned-to user, you follow the ticket.
• You can add followers to a ticket using the "Subscribe" form in the notification panel.  This is useful if you want to show clients or bosses what you are doing.  You can also add an email address, even if it does not match a team member.
• You can see the tickets that you follow by selecting the filter for "My Followed Tickets".
• You will no longer get alerts about all tickets in real time with the default stream page "email me when an event happens" setting.  Instead, you get an hourly report with the subject "Summary for <project>" listing activity in the past hour.
• The stream page shows more detailed activity reports, including changes in ticket status and assignment.

Ticket export options: You will see RSS, CSV, XML and Print options on top of any ticket list.  This makes the export features much easier to find.

Email Tickets and Messages: Many users do not know that they can email Tickets and Messages  Now you will see a "Post via email" button on the top of the Tickets and Messages tools.  This uses a mailto: link to pop up an email, making the feature easier to understand.

 Google and Yahoo login accounts

Login with the Google or Yahoo accounts (via OpenID).    We think that the Google login option will be popular because of a remarkable statistic about our user base.  Almost 50% of them use gmail addresses.  This also starts us down the road to better integration with Google Docs.

You can register in seconds by selecting the Google or Yahoo login buttons.  This will create a new account and ask you for a bit of optional information.  We recommend that you enter an Assembla password, because you will need it to use a subversion client.

If you have an existing account, you can login with Google or Yahoo, and it will match your account by email address.  You must enter the matching email address in your user profile, and for security reasons, you must have a "verified" email address.  The address is verified if you responded to an email invitation, or if you registered and responded to a verification email by clicking the included link.  You will see a "Confirm email" panel on your start page if your address is not verified.

Code Browser Styles

 Code repositories in the Source/svn and Source/git tools have a new style that is easier to read.

 

Unseen but Important: We moved our message queue to RabbitMQ for increased speed and capacity.  The message queue is important for scaling.  It handles all of the Stream events, including their email alerts, webhooks, build triggers, etc., and also handles long-running requests such as repository create requests.  We made about 50 other fixes and improvements, which we hope will improve usability and reliability.

We will install a new release tomorrow, August 24, starting at 08:00 UTC. The system will be down for up to 1.5 hours. We plan to bring it back online before 09:30 UTC

I understand that this downtime is frustrating for some users in Europe.  However, we believe that this new release will be worth the wait.  It includes about 70 improvements.  There significant improvements to the Support tool and to Ticket notifications.

We need scheduled downtime because we are making changes to the database to improve performance, and we are moving our event queue to RabbitMQ, which will improve reliability.

//

This post is from Sergio Romano, Assembla's product leader and skilled technical lead.  He's currently deep into the process of building an advanced set of portfolio and ticketing features.  Here he takes some time to recommend "iterative planning".

 

I originally got the idea for this blog article when Santiago Ceria, a professor from my university who also happens to be responsible for process and quality improvement in a big outsourcing company in Argentina, made a bold remark to our class that "Estimation is a REQUIRED step in EVERY project plan". I respected Professor Ceria, but I couldn't agree with him less.

Estimation in Today's World

Software engineering is a young discipline and thus it is heavily influenced by the project management "fashions of the day". You see people jumping between Waterfall, RUP, Scrum, XP or whatever is hot at the moment. Despite the great diversity in these approaches to software development, one can extract some nearly universal principles by threading a middle path between them. 

I believe that ESTIMATORS have swung the pendulum too far in one direction and have taken estimation to a point where it is counter-productive. Luckily, there are guys like Andy, our CEO (check his posts about estimation and other things you should avoid), the 37 Signals founders and Kanban gurus who are starting to move pendulum back in the opposite direction.

I see two reasons why estimation is so hyped right now.

Reason 1 - Clients & the Illusion of Control

The first is that clients always ask for a detailed timeline. However, what they actually want is commitment. This carries a lot of weight because when big projects are undertaken, they are generally paid for with someone else's money.

Mostly, they want to trust that you will finish.  I may be an idealist, but can't we build trust without a schedule that is managed with a stopwatch? Let's look at an analagous example, do you vote for a presidential candidate because of their timeline or because of the solution they propose to fix a problem?  Trust comes from successful incremental releases.

Reason 2 - More detailed plans

The second reason that estimation is so hyped is that estimators often provide a more detailed plan. But the real question is: "Is it always better to have a more detailed plan?"

Let's look at 3 simple examples - each more detailed than the last

1) John will do task A and then he will do task B

2) John will do task A in approximately 2 hours and, after finishing it, he will do task B in aproximately 3 hours.

3) John, who will probably be wearing his favorite yellow shirt, will do task A in aproximately 2 hours and, after finishing it, he will do task B in aproximately 3 hours, but only after taking a 45 minute lunch break.

It's clear from #3 that more detailed plans aren't always better.

On the other hand, the level of detail in plan 2 may seem more reasonable than plan 1. Of course, it depends on the precision of those estimates and the amount of time it takes you to make them. If it took you one day to figure out that it should take John 5 hours to complete his tasks, I bet you would have preferred that he just got started.

Will the more detailed plan make things worse?

I will raise the ante of this discussion, by asking whether detailed estimation will even cause you screw up your project.

Many people will grudgingly admit that initial estimates are often wrong by up to a factor of 4. This lack of precision, whether it is in the form of overestimation or underestimation, is sure to cause problem such as: incorrect decisions, Parkinson's law, less chance of success, etc.

And, if you believe this, we are not just wasting the time we spent estimating but we are actually causing problems in the project itself.Of course, the counter argument is that estimating up front will give you more confidence and control at the beginning of a project. But, is that really the case? 

A lot of people think that if you have a very detailed plan you will have more control of your project. I believe that a detailed plan ties your future to your past: You may find yourself saying, "Sure, this is the best way to go, the plan that we created a year ago says so and we haven't had any problems following it so far". That may be the case, but have you consider the new competitors that have sprung up or the changing economic conditions?

 

The Solution: Iterative Plans

I believe that not only should development of a product be iterative, but also the plan for development of a product as well. This is especially true if you are designing your own products where you have to be very careful not to invest more than is needed.

I think we need stronger theories about iterative plans. Do you want some tips? Check out previous posts from Andy about how we do our work.

An iterative plan is a great choice for an iterative development methodology with client participation (ie: agile). A very detailed initial plan goes against the benefits of a iterative product development. It may be controversial, but I think that minimizing estimation actually minimize the risk of the project.

The last ten years have seen a massive increase in the productivity of software development.  New techniques that I call "fast, lean, and global" are allowing startups to build software for one fifth of the cost of ten years ago, and get it to market faster.  The same techniques are revolutionizing the delivery of software and online services from bigger companies, and moving into enterprise IT delivery.

At Assembla, we study fast, lean, and global software teams to build better tools for them.  We have identified a few key components that are driving the productivity revolution.  We also describe a set of practices - basic, intermediate, and advanced - for taking full advantage of these components.

Components 1) Open source and sharing

Free. Open source code, community development. Platforms and API's with sharing, versioning, and contribution strategies. Google searches that get you answers within minutes, not days.

2) Agile and Incremental development

Agile, scrum, kanban, daily builds and continuous integration/improvement, rapid release cycles, lean startups, minimum releasable products, automatic updates.

3) Distributed teams

Strategies for working together, collaborating, and managing. IP capture, management, and delivery.  Open-source communities, outsourcers, freelancers, multinationals, on-call admin and support.

4) On-demand Cloud services

Software and servers whenever you want them with no capital investment or setup.

Does it hold together?

The big question that I get is “Why link these components?” Yes, each of them is important.  Why not just study them, or teach them, one at a time, as the need arises?

We asked ourselves a similar question when we were building up our cloud development services.  We found that we weren’t just pitching “development and management of complex cloud applications.”  We were pitching the whole gummy ball of agile, continuous releases, and open source adoption, global on-demand teams, etc.  It all got stuck together.  We couldn’t pull it apart.  

I started thinking that these components really are stuck together.  For example, you can’t run a cloud datacenter without open source software.  There are too many servers to license, with too much infrastructure tweaking and versioning, to do it without using open source software.  And, you can’t build open source software without distributed teams.  You can’t make anything that complex work reliably without incremental development and releases.  Each is dependent on the other.

Practices

Practices are things that you can learn to do.  They help you take advantage of these large-scale components.  The “Fast Lean and Global” concept will be helpful if helps people learn useful practices in a straightforward way.

I find myself describing practices as Basic, Intermediate, and Advanced.  Let's look, for example, how these three apply to open source:

Basic: “Do research to find and test open source technology.”

Intermediate: “Contribute to open source projects.”

Advanced: “Organize and manage community projects.”

We don’t have a comprehensive list of the key practices in each of the three categories yet; that's where we need help from experts.  But, we do have a pretty good idea about some practices that work for us.  Here is a sample list:

//

We recommend that a distributed team have a driver that we call a "Technical Lead".  The Tech Lead manages the ticket list, answers questions about engineering, and works with the developers to get stuff done.  This person needs to be both a developer, and a manager.  It is not an easy job to do, or to recruit for.

However, it's not a hard job to learn - if you get the right guidance.  We believe that a technical lead can build and manage a very productive distributed team by following a checklist containing a small number of daily, weekly, and bi-weekly tasks.  Here they are:

DAILY

• Require written standup reports each day.  Read ALL standup reports. If someone did not write a standup report, contact them by chat or email, and escalate if they do not respond.
• Attend a daily chat. Ask for comments and issues. Make it short. Move long discussions offline.
• Resolve any needs or roadblocks posted in StandUp by a team member in the scrum chat.
• Look at the detailed activity report for each developer.
• Move any request, agreement to a ticket/message/wiki. Do not rely on chat agreements because they can’t be tracked.
• Let team members select their own tasks. Balance load. Do not let team members work on many tickets concurrently. A team member should select one or two tickets to work on and finish. The rest are available for others to select.
• If someone has been working for several days on one ticket, without committing, ask him to split it into smaller tasks.

WEEKLY

• Review all tickets for the current milestone. Add or move depending on schedule and capacity.
• Ask specific developers to take the planning and task breakdown for complex tickets, features, stories.  To distribute the load, you should also be getting mockups and stories/scenarios from a non-developer product owner.
• Write and post a message about what the team did last week and what the team will do next week – a sort of scrum of scrums report

BI-WEEKLY TEAM BUILDING

• Look at new developer applications and say who you are interested in.  Someone else should handle the details of finding new candidates and then getting them started.
• Do “onboarding”. Make sure each new developer has the information he needs, a development environment, and a simple task. Help the new developers to update the setup documentation. Send them contact information and an outline of the daily requirements (standup, chat, commits).
• Evaluate trial developers near the end of the trial period. Look at all of their work, and evaluate productivity and quality. Write a little review. Say whether you want to continue working with them.

I realize that some scrum masters will say that this is too much micro-management, that we should set weekly goals and let the the team work out its own schedule.  I love you guys, I really love you.  We should get together for a big, warm, group hug.  But, we should do it AFTER we use these tactics to build a highly productive team that feels great because they are doing kickass coding.

 

We improved the wiki usability in our May release.  Now we have an updated tutorial video that matches the new layout:

• We moved the page menu sidebar to the left side of the page, where it cannot be overwritten by stubborn content panels.
• We added tabs above the page Edit, View, Page History and Comments.
• We added small Print and Delete icons on the top right side of the page.
• We added a popup that will remind you to save your edits if you try to leave the page while editing.

 Watch the video for more!

//

Recently, we decided to look at the numbers for Assembla's most used tools. We selected counts data from the last seven days. We counted and or edit activity - commits, new comments, new files or wiki pages, etc., rather than views. 

Here is a summary of the results. 

 

 

 

Repository commits are the most common action. That makes sense, as our free repository offers have attracted large numbers of users.  Tickets, however, is a close second.

These counts are relatively close to our own usage of the tools as insiders.  I have noticed that on Assembla teams, there are about twice as many ticket add/comment events as code commits, and there is a higher proportion of Standup Reports.

//

It's fast, it's fun.  It powers your planning.  It tames your tickets.  It's the upgraded Agile Planner, our AJAX interface for adding tickets, building stories with tasks, and scheduling them into milestones, iterations, or releases.  For more details, please watch the video, or just select the “Agile Planner” link in the Tickets tool menu, and try it.

During the last year, many users have told me that they use the agile planner every week with their team.  So what is NEW in the Agile Planner this month? 

* It’s fast.  Drag and drop is smooth.  All tickets are loaded into local memory for instant access.  New layouts for “Milestone | Detail” and “Story | Detail” remove EVERY CLICK between mousover and seeing the detail edit form.

* Open tasks and subtasks to unlimited depth, in the Story/Feature column.  This “hierarchical ticket view” was one of our most requested features, with over 300 votes.

* Enter a list of tasks with the same attributes, using a new pop-up UI.

* In-place editing of estimates.  Just click on the number and edit.  The estimates add up correctly for complete features or milestones.

Incremental development is important

The Agile planner will help you with roadmapping, which I described in my article "Save the best for first".  It's a simple way to get what you want, fast, using incremental development.  We write down everything we want to do, and then we sort it by priority, and we try to find the minimum set of high-priority stuff that will get us a great release as soon as possible. 

A whole industry has grown up around incremental development, represented by Agile, minimum releasable product, lean startups, and even behemoths like Linux, which started as a student project. 

Sometimes, a planning view can be one of the biggest obstacles to this process.  If you write a view of your project that shows a feature listed under a milestone or release, and subtasks for that feature, it starts to force you into thinking that you need to finish everything before you can release.  You start to forget that you are in charge, and that you can release a simple version before you release the complete version.  In the Agile Planner, we separate the your grand plan in the Story/Feature view, from the schedule in the Milestones view.

How can you use the Agile Planner?

Use it with a client or business owner to launch a project.  It’s fun to see a plan take shape, which builds the relationship.  If you run a good roadmapping session, you get a big head start on the implementation, which is the biggest revenue earner. 

Use it with your team to plan iterations.  Many Assembla users sit down as a group with the agile planner each week or each month.  I have seen distributed teams do this with screen sharing tools.

Distribute planning.  I like to create a top-level story, and then ask the developer to fill in more detailed tasks.  It makes the developer feel more confident, and it makes the work more visible.

Many of our users like to sort their tasks into a very specific order.  Agile Planner gives you that control.

 

Here's a quick video of the Agile Planner, so you can see it in action.

The folks at AlertGrid posted an article with instructions for configuring Assembla to send SMS messages to your phone whenver something important happens. They asked "Can Assembla send me SMS message when new milestone is created?" Yes, it can.

The key ingredients are

• the Assembla Webhooks tool, which will send events from the activity stream to other applications.  You select the type of events that you want to send (for example, code commits, ticket comments, or new/edited milestones).  Then, you configure the URL to get or post the information.
• The AlertGrid service.  AlertGrid will not only send you an SMS, but it will compare the incoming messages to workflow rules, and send the correct message to the correct people.  So, this adds an extra layer of intelligence to the notification process that you can use to filter out noise and find the most important events.

Chat is back.  Just add a Chat tool, and click on the tab to drop into the chat room.  The new chat tab will be useful because:

Everyone on your team can use it.  It has the correct permissions for each team member, it requires no client software, and it is usable with any modern browser.  It gets messages with HTTP "long polling", so it reaches through firewalls, even proxy firewalls.  This is an important upgrade from our previous chat implementation, and it is especially important for workplaces where Skype is banned for it's bandwidth grabbing, firewall tunneling tricks.

Searchable history.  So, for example, your new team members can go back and find that reference URL that you posted last month.

Convenient linking.  It links to the user profile of the people in the chat room. You can link to ticket 99 with #99. You can upload files and get links and thumbnails.

It shows team activity in one river of information.  You can optionally edit the settings to show team activity - like commits, messages, new and edited tickets - in the chat message stream.

This is the first big win for our bounty program.  We thank D3velopers, an outsourcing company based in Pakistan, for implementing this feature.  They had some previous experience with COMET chat.  They were willing to do research on our preferred server (Nginx).  They were flexible in improving the feature, and delivered on time.  I hope that we can do more of these bounty projects.  Note the "Powered by D3velopers" logo on the top of the "Who's Chatting" column.  If you take responsibility for a tool through the bounty program, you get paid, and you get the logo and link.

Our previous chat implementation had a poor communication protocol that prevented it from working through firewalls.  We let it linger as a quality problem because there are many alternative chats, such as the popular Skype conferencing.  However, we received more and more questions about chat over time, and I am happy now that we have this solid new implementation.

Technology Credits As usual, we rely on great open source software provided by others.  The technology stack includes the Nginx HTTP Push Module.  We use Nginx in our proxy servers, and we found it to be fast and reliable. The Push Module is a "beta" feature, but it has served us well so far.    We use Xapian text indexing and search, and of course, Ruby on Rails, MySQL, and the whole Linux stack. The D3velopers team used our tool development kit to generate a new tool, and wrote javascript to finish the client side implementation.  We learned  something about playing sound - the little chirp that the browser makes when you get a chat message.  Browsers got quite confused when we asked them to play a sound, and they stopped taking data entry, went to load quicktime, and did other bad things.  Fortunately, the author of Soundmanager2 figured out how to use flash, with a fallback to HTML5 sound features, to play sound reliably.

//

When we started telling people about our new Standup/Scrum report offer, we expected our main problem to be that this incredibly useful tool is low-tech (basically, one form), and boring.  Instead, we got a some pushback that actually makes this discussion pretty interesting. 

Our friend, Ian Ippolito - the founder of vWorker, started by saying that he didn't see why it was useful.  

Derick Bailey wrote: "I think the product misses the point of the daily standup and could facilitate anti-collaborative measures in a team. Instead of having people talk to each other and gaining value through communication, understanding what other team members are working on and hopefully offering insight into the issues and directions that those people are taking, your product reduces the daily standup to a management task that serves only managers, not the team doing the work. Online collaboration with distributed, global teams is a difficult problem to solve...Understanding the big picture requires communication not just one-way statements...".  Here's a link to Derick's blog.

Tobias Mayer wrote: " actually, it sounds like a tool for micromanagement. In Scrum there is no 'reporting'. Team members meet to align with each other, not to report to their manager." Here's a link to Tobias' blog.

I learned a few things.

First, a tool like this must be useful for team members, not just management reporting.  I believe that engaged management is very helpful, but ideally, teams don't need or want much top-down intervention.  We have always tried to make Assembla first and foremost a place where team members can communicate with each other and get something useful in their daily work - in contrast to my last project, PowerSteering, which quickly became a rather intrusive management reporting system.  From this point of view, we see Standup as having two advantages.  First of call, you can see what team members are doing without bugging them.  Second, you don't spend much time at it.  Every minute saved from chat and calls is a minute that you can think more clearly about your own work.  And, finally, there is the top-down benefit of being able to easily raise a flag about what you need.

Second, the online Standup report is most useful if you have a team of five or more people.  A lot of the people that we talked to work with smaller teams, and they get good communication from email, chat, and other things that they do together.  On the other hand, the single biggest problem in software is working with bigger teams.  Bigger teams are always much less efficient, a syndrome that was analyzed almost forty years ago in The Mythical Man Month, and proven out by numerous benchmarking studies and our own mutual head-banging personal experience.  Given these problems, it's incredibly valuable to find methods that actually work better with bigger teams.  With the Standup report, I find that we are able to work effectively in teams of  up to 15 or 20, with the same type of teamwork that goes around in a four person team.

Third, that it is important to use all of the other communication tools that we recommend - an online ticket/task list, a daily chat, a shared build with daily, hourly, or continuous integration, and a shared view of the team activity stream.

We did hear from a number of users that like the Standup/Scrum report.  Here are some of their comments.

"Assembla's StandUp/Scrum tool helps us coordinate the activities of team members on three continents. A regular, light-weight report of tasks and problems makes a huge difference to our forward progress, and Assembla's tool fits the bill perfectly."
-- Daniel Hardman, Senior Architect - Perfect Search Corporation

"We use Assembla's standup tools extensively to coordinate our development teams in the UK, Europe and India. It's really useful when face to face standups aren't possible due to working time differences. Using this means we are all aware of what each person is doing and most importantly when they need help.It definitely helps to bring the teams together."
-- Gareth Gower, Applied Language Solutions

"At MeYou Health, we use the StandUp/Scrum reporting tool to allow the team to easily communicate to each other their progress on tasks, their upcoming priorities, and any blockers that others can help with. We usually do daily standups in addition to using the tool, but we find that the tool is nice because it helps us organize our thoughts before our standup and allows us to keep a running history of our high-priority tasks."
-- Chad Dressler, Senior Web Architect - MeYou Health

 

"IconApps uses the StandUp / Scrum reporting tool to allow both the management team and the development to keep track of our sprint progress, upcoming plans and overall team activity. We use it to collect team activity in one centralized place, so it's also like a history log. We found that asking everyone to fill out the "What I will do today/this week" section, forces everyone to really know what need to complete before they actually start the work."
-- Liana Gevorgyan, QA Manager - IconApps

"As a virtual company with employees across the United States, having a single place for everyone to share information is essential. The StandUp feature in Assembla is an integral tool in our semiweekly staff meetings as it allows us to share information about current projects, and note any needs we may have. Since using the StandUp feature, our meetings move faster and are better organized."
-- RedWeek.com

"I am a professor teaching software engineering project courses. We are using Assembla to give the students a realistic set of tools to work with in their team projects. We use the StandUp report tool for student reporting on a weekly basis. It pushes them to have something to report and allows a quick overview on how they are doing as well as giving them a clear way to ask for help. I like the way the tool rolls up the reports and highlights the "blockers" if present."
-- University Professor

So, is a written standup report the best way to manage a distributed team or is it anti-collaborative?  Please leave us a comment below and let us know which side of the fence that you fall on.

This month we'd like to introduce you to a development tool for a programming language you may not have had the chance to play with yet, Scala.

Our featured project this month is the Scala IDE for Eclipse, an Open Source Plug-In that adds Scala Programming language support with Java integration to Eclipse, a powerful and extensible Integrated Development Environment most commonly used by Java Developers. (you may have heard of it once or twice) ;-)

Scala is a language for the Java Virtual Machine, that allows developers greater productivity by mixing object-oriented and functional programming language features with a more concise syntax, typical code sizes being two to three times smaller than an equivalent Java app.

Recently, we had the opportunity to catch up with Miles Sabin, from the Scala IDE project, to discuss the project, Scala, and Assembla.

When we asked him to describe the project and its impact on developers, he pointed out that of the top three Java IDE's, Eclipse was the most popular and widely-used. He and his fellow developers at the Scala IDE project believe that if Scala were fully supported using Eclipse that many Java developers would switch to Scala.

Because Scala interoperates seemlessly with Java, it can freely be mixed in with Java code. This allows programmers to take full advantage of Java's tried and tested libraries and tools while using Scala's more concise syntax to get things done faster. By building a tool that seamlessly integrates into the IDE that a majority of Java Developers use in their daily work, Eclipse-based projects can quickly and easily begin to refactor, and add code using the more lean Scala language without a great deal of extra effort.

Scala is currently getting about 100,000 downloads per month and growing, and the Scala IDE for Eclipse already has thousands of users, lively user and developer mailing lists and a growing number of active contributors.

When asked how the Scala IDE Project came to be hosted at Assembla, Miles related that "Most of the active contributors were DVCS fans and in particular GIT fans.  When they started looking for a GIT home, GITHub was the obvious choice, but was rejected primarily because of their weak ticketing system." (If interested you can learn more about the advantages of Assembla Git Hosting and its integration with Assembla Tickets in the features section of our main website, here)

Miles also told us that the fact that Scala-based, Lift Web Framework had already chosen Assembla to host their issue tracking and and the related Stambecco Project was wholly hosted at Assembla were contributing factors.

In addition to our Integrated Ticketing system, Miles noted that -after the fact- two other Assembla features have proven to be very important to the team as well: our Wiki Tool and our Portfolio Tool.

Miles and his teammates use our Wiki tool to manage developer and end-user documentation, frequently asked questions, and release notes.

The Portfolio tool allows the Scala IDE project team to manage multiple projects from a single space, and the ability to create templates so that you can easily create new workspaces pre-populated with code, wiki pages, tickets, etc. This is great for both complex Open-Source projects and client-driven consultancies, design & development shops.

Miles also had a few pointers for those of you out there already managing open-source projects, or who are thinking about starting a project:

• Involve as many people as possible
• Have great code review processes and tools to ensure high code-quality
• Have all contributors and especially active contributors explicitly agree to the license under which their work will be governed so that there are no IP issues later

Scala IDE for Eclipse is a very promising project, and if you would like to download and play with the plug-in, be sure to visit their website for details on installing the plug-in for Eclipse. If you are interested in learning more about the Scala language, visit: http://www.scala-lang.org. And of course check out the Scala IDE Assembla Workspace if you would like to check out the developer or user documentation or contribute to the project.

I work with a lot of distributed teams here at Assembla, and I can't work without our online "Standup" report. This is a simple, low-tech form where users go every day to enter "What I did" "What I will do" and "Obstacles and needs". I can quickly browse through it and see who needs help and who is working on important tasks.

It's so useful, and so simple, that we think that EVERY distributed team should use it. If you work in a distributed agile team, you need it. If you work in a distributed development team, you need it, even if you are using competing ticketing and collaboration systems. If you are working on a corporate or government or NGO initiative from multiple offices, you probably need it. If you are organizing an election campaign, you probably need it. In order to make it possible for all of these deserving teams to use Standup, we are now offering Standup as a free package.

If you have been using this tool, you probably noticed that we changed the name of the tab last month from "Scrum" to the more generic "StandUp". Scrum teams do these reports every day in a meeting. That is one of the reasons that scrum teams like to be co-located. However, with Assembla's online Standup report, the team can get it done even faster by filling out an online form. It's simple, fast, and now free.

Why do a standup report?

• It saves time for the person doing the reporting. The form takes only a minute to fill out, and it saves time in email, chat, or meetings.

• It saves time for the manager, who can quickly browse and see what people are working on.

• It gets stuff finished faster by focusing people on the most important tasks. After you read through the reports, you will see if people are working on things that are important, and you can ask them to work on higher priority tasks.

• It gets problems resolved quickly, by flashing a little red "needs" sign from the people that have obstacles

• It increases productivity. Studies show that the act of writing down a goal makes the writer more likely to achieve it.

This report format comes from a traditional "stand up" meeting in which everyone stands until the meeting is over. Standing is a little bit uncomfortable, so it encourages people to finish the meeting quickly. It's expensive to have a big group in the room if you are paying everyone, and they have other things to do, so you want to go finish. In the bubble ‘90s I ran an e-business development company, and we did a standup meeting every Monday. We used the did/will do/obstacles format with everyone standing, and this did indeed help us get through the meeting quickly. So, it's useful for coordinating any type of group, and not just a scrum team.

When we write the online report, we are sitting comfortably on our butts. If you're like me, you probably have your feet up on the desk with a keyboard in your lap and a nice cup of hot tea. It doesn't matter. This report is so simple that you will have a hard time spending more than 60 seconds on it.

Three steps to a productive team

1. Invite team members
2. As soon as they start work, in whatever time zone they work in, ask them to click the button in the upper right that says "Add/Enter your report". They fill out the simple online form. If they have an obstacle, they write about it there.
   
3. At a glance, see what everyone is doing and eliminate roadblocks before they slow you down.

Optionally, use Assembla chat, Skype chat, or other conferencing to answer questions and get clarification.

ADDED BONUS: In tomorrow's release we upgrade the Standup tool to include "I am away" reports. If you are going to be away, post the "I am away" report in advance and it will be on the calendar to answer any questions from your colleagues.

The form....

The report ...

We plan to release a new version of Assembla.com tomorrow, Tuesday June 15th. This release will include a new chat tool, improvements to the agile planner and infrastructure enhancements that will make Assembla faster and more reliable. We will try to complete the release as quickly as possible, but Assembla.com may be down for up to 1 hour starting at 8:00 UTC ( When is 8:00 UTC? See http://bit.ly/7JSz ) .

I just got back from Seattle, where I was very surprised to find FOUR Starbucks coffeeshops on one (four sided) block. There was also a non-chain bakery and coffeeshop with a line of people waiting for coffee and muffins. People in Seattle must buy a lot of coffee in coffeeshops, and there are a lot of coffeshops that spring up to satisfy that addiction.

Which came first, the chicken or the egg? For whatever reason, Seattle coffee suppliers and buyers started a cycle of competition and appreciation that turned corner coffeeshops into global marketing giants. I used to wonder how Starbucks and Seattle's Best coffeshops could come from 3000 miles away and drive out the local competition here in Boston. Now I realize that there is a reason.

We see the same effect in Web businesses. Fred Wilson posted a chart here of the top 30 Internet sites by traffic here, and noted "75% of these properties are based in the US ... Contrast that with the fact that only 17% of the Internet audience (213mm) is in the US and you will see that Internet is one of the primary export industries in the US."

As you know, I am a supporter of global development teams. Business models may be local, but production is not. "Seattle's Best" coffee doesn't come from Seattle. It comes from Nicaragua. And, Belgian chocolate wasn't grown in Belgium. America imports most the equipment and a lot of the talent that goes into building those top Internet services.

The lesson that I take away is that we can pull our materials and talent from around the world, but we should look for a small number of up-close and personal customers and competitors that will make our business stronger.

// It's not surprising that we count so many software consulting, web design and general project shops amongst our customer base. After all, we originally built Assembla.com as an internal tool suite that our sister company, Assembla Consulting, could use to build and deliver software for other companies. What does amaze us, though, is how many different ways our customers use Assembla to involve their clients by selectively giving them access to certain tools or the entirety of a workspace that they are using to coordinate and accelerate that client's project.

We thought that you might find some of these tactics of client interaction interesting, so we have grouped them together into generic use cases. Please leave us comments about which use case(s) you find most effective or if you have developed a different way of using Assembla to work with your clients.

Complete Transparency with a Handoff at the End

Before we started reaching out and conducting lots of interviews, we assumed that our customers used Assembla.com to interact with clients the same way we do. We basically invite interested folks on the client side, usually the "business-side" project manager and occasionally others, to view the entirety of the project. Then, at the end of the project, we hand off the workspace to the client.

Many clients will sign up for our lowest level plan and use Assmebla.com to archive the workspace should they ever decide to do version 2.0 of the project or need to go back a year later and understand why something was built the way that it was. A persistent (archived) workspace is a fantastic way for clients to safeguard their intellectual property - and not just their code, but all of the thought that went into conceiving, architecting, building and testing a piece of software or some other complex project.

However, we have learned from our customers that there are lots of good reasons to manage client interaction with a workspace differently. For example, you may not want clients having access to a code repository before they have paid their bill or you might be afraid that if clients have access to the Tickets Tool that your team will constantly have to self-censor what they say in ticket comments so as not to offend the client.

Parallel Workspaces

Some of our customers use a slight variation of the completely transparent approach and set up two workspaces for each project - one that is inward-facing and is only used by the project team and another that is outward-facing and the clients have access to. It's a great way to control what the client sees while still allowing them to observe the incremental progress being made on a project and feel like they are involved. Often times, the outward-facing workspace will use the ticket tool as a way for clients to test the project and leave feedback along the way.  The obvious downside of this approach is that you have to synchronize the parts of the workspaces that you want the client to see frequently. 

Using the Customer Service Tool for Client Testing

Similarly, if customers don't want to set up an entirely separate workspace, they may opt to use the Customer Service tool as means by which the end client can test the project along the way and report problems without allowing the client to see all of the tickets. This way clients can be continuously involved, but without the possibility of stumbling across something that may be embarrassing to the project team.

Limiting Access to One Tool

It is also possible to give the client very limited access to a workspace on Assembla.com. Here's a great example.  Many of our customers will use a wiki as a set of working documents that house the project scope and other content that help to define the project. Initially, both our customers and their clients will go back and forth editing the wiki and recording their comments. When our customers and the clients agree on the scope, that wiki becomes the de facto Statement of Work for the project.  However, a workspace can be configured so that this is the only tool that a client that can see. 

This can be done by defining the permissions of each tool for a workspace for the team member level of "Watcher" (visit the Admin tab and click the "more" link in the Security section ) and then inviting the client as a Watcher. 

 

Juan Enriquez stepped up to remind software developers that the most significant future work in coding is likely to be done with genomes.  He works in the emerging industry of synthetic biology.  He's suggesting applications like "improving the climate on Mars, designing human organs that fend off disease or cloning cattle that produce powerful vaccines in lieu of dairy products."

This is indeed a trend.  Last year I went to visit Tom Knight, one of the inventors of computer science, at his office in the MIT's Stata Center.  I was surprised to find him surrouned by petri dishes.  Always the pioneer, he has moved his attention from digital code to genomic code.

Coders can bring their skills to synthetic biology.  We can turn this around.  Biology can also bring it's magic to coding. 

I propose the basic idea that innovation has multiple forms - biological evolution, industrial/economic innovation, and human creativity - but a single underlying set of mechanisms.  The mechanisms are based on the simple variation and selection process that we learn about when we study darwinian evolution.  It's called "exploration and optimization" in engineering circles. 

However, the machinery is actually a lot more complicated than that, which is why we still don't understand it fully.  We can run evolution on computer programs, "genetic programming," but the results aren't even close to what we get with real evolution, yet.  That's why it's such a good area for further study.  Code is the product of innovation in its pure form, and if we learn how to make one type of code, we can make other types of code.

Evolution takes a long time to deliver results.  It can go 1.8 billion years just working on bacteria.  However, it appears to be "punctuated equilibrium".  Most of the action is packed into short bursts.  We see the same pattern when we run genetic programming.  By creating an "arms race" scenario and taking away the tendency to equilibrium, we can prod evolution to run much faster.  This creates an artificial process that is related to normal evolution in the same way that a Mach 3 jet airplane is related to a bird.

This is a long term answer to how we are going to generate bigger projects and bigger wins than Web services.  Once we understand how innovation and evolution work, we can apply those ideas to computer code, to synthetic biology, and to hardware.  How, as a species, we are going to deal with the effects of this takes us into the realm of science fiction, but at least the current innovation deficit will be out of the way.

We plan to release a new version of Assembla.com tomorrow, Tuesday June 1st.  This release will include new features and bug fixes, as well as an upgrade to the database software for improved speed and reliability. The database upgrade will require a small amount of downtime.  We will try to complete the release as quickly as possible, but may be down for up to 1 hour starting at 8:00 UTC (when is 8:00 UTC?).

tweetmeme_url = 'http://blog.assembla.com/assemblablog/tabid/12618/bid/12763/Fat-or-Lean-startup-Which-is-better-for-you.aspx'; tweetmeme_service = 'bit.ly'; tweetmeme_source = 'assembla';

The ongoing debate between Fred Wilson (likes lean, "capital efficient" startups) and Ben Horowitz (thinks you should raise big money to go after big opportunities) was nicely summarized on GigaOm here.  I think it is relevant for many of our readers, who run software-based businesses.

The case for lean / capital-efficient

"Lean" is much better for founders.  It's a huge amount of work to build a lean or bootstrapped company - the opposite of a "lifestyle" operation.  But, as Wilson notes, you end up with a bigger stake and a much higher probability of making money.

In an investor-funded businesses, the original founder usually does not make much money.  You will often see statistics from VC firms showing that they make money on 10% to 50% of their deals, depending on how big the gain needs to be to be "making money".  I have never seen a similar statistic that showed the percentage of deals that make money for the original founders.  That statistic is much smaller.  They wouldn't want you to see it.  Big wins are well under 10%. 

How does this happen?  If you have a company that proceeds from its first investment to an exit without ever having a down round, the founder will make money.  The fabulously wealthy silicon valley founders that you hear about had this type of good fortune.  However, the average VC-funded startup now takes about 8 years to reach an exit.  In that much time, even a strong company will have some random walks down.  That wipes out the founders.  VC term sheets are designed to take advantage of this type of ratchet, and VC's depend on it.

On the other hand, most bootstrapped businesses eventually find a way to make money for their founders, and it seems like the probability of founders making money falls when they need more investment.

So, if you want to make money, go lean.  If you are founder or early shareholder, that is all you need to know.  You can stop reading now.  Read on only if you are curious about the other side of the argument.

The case for FAT

You can innovate without spending money, but you will be innovating within a very limited range.  Does the world need another little Web service?  There are a lot of things that are just expensive.  These are the big, society changing innovations. Without significant investment, you won't be building a new kind of semiconductor, or replacing oil with algae, or sending a man to the moon.  If you spend money, you can do more, and you can be more innovative.

The changing debate

It's a new phenomenon to see Fred Wilson and other VC's stand up for lean and capital-efficient.  Investors sell money.  Their job is to get the best price for money by finding investments that need a lot of money and are desperate for it.  Lean goes against their interests.  And, in fact, I have heard VC's like Robert Metcalf dismiss companies with "it's capital efficient" as words of utter contempt.  I searched on google for "Capital efficient" one year ago, and the top hits were all investors who agree with Horowitz, that capital efficient = trivial.  Times change. Now, you find articles with titles like "The gift of capital efficiency.".  I think this change is driven by statistics.  As Wilson notes, capital efficient companies are making more money and better returns.

So, which way am I voting?  I am a founder, and I want to make money for my own family.  I run one of the most capital efficient startups you are likely to find anywhere.  We have basically no costs beyond contract labor.  I work alone at a $15 desk.  In my last startup I raised venture capital, had a big office and a sales force and a receptionist.  Although the company was successful, I got a cramdown that rendered my stake worthless.  That company was less profitable, less able to support my family, and interestingly, less able to fund new directions, because anything it did was more expensive.

However, I think that the trend to efficiency, while good for me because I can deliver efficiency, does indicate a sickness and lack of innovation in our economy.  If most of the money is being made by people who work within the narrow bounds of efficient operations, it means that big innovations aren't paying off.  That's why VC returns are so crappy.  That's why our economy isn't growing.  That's why we are looking to efficiency.  There aren't enough big innovations that are succeeding.  Have we run out of opportunities?

This isn't just a discussion for small companies and startups.  This is a huge issue in the global economy that affects billions of people.  Those people are saving for retirement.  They need a much higher return on investment.  They are driving interest rates to zero.  They are bidding up stocks until they can't go up any further.  They are funding huge government deficits.  They are desperate for better returns, which they are not finding.

It will seem to a startup founder that capital is hard to get, but the reality is the opposite.  Startups can't get funded because, statistically, they don't make much money.  They don't make much money because the big innovations are scarce at the moment.  If you can fix that problem, there are trillions of dollars out there begging to get in to your deal.