After the much-anticipated release of Google Drive, there have been many articles about teams using it for project related collaboration.  With Assembla’s Google integrations, using Google Drive in combination with Assembla results in the ultimate collaboration powerhouse.  

The integration allows team members to link to their Google Drive files from tickets, wiki pages, messages, etc. without having to manually share files though Google’s web interface. No matter what type of Google Drive file, team members will always have instant access because Assembla "shares" the document when a team member clicks on it.

How does it work?:

From within multiple tools of your Assembla Project Workspace, you have the option of attaching a local file or attaching a Google Doc.  For example, you may want to attach a Google Doc to a task.

When you click on the upload a Google Doc option for the first time, you will be taken to a Google page to grant Assembla access to your files – it’s safe and secure.  Once you grant access, you will get a Google file picker pop-up that displays all the files on your Google Drive.

When a file is selected, our integration automatically grants instant access to anyone that is a part of your Assembla team so you don’t have to individually share anything.

Working with Google formats (.gdoc, .gsheet, etc.):

Google formatted documents and spreedsheets are ideal for content and requirements collaboration because of their ability to have multiple contributors working on the same web based file.

For example, the marketing team at Assembla is responsible for a lot of content creation and collaboration tasks. Every ticket/task has a Google Doc attached to it where the content comes alive from multiple contributors though drafts, edits, comments, etc. until it is satisfactory. Passing around and uploading new versions would double the time required to complete these tasks.

Working with other file types from your Google Drive:

Google Docs is nothing new but Google Drive adds many new capabilities. With desktop integration, you can now easily add any file to your Google Drive. When you work on the files locally, new versions are synced to the web-based drive.

Attaching these files via “Add a Google Doc” integration is different than just attaching the files via “Add a File” from your computer because they are accessed from Google’s version and not the version you attach. This is better because:

• When you attach a file from your Google Drive, you can still work on it locally without having to attach an updated version – the Assrmbla link is always the most recently synced version from your computer.

• These files are accessed directly from Google and not Assembla so you do not have to upload anything. Attach a 100 mb photoshop file or a 1 gb video file and it is instantly available without waiting on uploads.

Assembla’s Google integration is perfect for teams that are using or considering Google Drive but also require a complete suite of integrated collaboration and development tools like tickets, code repositories, deploy tools, wikis, messages, and more. 

We wrapped up our second annual development team meeting in Antalya, Turkey.  The setting was beautiful and company was excellent.  In spite of this fact, we managed to focus on breakout sessions where we worked out solutions for problems in development process, architecture, and usability.  This meeting proved that the people at Assembla are more important than the code.

We had attendees from Argentina, Canada, Chile, Czechia, France, India, Lithuania, Mexico, Moldova, Pakistan, Poland, Romania, Russia, and the United States.

Do I recommend this type of meeting to other teams?  It costs some work time, and I am seeing a trend where people wander around the world on the way back from the meeting.  For the next few weeks, Assembla will be brought to you from the cafes of Paris, Rome, and Katmandu.

However, the meeting this year was very successful.  It improved the job experience by giving us warm friendships.  I got a jolt of positive energy from the commitment and enthusiasm of the team members.  It also provided a forum to promote new functional leaders that we need as we continue grow.  It gave me a chance for one-on-one interviews with everyone to find out what they want to do in the next year.  And, the breakout sessions often reached a point where we were suddenly in agreement on process, technical, and design issues.

We got dramatic results from usability sessions where we saw victims, some of them team members, struggling to accomplish simple tasks.  This hammered home the point that Assembla needs to move to a world-class level of usability.  We also got a visit from Vladislav and Matej of Bioport, who made the Pocket Assembla mobile app, and provided a lot of creative energy.

Thanks to everyone.

We turned on Akamai CDN / ADN yesterday, after a long period of testing and adjustment.  We are seeing improvements in total page rendering times of about .6 seconds.  Improvements are bigger in China, Australia, and other countries that are far from our US servers.  Our main goal is to improve service for users in the BRIC countries.

The CDN speeds up page loading by caching static parts of every page on proxy servers that are close to users in dozens of countries.  The ADN service is supposed to speed up the network by sending data on optimized routes.

