inc(Dev.UltraStar_Deluxe)

TestLodge recently announced their latest feature that allows Assembla users to link their accounts to TestLodge's test case management tools. This integration makes many essential software testing features available to Assembla users without having to manually enter data for their tests and bug tickets multiple times. TestLodge created this custom integration using Assembla's REST API.

Below are the updated overview videos for Assembla's most used collaboration tools - Wiki, Files, and Messages. If you are not taking advantage of any of these tools, you can add them to your project workspace in seconds from the Admin tab of of you space.

  The Wiki tool is ideal for organizing pages for instructions, ideas, specifications, documentation, and anything else you want. Add new pages in seconds, and customize the navigation to fit your needs. Let other team members contribute; if you don't like their additions, just roll back to any previous version.      The Files tool provides a central and secure place or organize and manage project files and Google docs. You can add files and Google docs directly to the Files tool or you can upload them to tickets, messages, wiki pages, etc. - either way, all your project files will be organized and searchable from the Files tool.       The Message tool lets team members communicate with each other while maintaining a centralized record of all conversations. Messages are a great way to facilitate communication and collaboration without messy email threads that get overlooked, clutter email inboxes, or don't reach everyone.

These videos and others can be found on Assembla's YouTube channel. 

1) Development

2) Release Management

3) Product Management

4) Recruiting

5) Managing People

Some estimates show that up to 80% of software development is done in some sort of distributed environment. Managing a distributed team can be challenging but rewarding if you find what processes work for you and your team.

Titas Norkūnas, a Technical Lead at Assembla, spoke at Agile 2011 in Norway on “Distributed Agile: 5 Dos and 5 Don’ts for Global Team Management.” Titas works with a development team that spans over 15 countries. Below is the video from Titas's presentation and the annotated summary.

Watch the Video: 

Titas provided some notes from his open space sessions that show how important this material is.

• Mostly Project Managers attended these [sessions on distributed teams].
• Project Managers did not like my presentation. I think it is because I argued skipping Project Managers, skipping estimates, not doing video/phone conversations. I got a much better response from technical people - architects, consultants, even a phd researcher.
• Every Project Manager insists to use video conferencing software.
• All people in an open space, except for me and one other guy, thought that their distributed teams were not successful (about 20 people in a "show of hands").

There is clearly a correlation between old-style project management, complete with video conference calls, and mis-handling distributed teams. Many project managers don’t notice this themselves.

Titas's final conclusion? - “A lot of people want to outsource or use distributed teams, but they don't know how.“

Summary

5 Dos:

1. Share a Continuous or Daily Build:

Have a continuous or daily build where everybody on the team shares their code instead of working from a hodgepodge of commits and branches. This provides a more up-to-date codebase for team members to checkout and a stable running version of the software.

A common obstacle of implementing this is when team members do not commit often. Below are some ways to help prevent this problem:

• Simply ask team members to commit more often and define some guidelines.
• Break complex tasks into smaller, more manageable task that take less time to develop.
• Provide rapid feedback when code changes are available to reduce downtime.

2. Embrace Decision-Making:

Communication will be slower and more difficult in a distributed team, especially when spread across multiple distant time zones. Give developers leeway to make some decisions on their own. This can translate into getting something decent today instead of being delayed. If you don’t get exactly what you want, you can always tweak it, but at least you made progress without downtime.

Writing really good specifications reduces the need to make independent decisions, but writing really good specifications takes time and is easier said than done, so don’t discourage decision-making during certain circumstances.

3. Keep Everything Organized in Tickets:

A lot of conversations will happen via email or through IM services like Skype or Google Chat. These conversations typically result in a task or tasks that should be documented before they are forgotten. It is important to use a web-based task/issue tracker where team member can view, create, and edit tickets.

Use milestones to plan sprints and iterations. Did you conversation lead to a cool improvement that is not a top priority? Put it into the backlog so you can fit it into a later release.

4. Communicate Asynchronously:

Skip the unnecessary teleconferencing and video chats by having developers fill out daily stand up reports, which is a simple form that addresses what I have done, what I will do, and any needs or roadblocks. Stand up repots allow Technical Leads to quickly check to see if the team is on the same page, are their priorities ok, and if there is anything that needs to be addressed.

5. Subscribe to Team Activity:

Just like you check Facebook to see what your friends are up to, you should regularly check your project’s stream to see project activity. Keep an eye out for irregularities such as unusually low activity or lack of involvement from certain team members. 

5 Don’ts:

1. Skip Interviews (and do Trials):

Look for qualified applicants with relevant experience and give them trial task to complete during a paid trial period. At Assembla, we do two week paid trials where we can evaluate a set of candidates based on their performance to see if we are getting the value for the money. 

2. Skip Non-Technical Project Managers

Non-technical Project Managers can slow down development progress. Train Technical Leads which are Project Managers that are also developers. Check out our blog pot on “Tech Leads will Rule the World” to learn more about Technical Leads.

3. Skip Estimates

This doesn’t apply to everyone but if you have a good roadmap and prioritize tasks, estimates will just slow you down. In this case, estimates will not change the order in which you do things so why spend the time working on estimate when you can just work from high priority tasks in queue.

4. Skip Traveling

There is no need for face-to-face communication so why spend the money and time to travel? Traveling can be good for team building but not for productivity.

5. Don’t Have Rules

Given certain circumstances, rules occasionally need to broken so instead, provides guidelines that allow team members to make certain decisions based on the outcome, not the rule.

We recently released two new features for Portfolio users:  Standup, and Share.

"Standup" in the portfolio will show you the most recent Standup reports from all spaces.  You can click on the “Activity report” link to see more details about the user.   This has been a lifesaver for me as our business gets more complicated.  Before I talk to someone, I can check this report to find out what he or she is working on, and I have the opportunity to sound relatively informed and attentive.  You can also use it to spot "needs" and remove obstacles more quickly.

With “Share” permissions, you do not need to enter all of your team members multiple times.   Just “Share” with an existing team.  This is convenient if you have a project / subproject structure.  You can add team members to your top-level project, and then when you set up subprojects, “Share” with the entire team.  To use it, go to the Team tab, and (if you are in a portfolio) select the “Share” subtab.

If you have only one space, you see a new layout on your user/start page.  This new layout simplifies navigation by moving links and information onto the start page.  About half of all Assembla users are team members who are invited to one space.  When you join a second space, your start page will go back to the list of projects, and you will need to click on a space name to see the tools.

Here is a screenshot that shows a typical project configuration:

On top, you have direct links to the tools in the space.  Underneath, you will see “modules” that depend on the tools installed in your workspace.

Static Modules:

Stream: From the Stream module, you can view project activity, in real-time, so you always know what is being worked on.

Project Owners: Shows who “owns” a project and also provides one-click access to the Team tab to view all team members. Owners of a project also have on-click access to add new team members from the dashboard.

Tool Modules (vary based on the tools installed in your space):

My Followed Tickets: A list of tickets that are assigned to you, and other tickets that you follow. An orange star next to a ticket represents a ticket that is assigned to you and a yellow star next to a ticket represents a ticket you follow but not assigned to you.  Follow and unfollow tickets by clicking the star.

StandUp:  If Standup is your default landing page (Free Standup configuration) you can update/edit your daily StandUp report from your dashboard. Click “StandUp reports” link to view the StandUp tab of your space to read through other team members reports.

Commits: If you have a code repository installed in your space, you can get an at-a-glance view of the number of commits for the current week and the previous week. Click on the “Browse code” link to go to the code browser of your repository.

Wiki: The Home page of your wiki is displayed on the dashboard to provide important information about the project such as relevant links, processes, and other documentation.  You can use a Wiki home page as an easy way to introduce new team members to a project.

Future:

If you participate in a second space, you will go back to the view with a list of spaces.  We are seeking advice on enhancements.  For example, if people like the one-space view, we can put panels under each space to show the dashboard. We will continue to refine the panels on the dashboard.

Assembla Subversion and Git users are now able to access both affected files AND tickets when comparing what has changed between revisions. This update makes it easier for release managers to know what tickets were affected in a revision or between a range of revisions.

The "What changed" feature shows files that were changed between two revisions.

In order to track affected tickets, you must reference tickets in commit comments. For example, “re #1231” in your commit comment shows that your commit is related to ticket number 1231. Or “test #1231” shows that your commit is in reference to ticket number 1231 and will also update the status to test.

Using "What Changed"