This is the most recent step in a series of performance improvement projects.  Last fall we installed a dedicated server architecture that moved our average server response time under 100ms.  In every major release we look at slow operations and improve their implementation.  In some places we put in AJAX operations to speed up initial page rendering.  Now we are working to reduce the number of javascript libraries (which was out of control) that each page needs to load and parse.

What's next?  Repository operations consume more bandwidth than Web operations, and those are not going through any acceleration network.  We are working on a "mini datacenter" architecture that will allow us to put read-only db and repository servers closer to users on other continents.

Scaling– Design your process so that new contributors can join.

Recruiting and Staffing – Add the new contributors.

Blending – Use knowledgeable internal people, and new outside people, on the same team.

Duplication – Fund two or more contributors to work separately on something really important and take the first or best result.

Compression – Increase efficiency by reducing the size of the team and getting a bigger commitment from each team member.

Prototyping – Ask one person to build something new and show the results of the experiment.  This reduces total work time while increasing elapsed time.

Dispersion – Share an API or other architecture that helps others build around your product.

Tech leadership – Get focused attention from an individual who works on both architecture and implementation.

Research – find, test, and adopt existing code, product, and technologies

This list includes four tactics that increase the size of the team (scaling, staffing, blending, duplication), and three tactics that decrease the size of the team (compression, prototyping, dispersion) , and two tactics that are size neutral (tech leadership and research).

Today we are announcing Advanced Merge Requests for Git.  You can find them in your Git/Source tool under the “Contribute code” and “Review code” sub-tabs.  As a contributor, you can use a merge request to submit a change from your branch or fork.  As a reviewer, you can use merge request view to pull and test changes, vote on them, discuss them, and merge them.

We enjoyed testing this feature.  It's exciting for me to see code contributions piling up in the merge request list from our own developers, ready to go into the daily releases.  Merge requests are an important part of a Scalable Agile process by allowing you to select and release what's ready rather than slogging through a pre-planned iteration.  It saves time, improves quality, and increases creativity.

A year ago, I talked about four ways to manage code and simplify projects.  Merge requests help you implement two of them, which I will call "fork" and "branch" because you can submit merge requests from a fork or a branch.

Fork		Branch
In the fork workfow, contributors post merge requests from cloned or "forked" repositories. "Maintainers" pull the changes, test them, and commit them.  This is the github workflow that revolutionized open source development. Fork workflow is good for independent teams and for people who work independently and are ready to maintain their own clones.  It puts some load on the maintainer, which we spread around in our implementation with features like voting.		In the branch workflow, contributors  make temporary branches of the master version and submits them as "changes." A core group reviews changes and accepts them.  Our implementation is modeled after the Gerrit system that Google uses for Android contributions. Branch workflow is good for full-time teams that work closely together and for products where the master branch is maintained to be releasable.

How To Use Merge Requests

To contribute with a branch, "git branch" locally to create a branch for your contribution, and push your changes.  Now you can go to "Contribute code" under the Source/Git tab and select "New Merge Request."  Search for your branch, and write a description of your contribution. Optionally  use #<ticket> to link it to a ticket.

Now the merge request shows up in this nice list for reviewers.

The list is sorted with the most recently active on top, and it shows the current vote and comment counts.  You can see your requests by selecting "me" from the user filter.

Click on a merge request to review or respond.  You will see something like the screen below, where we provide instructions for each role.

Review: If you have rights to review and merge in the target repository, you will see a reviewer bar.  To get and test the code, select "Get changes" to see the Git commands, or just select the clipboard icon to grab them.  Then comment, vote, or merge.  You can vote just by selecting the red and green buttons.  Ultimately, the goal is to "merge and close," accepting the change, or "Ignore," discarding the change.

Contribute: If you have rights to contribute in the source repository, you will see a contributor bar where you can submit a new version, after changes are pushed to the source branch.  In the branch case you will usually have both contributor and reviewer rights.  Speedup tip - if you are a reviewer, you can often fix a change and add it as a new version.  It works great if you create pairs to review each other's code.

The review panel is under the Version bar.  You can see the discussion thread and write your own comments.  My favorite feature is the "files affected" tab, where you can see all of the changes and pop them open in an AJAX panel to see the diff.