In your Subversion or Git repository, go to the Changesets sub tab, click the “What changed” button, and in the pop up, enter the two revisions you want to see changes between. The AJAX search will find what you are looking for as you begin to type. Click compare. 
 

Scroll to the bottom of the page and you will have two tabs – Affected Files and Affected Tickets. Click on the Affected Tickets tab and you can see the summary, milestone, assigned to, and status of all affected tickets between the two revisions. From this tab, you can also update or access these tickets.
 

Hello, Привет, Hola, Chào!

The Spanish and Russian translations are complete, and most of the tools have been translated into Vietnamese. 

To update your language preference, visit the Edit Profile page of Assembla. When you update your language preference in your user profile, it will remain the default language whenever you log in to Assembla. 

Because Assembla has users in more than 100 countries, we will continue to translate Assembla’s tools and landing pages into new languages.  We plan to add languages such as German, Chinese, Polish, and Portuguese.

• If you are interested in helping Assembla translate our tools into additional languages, please check out our current job opening for translators.
• If you find any issues with current language translations, please report them on our Language Translations Forum. 

How to update your language preference

Below is the video presentation from a previous webinar on "Managing Distributed Teams with Assembla." You can also watch the video on YouTube.  We built Assembla to manage distributed teams, and we work as a distributed team. Our experience might be helpful to the 79% of software projects that have team members in more than one place.

The presention covers how to:

• Set up and manage a cloud-based development environment
• Coordinate team activities across multiple time zones
• Apply Agile techniques to globally distributed teams
• Manage a global development organization

Today we are offering the first beta release of EasySVN for Windows, an automatic update and commit feature that will make Subversion as easy to use as file sharing tools like Dropbox.  Get it on the download page.

EasySVN enhances the things that we like about Subversion:  Its ease of use, the fact that it uses normal files and folders that are easy to understand, and the fact that it can handle big files, like the files that designers often share.  I think the designers on your team will appreciate it.

To use it, just select "automatic update and commit" from the right-click menu of a repository directory.  The EasySVN process will commit changes and new files in that directory, and update your local files with changes from anyone else using the repository.

How it started and where it is going

We started working on this project when I noticed that there are hundreds of thousands of designers and Web developers working on sites like oDesk that don’t use Subversion.  They should be using a sharing and versioning repository, but they aren’t.  They use simpler sharing media like emailed archives, ftp, and Dropbox. 

I emailed Stefan Kung, a leader on the TortoiseSVN project, to ask if he would help us.  He replied that the automatic update and commit mode is a feature he had been wanting to add for some time.  He referred us to Stefan Fuhrmann, also on the Tortoise team, and we started building a team around him with contribution from Christian Amarie and Oleksiy Suschuk.  So, the first release of EasySVN is a Windows version based on TortoiseSVN.

This first release of EasySVN isn’t as "easy" as it will be.  It requires that you install two pieces of software, TortoiseSVN and the EasySVN replicator.  Then you have to checkout a repository populate it, and share it.  In the final release, we will have a single installer, and you will just be able to select an existing directory and “Share with Assembla.”

We are also working on a linux port (command line), which can be a reference implementation for other linux client developers, and on a Macintosh client that will have some Finder integration.

Commitment to Subversion AND Git

Just because we are innovating with Subversion does not mean that we are moving away from our commitment to git.  We love git, and we use it in our own development process because of the incredible flexibility it gives us when we share, review, test, and deploy code.  We are working on enhancements that will upgrade the basic git merge request workflow to include review features seen in the Gerrit review system.  Eventually, these powerful workflows will also be available for Subversion, when we finish upgrading Subversion merge.

Some advantages over other file sharing

If you are a Subversion user, you can recommend EasySVN for the non-programmers on your team.  What if you aren’t a Subversion user?  There are some specific reasons and circumstances that you might want to use EasySvn instead of other types of file sharing.

• Subversion repositories are portable.  You can dump them and move them to in-house servers.
• Versioning and recovery features are excellent.
• It handles large files and repositories with atomic commits.
• When you use it with systems like Assembla, it has notifications and auditing and linking that makes it easy to use for team collaboration.
• It’s an open system.  There are many subversion clients and servers, and many ways to access subversion and use it for publication, notification, mobile access, etc.

This is the first beta release.  It will have some problems.  Thanks for your patience and your suggestions as we improve quality and ease of use.

The Wiki has an improved WYSIWYG editor.  It will be familiar to many of our users because it comes from the Google Closure editor that is used in gmail.

The layout is simpler. There are fewer controls and fewer options.  You don't need "Preview", and the submit buttons are easy to find on the top and bottom right.

The edit form sizes itself to contain the entire page.  It expands as your page gets bigger. When you scroll down to the bottom of a large page, the formatting bar follows you.

We see better results when cutting and  pasting from other editors.

We improved image upload, so you can quickly add pictures. Click on the little square image upload icon and you get the following options:

• Upload an image file.  It loads into the "Files" list and appears on your Wiki page.
• Select a previously uploaded image.  You can select from thumbnails of the last 20 images, or you can search by name.
• Size an image. Select small, medium, or large sizes to fit your page.

Here is the image uploader

 

Do you think we should use this editor on the Ticket description panel?

Assembla servers are now running the newly released Subversion 1.7, which is faster, looks better on your disk, and contains many other improvements.

You will still be able to use your Subversion 1.6 clients.  However, we recommend that you upgrade to a Subversion 1.7 clients, because many operations will be faster. Download free Subversion 1.7 clients here.

Why upgrade your client?

Server operations are faster in version 1.7.  HTTPv2 and libserf reduce the "chattiness" of subversion and allow for faster pulls and pushes to the repository over http and https.  The server is now tunable to allow for various caching mechanisms and data compression.

On your local working copy, the Subversion information is centralized and those annoying .svn files go away because only one ".svn" directory is created.  This centralized metadata also makes svn operations faster.  When you start the Subversion 1.7 client, it will ask you if it can convert your working copy to the new 1.7 format.

Hint:  Subversion 1.7 will upgrade your working copy, so if you use multiple clients, you should wait until you can upgrade all of them.  For example, if you use subclipse inside the Eclipse IDE, and TortoiseSVN outside of Eclipse, it's a good idea to get the most recent subclipse  (which supports the 1.7 format) when you upgrade TortoiseSVN.

Hint: Subversion 1.7 clients cannot upgrade inconsistent 1.6 working copies.  Before upgrading to a 1.7 client, a 1.6 client must be used to run svn cleanup on all working copies that require cleanup.

The full Subversion 1.7 release notes are available on the Apache Subversion site. 

Subversion 1.7 clients are listed on the Assembla Subversion reference site.

About Assembla Subversion Hosting

Assembla provides the world's best subversion hosting in the cloud. Our secure, reliable, and feature-rich subversion hosting is free and scalable with optional paid plans that offer ticket, collaboration and management tools that integrate with your subversion repository. Learn more about Assembla Subversion.

Agile development practices were initially designed to work with smaller co-located teams, but these practices begin to break down when applied to large and/or distributed teams. With this said, open source projects have managed to be Agile with hundreds to thousands of contributors across multiple time zones.

So how can Agile learn from open source projects? On November 3, 2011, Andy Singleton, CEO of Assembla, spoke at the Agile New England event on ‘What Agile can Learn from Open Source.” Below is a video of Andy’s presentation as well as the slides. Enjoy. 

Watch the presentation:

View/download the slides:

View on Slideshare | Download

 Andy's notes:

About halfway through, I started talking about scaling projects, and I made some claims that caused active rebellion in the audience. That's awesome when you consider that this audience is composed of corporate agile people who specialize in calmly coming to consensus. I said that the Mythical Man Month is wrong (it turns out that at least one audience member studied with the author), and that it's a good idea to let people go around dependencies by duplicating work, because that way the worst delay is a 50% reduction in productivity, which is much better than most large projects, etc.  It's a fun subject that is worth more debate.

At the end, I present "Release Driven Development." This is my synthesis of the agile process that people actually end up with when they try out Scrum but know how open source projects work. It's a lot like Scrum, but with a twist. Instead of doing iteration planning at the beginning (this is hard, almost nobody does it well, doesn't scale), you do what open source projects do and assemble the release at the END, including or "accepting" components that are ready to meet your quality standards. This improves scalability, saves time, and gives more time for design and quality control. We're going to do a lot more with RDD.  Check out the last few slides in the slideshare deck above for a description.