Merge request events such as posting a request, comments, and votes, show up in the activity stream as "code reviews" with this icon .  You can subscribe to email alerts by going to the Stream tab > email notifications subtab > and selecting "Code reviews."

Past and Future

We started thinking about improving merge reqeusts a year ago when we embedded Gerrit and started using it in the Assembla development team.  We eventually decided that we wanted to bring our customers something that would be simpler to use, integrated, and available in local languages.

Now, we believe that advanced merge requests are a core feature of our scalable agile process.  We are committed to upgrading the Git workflows and to implementing merge requests for our other repository types.

Assembla Timer is a handy third-party Mac application that tracks time spent on tasks. You can time your work on a digital stop watch and then post the time to an Assembla project, or directly to a specific ticket.

Until recently, Assembla Timer was $0.99 in Apple’s App Store, but the app’s creator, Adam Bronte, has decided to make it free and open source. 

The source code for the app is available here and a compiled version ready for install is available here.

I installed the application, and the setup was a breeze. You simply enter your Assembla username and password, then click the ‘Start’ button to begin counting off time. You can stop and start as many times as you like - the app keeps a cumulative sum. When you’re done working, type in a description of the work completed and select an Assembla project workspace. You can also associate the time with a specific ticket. When you click ‘Save’ your information is stored in your Assembla project.

Those familiar with Assembla’s time tracking capabilities know that there is a field on every ticket for “Worked Hours,” and a “Time Expenditure” tab on each ticket shows the total hours worked for a task. Assembla's optional Time tool shows time worked across all tasks. The Time tool provides filterable reporting and is exportable for accounting and billing purposes. The Assembla Timer app makes it easier to feed accurate timing information into these reports.

Assembla Timer is simple to use and allows you to focus on your work while a lightweight desktop application takes care of recording and posting your time to Assembla.

Here are answers to questions posed during the lively question and answer period of the webinar Scrum, Kanban and Scalable Agile, in no special order.

Here is a video recording of the webinar. 

Q: Is the cardwall (Assembla) view the same as kanban?

A: Kanban is a work process that involves trying to move a task as quickly as possible through various stages, for example, design, development and test.  The “Kanban board” is a bulletin board where you can see tasks represented as cards in status columns.  “Kanban” is Japanese for, approximately, “card display.” The Assembla cardwall is a view of Assembla tickets, represented as cards, arranged into columns for each status.  You can use it as a Kanban board or Scrum board.

Q: Are pull requests part of the "Issue Tracking/Ticketing" feature?

A: Merge Requests are part of the git repository feature (Source/git tool  in Assembla).

Q: When will the backlog planner be available in production?

A: The Simple Planner will be available in about four weeks – the second week in April.  We will need  another three weeks after that to finish Backlog planner. 

Q: When will the features Andy demonstrated be made available to Private Install users?

A: Advanced merge request will be available in the Private Install the first week in April.  Simple Planner will be available by the end of April. For those who haven’t heard about it before, Private Install is a version of Assembla that can be installed in your data center.

Q: is it possible to have a "standard" milestone, with x amount of tickets, if you have a standard flow you use several times a year?

A: We have received this request before.  I think that the idea is to basically copy a template milestone, so that you get a prepared list of tasks.  There is no simple way to do this now in the Assembla Tickets feature.  We will add a cut and paste feature that will make this easier.  In the current system, you can make a project Space that contains prepared milestones and tickets, and copy that.  You can do it with the “template” type in a portfolio, or with “Copy this space” in the footer of any space.

Q: Andy, what was the development language in the project you mentioned?

A: We mentioned the Assembla.com development project.  We use Ruby on Rails, combined with various other components (message queue, hacks for git and subversion, etc.)

Q: Are there any plans to release an aggregated planner for Assembla Portfolio?

A: Yes.  This is an important design project.  We call it the “Multi-team” dashboard, because it will help many teams work on one project.  I am going to invite people to join us in this design process, and I hope this will also be a forum where people can share ideas about Scalable Agile.  If you are interested, please email us at scalable_agile (at) assembla.com.

A: At the code level, I think that you just have to distribute all of the code, and let each person work on his piece.  They will be building the same code, but independently.  Sharing is scaling.  If you share the code, people can figure out for themselves how to fix problems or get in touch with other component specialist, and route around problems.  At the level of a cloud system, you often have separate servers.  Then you have a more complicated job if you want to give people a place to test their stuff with everyone else’s components.   I personally think that the miracle of on-demand cloud systems often makes it possible to give each feature team a sandbox with many of the components.  They should be as independently powerful as possible, to remove constraints.

In both cases, I like the idea that each developer or team is going to pull changes from the current release, and test the current release with their changes.  This is in contrast to a system where they all push changes to a central build.  You can often block people if they are waiting for centralized test resources.

Q: In Assembla workflow, is it possible to manage teams backlog?   There is the global project backlog feature, but what about if you have specialized teams and want to assign a specific ticket to a specific team?

A: In the Assembla.com development project we added a custom field for “Feature team” so that we can assign a ticket to a team, and we can use filters to see tickets for a team in the List or Cardwall views.  We are going to carry this idea into the Backlog sorter, where you will be able to select the same filtered  view (for example, just team X) and sort that smaller list.

Q: Will Assembla support pure Scrum in the near future? If not, why not? :)  Why are there story points for subtasks – do these make the burn-down inaccurate? Regarding the average velocity calculation / chart – are there any plans to add that to Assembla in the near future?

I believe that the most important think that Scrum teams use that Assembla lacks is the Story/subtask breakdown. We support this in the “Outline” view, and with child tasks, but not in the other views.  We will add this to the Simple Planner in a second release, so that you can plan with stories, and then expand them with a list of subtasks when they move into the Current work bin.

We let you enter points on stories or subtasks.   You will need a policy to use one or the other, because they will add together.   If your policy is to enter zero points on subtasks, then your story estimate will be useful.

Yes, the Simple planner will include an average velocity calculation and chart, with the four week trailing average used  to set the capacity default.  With these adjustments, Simple Planner will match the traditional Scrum process.

Q: Any plans for plugins for IDEs such as VS, Netbeans, Eclipse, etc?  

A: Assembla has a MyLyn plugin for Eclipse that is actively maintained by a contributor named Brett Smith.  Thanks, Brett.  We do not have any plans to support Netbeans and Visual Studio, but we will work with and subsidize contributors who want to work on those.

Q:  What kind of predictability do you have around when a feature will be released? 

With our process, I find that I can predict about six weeks in advance.  So, the release date is fuzzy until we are within six weeks of release.  I hypothesize that you can increase this time horizon if you work on bigger features, and if you have slack  or are not going as fast as possible.   There is obviously a direct tradeoff between how hard you are driving and how much predictability you get, and I am willing to trade away predictability and just focus on top priorities.  There are people who are much better at tracking velocity and improving estimates.  Those people will have a useful tool in the Simple Planner.  It encourages you to enter an estimate in points on every ticket, it tracks historical velocity, and it uses that to put bars into the sorted backlog that show the estimated release date at various points down the backlog.

Q: About scaling for multiple teams. How does the new planner support multiple team development? We use one backlog, but we need to follow-up each team’s contribution during a Sprint.

I have three suggestions for you.  First, we are using YOUR idea of feature teams as a filter, and giving you a way to filter the backlog sorter and cardwall view for each team in a space.  Second, the Advanced Merge Request will help you merge code from different teams.  Third, we are building a new “Multi-team” planner in the Portfolio.  This has four basic functions.  It helps you set a milestone for all of the related spaces/teams working on a project.  It reports on all of the tasks in that milestone.  It helps you move tasks between the spaces for different teams.  It will show dependency relationships between tasks, and between tasks for different teams, so that you can see, for example, if one team is waiting for something that is not in the Current iteration for a different team.  I want to involve you in the design process for this feature.

A: Git does require some training.  It has more commands and is conceptually different from Subversion.  We recently posted a tutorial about setting up git for Windows – a common question.  I will look for a more comprehensive list of tutorials.

Q: When will Assembla support enforced/defined WIP limits?