Forrester Research is conducting a study on the adoption of Agile software development practices. This study will explore how organizations measure the value of software delivered. 

The survey is completely anonymous and should take no more than 15 minutes. Completing the survey entitles you to receive a copy of the research findings. We encourage you to participate and share your impressions of the current state of Agile development. 

       Complete Forrester's Agile Software Application Development Survey 2011

At a Google office the other day, I heard someone say “Tech Leads make all the decisions at Google.” They also make the decisions here at Assembla. If you do distributed software development, they should be making the decisions at your company

A Technical Lead or Tech Lead is a software engineer who also leads a team. The Tech Lead picks the important tasks, answers questions, solves problems, assembles a release, helps new team members – and does development.

We think that distributed teams require Tech Leads. These teams communicate with code and other deliverables. They need to work with a developer who can read the code.

Why don’t we use Project Managers or Scrum Masters? Non-technical project managers aren’t effective in a distributed team, because these teams communicate by exchanging code and other deliverables.  We can’t afford Scrum Masters who “coach” and “remove impediments” but don’t code and don’t lead. We need guys who write code, know what they are talking about, take responsibility, and take the lead.

It’s a tough job, and some say that engineers can’t do it. I’ve heard many times that “a good engineer is a bad manager.” I don’t believe it. There was a time when people said that engineers made bad entrepreneurs. Today, software engineers run the most successful technology companies, and the hottest startups.

There are many people doing Tech Lead jobs today. They are doing it as technical founders, directors of development, lead programmers, project leads, etc.

However, few people are trained for the Tech Lead role. We find that a lack of Tech Leads is the primary reason for not using distributed teams, not expanding teams, or not succeeding with distributed teams. 

We think that good developers can become good Tech Leads by practicing a small set of new skills.  We have been putting together a Tech Lead Checklist, a minimal list of tasks that will equip an engineer to lead a team. This will be joined with other materials, including a list of skills and exercises drawn from the experience of our own Tech Leads and other contributors.

Tech Leads have always been important for Assembla. We organized some Tech Lead training two months ago, and expanded our capacity with “feature teams” headed up by Tech Leads that can independently design and release complete features. Our Tech Lead candidates have been taking turns as “release captain,” and improving the release process, and helping with recruiting and hiring. I find that our Tech Lead candidates are a lot more fun to work with since we started this program.

The Tech Lead role is important for developers who are interested in career development. As Tech Leads, developers can do more, succeed in their careers, and proceed to world domination.  And other developers, who aren’t interested in management or the petty hassles of world domination, like the idea that they will have better, more technical management.

Tech Leads are also important for business managers. Last month, I went out to Silicon Valley, and I saw people actually leaning across the table in excitement when I told them about our Tech Lead training program. They are desperately short of programming and product management capacity. They got excited thinking about how Tech Lead training can help them break out with expandable, distributed teams.

Some engineers are already great at the Tech Lead job. However, we can have a lot more if we study the role and share good practices.

When that happens, we will have more distributed teams, since the lack of technical leads is the most common reason for not using distributed teams.  Those teams will go on to make the apps and software that control phones, cars, media empires, payment systems, voting machines, and power grids. So in a few years Tech Leads will not only make all the decisions, they will rule the world.

We will be posting a series of resources related to implementing and training effective Tech Leads. If you would like to receive email notifications as these resources become available, sign up to the Tech Lead email list.
 

I will go to the Agile New England monthly meeting tonight and make a presentation about "What Agile can learn from Open Source."  We will meet at the IBM office in Waltham, Massachusetts.

Learn more at agilenewengland.org

Here is the abstract.

Agile and Open Source methodologies grew up in different neighborhoods. Agile became popular for small, continuously managed commercial projects. Open Source projects grew into big, freewheeling “ecosystems” with hundreds of contributors. Both sides evolved powerful ideas for accelerating software development.

Today some Agile organizations have outgrown a number of conventional Agile practices. It’s time to see what Agile can learn from Open Source communities to scale up projects.

In this presentation, we’ll look at distributed teams, team roles, building teams, planning releases, managing releases, testing releases, and scaling to big projects. Everyone should get some new ideas inspired by the Open Source movement that they can use in their own projects.

I will also present an idea for a new and more streamlined agile process that includes these learnings.