A: In the Simple Planner we give you a convenient place to estimate work amount (a prerequisite for WIP limits) and we enforce a WIP limit for the Current iteration or bin.  As soon as that is released we will add capacity settings to the cardwall columns (status values).  This  will not enforce a limit, but it will show an alert on the column when you are over the limit.

Q: In the examples you have shown, stories do not split into tasks. Would not be easier to maintain a product backlog with higher level stories, which are divided into tasks when enter into production?

A: Yes.  That will be in a second release.

Q: Has Agile or Kanban helped you deal with developers incorrectly trying to fulfill their role rather than trying to help the product?  I.e., a code manager looks for ways to spend 20 hours doing code management so he can get paid when only 3 hours of code management is necessary in that particular week and 17 hours could have been spent in more constructive "helping build the story" ways. 

A: We use a simple online standup form to find out what people are working on, and we look for cases where a person is not working on the things that we think are important.  Ideally, we can encourage everyone to work on the most important stuff each day.  We think this works better if our project leader is a “tech lead” and knows the details, rather than a less technical scrum master or project manager.  The process should go around obstacles, such as people who don’t want to participate in the methodology or people who are not strong contributors for other reasons.  In the future I would like to do some sort of “gamified” contribution board, so that people can see how they are doing.  That might encourage people to work on tasks that we think are valuable.

Q: What do you recommend for a small team that does development as well as production support? What's the best practice to accommodate the workload?  Currently we do not use a Kanban or scrum tool.  We have Issue Tracker and mostly issues that we have to resolve quickly.  For development we have project work. This can be new features, enhancement, existing, bug fixes.

A: At Assembla, we keep a ticket list only for support cases.  However, if these require a response from the developers, we mix support issues into the ticket list for our development project.  We’re using the Toyota Jidoka / Lean idea of “Stop the line” when we run into an important problem.  We have a separate milestone called “Fix Today.” If something goes into that milestone, we stop and fix it.  If the issue is less urgent, then we just put it into the Current work bin with the other tasks, at an appropriate priority level.  Our system will show “high” priority tasks on top of the stack in most views.  I personally don’t think that there is a big difference at the task level between customer problems, bug fixes, enhancements, and new features.

 

View and download the slides from the webinar here

This webinar covered how to accelerate software development by combining elements of Scrum (with fixed-length sprints), Kanban (continuous flow with rapid completion of each selected task), and Scalable Agile (multiple contributing teams working on a big project).

Agile expert Damon Poole describes how to introduce Kanban into a Scrum process, how to accelerate development with "One Piece Flow", and how to coordinate the work of multiple teams.

Assembla founder Andy Singleton previewed his vision of Scalable Agile, and showed two related features. The "Simple Planner" view of Assembla tickets with an AJAX UI helps you to move effortlessly between Scrum iteration planning and Kanban. The Advanced Merge Request feature can help you manage continuous development and release.

Questions ans answers from the webinar have been posted in a seperate blog post.

When I talk to corporate people about agile, they are usually talking about “Scrum”.  Here’s a ten second description of Scrum:

A team gets together in a short planning session and decides what they will work on in the next iteration.  Then they work for a fixed period of time – often several weeks – and they end up with a “potentially shippable release”. 

There’s more - you’ll hear about three roles, three meetings, three artifacts - but not too much more.  If you have a team of 5 to 10 people, Scrum can help you achieve the agile goal of frequent, high-quality releases.

However, just from that brief description, you can already see why scrum will be frustrating if you want to get something done in any other circumstance.

1) “A team…” - It’s a small team methodology.  A scrum team has 5 to 10 people.  Less, and you don’t need this structure.  More, and you can’t run as a “self managed team.”  Unfortunately, software projects often require a bigger group effort.  The Scrum answer to this is to divide into teams of the right size, and then organize them hierarchically into a “scrum of scrums”.  This is sort of like the old idea of communist cells (Russian Bolsheviks organized themselves in “cells” of about 10 to hide from the management of the day) that would somehow “spontaneously” organize into a self-managing worker’s paradise.  That didn’t work out, mostly because a hierarchical organization is a by nature a command and control organization.  Given that the commander is not omniscient, this type of organization makes all of the mistakes that the “self organizing team” is hoping to avoid.

2) “…gets together…” – It’s only recommended for co-located teams.  However, most software teams are geographically distributed.  Good luck with that.

3) “…in a short planning session…” –  Iteration planning is hard.  In the scrum concept, it requires a lot of machinery.  They might pull out planning poker, and argue about point scores, and track their historical productivity (velocity) over months and years.  These poor saps are trying to predict the future.  It’s hard to do well in a short planning session.  Maybe it deserves more time?  It’s impossible to do well if you have more than ten people contributing, or a lot of different teams.

It gets worse.  If you adapt your process to get out from under these problems, you can be accused of “Scrumbut,” which sounds sort of like picking your ass, and apparently is a fatal weakness.   You can avoid these problems by paying a “certified scrum master”.  There is a whole industry of Scrum consultants who will try to make your non-agile organization more agile by following the scrum formula, but curiously, are forbidden by the formula to work directly on code or take responsibility for delivering anything.

It is possible to go beyond Scrum for both small and large groups.  I have noticed that effective teams tend to adapt in similar ways, especially if they have open source development experience.  We have been studying these adaptations, and compiling them into recommendations for a truly scalable agile process.

Today I will be talking about this in a Webinar about Scrum, Kanban, and Scalable Agile with Damon Poole. He will clearly explain what "Scrum" and "Kanban" mean, and make some great recommendations about how to combine them for less planning stress, and more scalability.  I will be showing some of our new tools for Scalable Agile.

EasySVN is a Subversion client with a unique (optional) feature to automatically update and commit.  It syncs local folders to Subversion repositories, so you can drag and drop, add, and edit, while EasySVN takes care of updating and committing any changes to files, whether from you or from others. This beta release includes the sharing cycle - an integration with free Assembla repositories that makes it incredibly easy to post and checkout files. Download the EasySVN beta-2 release for Windows.

You might be interested in EasySVN if:

• You are a designer working with developers
• You are a Web developer who wants a very simple way to deliver your work in a professional repository.
• You share and sync files (even large files), and you prefer an open source system that allows you to grab a complete repository, move it to new hosts, and control security.
• You share versioned desktop files (eg lawyers sharing documents with clients).  EasySVN saves every version and every change, and keeps you focused on the most recent version.

This release of EasySVN for Windows includes TortoiseSVN.  You can use the simple sharing cycle with automatic commit and update, or you can use all of the Subversion operations in TortoiseSVN.

We are also working on a Macintosh client.  It is a rebuilt version of the open-source SCPlugin client that includes finder integration, automatic commit and update, and the sharing cycle.  We should have a beta release in a few weeks.  You can find an early alpha release here.

Automatic update and commit

When you set “automatic update and commit" on a folder, your files will always be up to date.  As you edit files, or move between computers, the system runs in the background to commit your changes and retrieve updates from other locations. This makes using Subversion as easy as dragging and dropping and editing files on your local computer, while EasySVN takes care of the rest. 

The TortoiseSVN and EasySVN teams developed technical wizardry to handle open files, detect file activity, and handle editing conflicts.  The result works like other state of the art file sync tools, but with a versioned backend, portable repositories, and open source client and server options.  These Assembla clients are completely open source.

Sharing Cycle

Sharing Cycle includes three features that further simplify SVN operations for Assembla users, plus free backend storage.

	It all starts with Checkout from Assembla which provides users with the list of available repositories that are shared with your Assembla account. Your working copy will be automatically placed into a new sub-directory with a corresponding name.
	Share on Assembla allows users to put any local directory into an Assembla repository in one step.  Just right-click and “Share on Assembla“.  In the background, it creates a repository, checks out a working copy, moves files into the working copy, adds them, and commits them.  I always found this procedure very annoying, and now we have automated it.
	To share, simply select Share with team member from the EasySVN menu and enter the e-mail addresses of the people you want to share with. Existing Assembla users will be matched and added to the shared space automatically. New users will receive an invitation.

 

Our contribution to Subversion and Git

Git users will soon get "Advanced Merge Request," a feature that improves on the things we like about git - wonderful merge, review, and release workflows.

With EasySVN we are improving the things that we like about Subversion - ease of use, and support for big repositories.  Download newest EasySVN beta for Windows.