We have just released a feature for those of you using FTP, SVN/Git, and Tickets. We noticed an annoying problem related to the lack of traceability of changes between different servers. How does a Project Manager or QA know if a ticket is deployed to a server or not? The FTP output does not clearly state which ticket is deployed where:

Even when digging deeper (click on the event), this output is not that useful for non-techies (what are they doing in FTP tool at all?). 

But wait! What if you click on 2..3? This view is certainly more interesting - showing all deployed files, changesets and affected tickets. Perfect spot to gather your release notes.

And to make it even more sweet, a friendly Assembla Bot will comment on each affected ticket letting everyone know that code affecting this ticket has been deployed to a certain server.

We hope this can make your team even more productive while using Assembla!

On November 15, Assembla and WANdisco presented a webinar Beyond Scrum: Scaling Agile with Continuous Delivery and Subversion. For those that did not get a chance to register or attend, the video and slides are below. Enjoy. 

View and download the slides

In this 30-minute webinar Andy Singleton of Assembla and Scott Rudenstein of WANdisco described how to go beyond traditional Scrum principles and scale to globally distributed teams with continuous delivery and Subversion.

They discussed how to:

• Achieve continuous delivery using branch, merge and code review techniques.
• Accelerate the work and coordination of multiple distributed teams without lengthy meetings.
• Improve performance and security management, while replicating real-time repositories, within a centrally-managed Subversion infrastructure.

 Other Releated Resources from our Blog:

• Build your Assembla Merge Requests Gangn..Err Gerrit style with Jenkins
• Take Control with the Continuous Delivery Dial
• The Three Agile Use Cases: Where Do You Fit In?
• Beyond Scrum Roadmap
• Avoiding Premature Integration or: How we learned to stop worrying and ship software every day
• Intro to Scalable Agile: Scale Your Teams and Release More Frequently
• Continuous Delivery and Scalable Agile - Find Out the Secret

We have been writing a lot about Continuous Delivery and Continuous Integration and have discussed Continuous Deployment in our blog series.  If you are like most people these buzzwords are confusing and often misused.  I am going to try to dispel some of the confusion surrounding these processes and how they can all work together to provide a kickass environment that Managers, Developers and Customers love alike.

Continuous Integration

Continuous Integration is the practice of merging development work with a Master/Trunk/Mainline branch constantly so that you can test changes, and test that changes work with other changes.  The idea here is to test your code as often as possible to catch issues early.  Most of the work is done by automated tests, and this technique requires a unit test framework.  Typically there is a build server performing these tests, so developers can continue working while tests are being performed.

Continuous Delivery

Continuous Delivery is the continual delivery of code to an environment once the developer feels the code is ready to ship.  This could be UAT or Staging or could be Production.  But the idea is you are delivering code to a user base, whether it be QA or customers for continual review and inspection.  This is similar to Continuous Integration, but it can feed business logic tests.  Unit tests cannot catch all business logic, particularly design issues, so this stage or process can be used for these needs.   You may also be delivering code for Code Review.   Code may be batched for release or not after the UAT or QA is done.  The basis of Continuous Delivery is small batches of work continually fed to the next step will be consumed more easily and find more issues early on.  This system is easier for the developer because issues are presented to the developer before the task has left their memory.

Continuous Deployment

Continuous Deployment is the deployment or release of code to Production as soon as it is ready.  There is no large batching in Staging nor long UAT process that is directly before Production.  Any testing is done prior to merging to the Mainline branch and is performed on Production-like environments, see Integration blog article for more information.  The Production branch is always stable and ready to be deployed by an automated process.  The automated process is key because it should be able to be performed by anyone in a matter of minutes (preferably by the press of a button).  After a deploy, logs must be inspected to determine if your key metrics are affected, positively or negatively.  Some of these metrics may include revenue, user sign-up, response time or traffic, preferably these metrics are graphed for easy consumption.  Continuous Deployment requires Continuous Integration and Continuous Delivery - otherwise, you are just cowboy coding and you will get errors in the release.

Once you have moved to a Continuous Deployment process, you will have to have several pieces of automation in place.  You must automate your Continuous Integration Build Server and Continuous Delivery to Staging, as well as have the ability to automatically deploy to Production.  

In the ideal workflow, the entire process could be automated from start to finish:  Developer checks in code to development branch, Continuous Integration Server picks up the change, see how to Build Gerrit Style with Assembla, performs Unit Tests, votes on the Merge to Staging environment based on test results, if successful deploys it to Staging Environment, QA tests the Environment, if passed, they vote to move to Production, Continuous Integration server picks this up again and determines if it is ok to merge into Production, if successful, it will deploy to Production environment.  This process varies slightly based on needs, requirements and approaches.  

Continuous Deployment relies on small changes which are constantly tested and that are deployed and released to Production immediately upon verification.  The ownership of the code from development to release must be controlled by the developer and must be free flowing.  The automation of steps allows this process to be implemented and executed without cumbersome workflows.  Read About Moving Beyond Scrum to see how Assembla can be used to provide this process and help you reach Continuous Deployment on your codebase. Also, check out our Continuous Delivery page to see how the Assembla product helps you deliver quicker.

Git is the rage, we are all rushing to move over to it.  But there is a critical problem, git allows for almost any workflow imaginable.  I mean, I can use a straight svn style workflow with a master (similar to svn trunk) branch and have development or release branches from that.  I can implement the rather common nvie workflow or use a Gerrit workflow.  I can come up with some other masochistic workflow.  So what is the best git workflow.  Honestly, I don’t know.  It truly depends on your needs and your situation.  

For open source projects, it seems that forking and merging back into a master repository is working well.  For businesses, well they are still trying to grasp what git is and how they can utilize it effectively.  What I have found works rather well for Assembla, boasting 25-30 developers at any given time, is a forked network that has one repository per developer and a common origin.

The Story

So here is the story, Assembla transitioned to git and did what everyone was doing, had no idea how to work in it - so we used it, as I like to call it, “subversion-style”.  It was not utilizing the power of git for what it was, but it worked, so why fix it?  Well, keep reading to understand why.  We were releasing about 1-2 times per month, nothing impressive.  We got our features out and they had bugs.  We would fix them.  The team was typically stressed, we were either in a release sprint or in a bug fixing mode.  There seemed little time to breathe and releases started getting more complicated and more error prone as time went on.  We knew this had to change.  We realized that we had to move QA and the way developers were working in the codebase.  Read more about our workflow and conclusions where we Learned to Avoid Premature Integration.  This took a radical change to the way we worked in git.  In the end we are releasing software several times a day while the development team has less stress and issues because of the process change.

The Conclusion

Our developers work in forks, with a common origin.  This allows them to have as many branches as they like and create whatever tags they deem necessary without interfering with anyone else, as well as break their build or have unreleasable code in it.  They then merge their work upstream as well as merge changes from upstream to get other peoples work.  Since all the work is pivoting around a common origin, and since this common origin is always considered stable, the work is able to be integrated with production code and shared amongst developers without conflicting with each other.  Of course conflicts will occur, but they are dealt with by the person who contacts them.  Read more about this problem where we explain the Continuous Delivery process.  The basic structure looks something like this:

Its very simple, but that is what makes it so flexible.  One developer will not block another developer’s work.  Prior to code being merged into origin/master, origin/master must be merged back to the dev/master repository or a temporary branch from origin/master with the merge set from the dev/master repo must be created to test for conflicts or test other issues.  Whenever code is committed to origin/master, it must be considered stable and ready for deployment to production.   We use Merge Requests internally to control the flow of code from developer’s repositories to origin, read about how you can use Merge Requests to Code Review.

The above process can be used in teams as well, allowing for a more rigid architecture, and more control points.  If we move the developers down into branches on a team branch, and have them submit Merge Requests up to the team/master, then teams submit Merge Requests from their team/master to origin/master.  This is where Assembla went before transitioning developer’s into their own forks.  We had a git architecture that looks like this:

Now the work is aggregated into team/master before going forward into origin/master.  We found that often releases were delayed and one developer’s work would interrupt another developers work.  We only moved the problematic points to team/master instead of origin/master.   By moving the pain points to dev/master, we keep the problem where it belongs, at the developer’s fingertips.

Assembla recently finalized the switch to working in developer only repositories, we have seen great success so far.  And every developer is learning more about the tool that seems so hard for many to grasp - git.  And we know that it is already far better than our “subversion-style” workflow:

To learn more about how to utilize Assembla to achieve a better workflow, read Git Review and Merge Like a Boss and Avoiding Premature Integration: or How we learned to stop worrying and ship software everyday.

Your Source/SVN tool now supports a modern code review and code contribution process. You can see it under the new "Review code" subtab.  It is similar to the workflows enjoyed by git users to include a large number of contributors or to review code for continuous integration and continuous delivery.  You can put your changes in a branch, review them, and merge them through a Web-based UI.

This first release has a simple workflow that requires users to manage their own branches.  Please leave a comment with your feedback.  After we are sure that this is working smoothly, we will enhance it with much-requested features like extra permissions on trunk (to push contributions into reviewed branches), one-button branch creation, and inline code commenting.

How it Works:

Make a temporary branch.  Write your changes and commit them.

Make a merge request.  You only need to select the source branch. We already know how to merge it to the destination it was branched from.

Contributions show up on the review list

Select a merge request to review.  You can open the "Get Changes" link to see instructions for merging and testing the changes.  In most cases, you want to test the result of merging the change with trunk (or the source that you branched from).  So, the instructions will ask you to switch to trunk, and merge the changes.

Use the controls on the merge request to write comments (you can @mention the contributor), vote, and view changed files and diffs.

Subversion merge requests have a lot of the same great features that are in our git merge requests.  For example, they get linked to tickets when you include a #ticket link in your commits.  So, when you can see the status of the relevant code changes.  And, when you look at a merge request, you can see the tickets you are working on.

Patch or branch?

A lot of Subversion code review systems use patches.  You make a patch (a diff file with the changes) and you upload it to a code review system like Reviewboard, or you email it to a list of reviewers (Subversion developers do this on the Apache Subversion developers list).  The advantage of a patch is that it is easy for a reviewer to apply it to whatever version of code he is working on, and it doesn't need to be integrated with your repository server.  However, it is annoying to make and upload a patch, and you can't fix it.  If you see a problem in a branch, you just switch to the branch and fix it.  We discussed this with our own team, and with some of the Apache Subversion core developers, and we decided that we prefer reviewing and sharing real branches.

We hope that you see some benefit in the branch-based workflow.  Leave us your comments.

Assembla is pleased to officially announce the release of Assembla Touch for Android, a free, full-featured app that brings Assembla's task and project management features to anyone with an Android phone or tablet.

The new application syncs with any project that has the Tickets tool installed. From your Android device, you can easily see and search project tasks, create new tickets, edit/comment on existing tickets, view your activity stream, and even attach files such as screenshots and optionally include device info and errors logs as ticket comments – perfect for Android application development and testing.

Note: While Assembla Touch for Android has been available on Google Play for over two months, version 1.0.2 was recently released on December 18th. For those that have found Assembla Touch prior to 12/18, please make sure to update to the most recent stable release.

Key Features:

Create New Tickets in Seconds:
Think of a great idea or something that needs to be done while you’re on the go? Quickly create a new ticket in seconds. Assign it to a team member to work on or maybe to you to add more details later - either way, it is posted so it will not be forgotten.

Attach Pictures:
It's easy to attach a picture from the phone to a ticket. This is the feature that I use most frequently. Simply sketch something on paper or a whiteboard, snap a picture, and add it to a ticket.

See What’s Going On:
View your full activity stream or filter the stream events for specific projects. Click on ticket activity to access the ticket via the app where you can edit, add comments, etc.

Mobile Development and Testing:
If you have ever developed and tested mobile apps, you know how difficult it can be to pinpoint bugs/issues due to unknowns like what was the state of the device when the error occurred, exactly what device and what version of the OS is it, etc., but Assembla Touch for Android makes this easy.

Test your app from mobile devices. When errors occur, simply snap a screenshot and attached it to a new or existing ticket via Assembla Touch. Include the device info and error logs and now your team can fix the problem without spending excess time trying to diagnose the problem. 

We find this to be extremely useful and a must for anyone testing mobile applications or mobile-optimized sites.

Find What You’re Looking For:
The homepage allows you to easily access tickets assigned to you and tickets you follow. You can filter all project tickets by project, milestone, or user. A search conveniently lets you find the ticket you need, when you need it.

Security On the Go:
Assembla Touch uses HTTPS to communicate with Assembla servers so that your password is never exposed on public networks.  Additionally, authentication and authorization uses oAuth2 so your password is not stored in the app. 

Get the App:

Download the app today on Google Play. For users with iPhones and ipads, learn more about Assembla Touch for iOS devices and download it today in the App Store.

Let us Know What you Think:

Since this is the first official release, we would like to hear from you. Please leave your comments below and we will take them into consideration as we continue to improve the app. 

Today, a high risk Security Bulletin was posted for Ruby on Rails.  Assembla was able to process this request and patch within 3 hours from the posted bulletin.  We did this working solely within our normal, everyday process.  This is the power that a good Continuous Deployment process brings to the table. 

Being able to patch 3rd party applications is rather important these days.  As we rely more on them, we become more vulnerable.  High profile security bulletins are common, we love Hacker News, but its not a secret, and the number one posting today is about the Ruby on Rails vulnerability.  This means that everyone else knows about it as well - so the clock starts ticking.  How important is your data?  Ignoring a problem like this can be the end of your business, whereas getting a fix out quickly will make your customers feel better and safer knowing that you have them covered and possibly give you a competive edge as everyone else is running around patching and fixing issues.

In walks Continuous Deployment (for more information, see definitions) to help you streamline your process.  At Assembla, we were able to patch our codebase, test it via our CI server, do quick QA analysis and then push right out to production with no bottlenecks.  It took longer to get notified than to start the process, the conversation went like this:

[12:59:49 PM] Lead Dev: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/DCNTNp_qjFM
Did we patch?
this is on top of HN
[1:00:27 PM] Me: no
I will create a ticket and get it looked at
[1:00:39 PM] Lead Dev: lets patch now
[1:00:44 PM] Me: OK

Time went on as he pushed the patch to our Origin and our CI process kicked off, we had some failed specs, that was dealt with, then we got ready for deploy:

[2:05:18 PM] Me: and we are going to deploy

So approximately 1 hour after the bulletin was realized, we had deployed the patch out to production.  That is nice work, we even had spec failures that alerted us of potential issues, but did not stop the process.  Deploy takes about 10 minutes and is completely automated, after you press the button.  That's it, no big deal to update a major component quickly.

Check out how we accomplish this with:

A Better Git Workflow

A Better Integration Strategy

A Good CI strategy

And lots of Automation.

Learn how you can Achieve Continuous Delivery

Does your deploy process compare with this speed? If not, maybe you want to check out how Assembla can help with your Continuous Delivery process. 

We just released a frequently requested feature - an implementation of Story tickets with subtasks. You can use the subtasks in a Scrum planning process, or you can use them as an informal to-do list. To see this new feature, go to the Tickets/Planner UI, and open a ticket by selecting the little triangle on the side. This opens a “task tray” under the ticket. You can write into the form to make a list of subtasks. You can create a to-do list in a few seconds, right there in the task tray. You can also drop other tickets into the task tray.

Tasks move with the parent Story ticket. So, if you sort the Story, or move it to the Current column, or to a different milestone, the tasks go with it. Use this relationship to make a list of tasks that should be completed before you release the parent Story.

You can also see the Tasks on the “Related Tickets” tab of the parent Story ticket, and you can add or edit tasks right inside the Story ticket.

The tasks are complete tickets, so you can assign them, discuss them, and see them in Cardwall and List views.

In the old Outline view, parent and child tickets are only loosely related, and child tickets do not move with the parent. The Outline parent tickets create an “epic” relationship, where you can release each tasks separately on the way to completing a major feature. We’re going to remove the old Outline UI in favor of the more modern Planner, but will offer a way to build the Epic relationships. Many Outline users told us that they wanted “move with the parent” behavior. So, now you have it with the expanding tasks on the Planner. Please switch over to the Planner UI.

Here are two ideas for using Stories and Tasks:

1) You can use Stories and Tasks in a classic Scrum planning process where you write Story tickets, and put them in your backlog, without tasks. The Story ticket describes the function, not the implementation. It includes a summary of the user goal and functional requirements, for example “I am a user and I want X, so I use the system do this action…” Then, after you pull a ticket over to the Current work column, you expand it by adding more detailed implementation tasks. Then you finish all of the tasks, and close the parent Story.

2) You can use this to make your backlog smaller and easier to handle by grouping several backlog tasks together under one functional story. You can drag and drop tickets into the story tray under a parent ticket. The Tasks are hidden in the Planner view, but are still fully functional tickets in the other views.

The Scalable Agile Design Group (SADG) is an informal group representing 11 companies plus Assembla, pulled together to share ideas about how Agile techniques can be scaled up to address large, complex software development projects.

Although the group is not a scientific sample, it does contain a cross-section of midsized and large companies in businesses ranging from sporting goods, to financial services, to online computer games, to custom software development.

Below are findings that provide insight into how Agile is currently being used and where it is going, based on interviews and discussions with 11 companies that have scaled Agile to larger projects. We also include links to some recent Assembla blog posts related to these findings.

Finding #1: There are three distinct Agile use cases

There is not one set of Agile best practices that fits all development organizations. In fact, our group showed three use cases that dictate very different priorities and methods. Development teams fell into three categories:

• “Major Release Developers” work on client-server and locally installed products with releases every three to six months

• “Cloud Application Developers” build web-based applications that are updated frequently, as much as several times per day.

• “Multi-Project Developers” work on many concurrent projects for multiple customers

The group you belong to determines which Agile practices make sense for you and which don’t.

Get more details in: The Three Agile Use Cases: Where Do You Fit In?

Finding #2: Almost no large Agile organization is totally co-located

The vast majority of companies in the group have distributed development organizations:

Number of companies with development staff in:

• 7+ locations: 27%
• 3-5 locations: 55%
• 1 location: 18%

And almost all of these companies also have employees working at home, freelancers, and virtual business partners at multiple locations.

Finding #3: Scrum is the default Agile methodology

Scrum is clearly the predominant Agile methodology in the group.

Number of companies using:

• Exclusively Scrum or “scrumish” techniques: 55%
• Scrum and Kanban or Lean techniques: 36%
• Exclusively Kanban or Lean techniques: 9%

Finding #4: Kanban has its place, but not as a replacement for Scrum

Kanban is not seen as a new wave replacing Scrum. Rather, Kanban and lean techniques are seen as the right fit for web-based applications with frequent releases (Cloud app developers in finding #1), while Scrum is still viewed as optimal for client-server and locally installed applications with less frequent releases.

Companies are incorporating Lean concepts into their Scrum processes. This includes leaving room in the sprint plan for last-minute new tasks and limiting WIP within a sprint. These practices reduce some of the inflexibility of pure Scrum, while preserving advantages such as having defined releases at regular intervals.

We recently posted a blog article that discusses this hybrid approach. Check out: Scrum + Kanban = ScrumBan, an Easy Scrum Upgrade. See where ScrumBan fits in the progression toward Continuous Delivery: Assembla's Beyond Scrum Roadmap

Finding #6: Coordinating teams and dependencies is a major challenge for scaling Agile

Perhaps the greatest challenge in scaling up Agile projects is coordinating teams and managing dependencies across teams. As projects grow, development groups resort to ever more complicated and time-consuming rounds of meetings and calls. This is clearly a topic crying out for new ideas and fresh thinking.

Read: 3 Ways to Handle Dependencies

Finding #7: Continuous Integration and integrated testing are critical for scaling

The companies that have scaled most successfully are strong believers in Continuous Integration. They have invested in processes and automated build tools to the point where they create new builds daily or several times each day.

The organizations with the fastest release cycles have also worked hard on integrating testing into all parts of the development cycle. Testing early and often allows them to find and fix problems faster, without slowing down release cycles.

Assembla has published a lot about continuous integration and Continuous Delivery: 

• Continuous Delivery and Scalable Agile - Find Out the Secret
• Continuous Delivery vs Continuous Deployment vs Continuous Integration
• How we learned to stop worrying and ship software every day
• Take Control with the Continuous Delivery Dial
• Assembla Tools for Continuous Delivery

Do these findings ring true for you?

Do these findings agree with your experiences, or contradict them? Please comment below.

Two critical patches were released by Aaron Patterson on the RubyOnRails-Security Google Group - Unsafe Query Generations and Multiple Vulnerabilities in Parameters.  Thanks Aaron Patterson.  Assembla was able to patch production from time of notification to production in under 2 hrs!  So what makes us able to do this so fast?  We have a great community backing us up - the Ruby on Rails Community, a global team ready to react to any scenario and a good Continuous Delivery process. 

OSS Community

The advantages of Open Source Software is well known, but having a good community is very important.  It was because of the efforts of this community that we have been notified twice in the last week about critical security patches.  Aggregators like HackerNews are invaluable in attaining information about issues and best of practices.  And of course the individuals that make up the community lead to better quality code.  The Ruby on Rails Community is top notch, self-regulating itself and fixing issues as soon as they arise.

Global Devops Teams

The global team is well understood.  Having a global team with 24/7 devops that can update code, deploy to production, and troubleshoot in real-time is invaluable.  Assembla has been taking advantage of the global team since inception.  We do not have to page a sysadmin in the middle of the night for critical pages.  We do not need special permission to move from development to production, we just click a button.  The devop is able to fix the code, test it, push to production and make it live.  

Continuous Delivery

Assembla uses a Continuous Delivery model that goes one step further to Continuous Deployment.  This allows the devop assurity that they are able to move from development to production almost instantly with a feeling of security and stability, through process and Continuous Integration.  If a critical patch comes in, we are sure that our Mainline is stable and that we can push a fix very quickly.  We are also able to stay closer to the bleeding edge of technology, since we are able to update and push more frequently, allowing us to patch critical security fixes faster.

Thanks again Aaron Patterson, Titas Norkūnas and Continuous Delivery for keeping us safe and sound.

The Tickets tool has an all new reporting UI.  You can find it under the Metrics subtab of the tickets tool.  This is a big leap forward for Assembla.  Our old reports (ticket metrics) were not useful, and we did not use them.  The new reports are redesigned to fit our continuous development process, so that every report has a purpose.

Please go and look at some of your reports, under Tickets/Metrics. You will probably learn something.  I did.  The first thing you will see is the “Contents” page.  This is a list of reports with a picture and an explanation of what the report  shows you.  Here are some new highlights:

Cumulative Flow Diagram

Cumulative Flow is so important that we will post a more complete article about it.  It shows you the status of open tickets, for each day that you have been working on the current milestone.  If you run a Scrum process, it will show you a burnup chart.  If you run a continuous or Kanban process, it will show your velocity, and what status tickets are piling up in.  Here is an article that shows the basic shape of Cumulative Flow.

Here a report for Assembla.com development.  You can see that we stopped doing releases during Christmas break, leading to a bulge in orange "Deploy now" status.

Velocity

A simple way to see weekly velocity – by number of tickets, or by points.   Use this to see your ups and downs, and to estimate your future capacity.

Here is an Assembla velocity report. We use ticket count (every ticket is one point).  You can see a decline in closed tickets during Christmas week, and a half week (through Wednesday) at the end.

Stuck Tickets

If you run a continuous process, you want to focus on tickets that do NOT move to the next step in a short period of time. Those are the things that will cause problems for your lean process.  The Stuck Tickets report shows them.  You enter a number of days, and it shows Current tickets that haven’t moved in that time.

These tickets have been stuck a long time!  I'm asking my guys to fix that.  I cut off the field at the end of the line that shows the date.  It sorts the oldest tickets to the top so you can see the biggest problems.

BONUS – User reports

The user report has some nice new graphics.  This report is amazingly useful  for me.  It shows user activity across all Assembla tools.  You can link to it from the Tickets user report, which shows the tickets a user is working on, or from the “reports” link on the Team page.

The left panel shows the times that a user submitted events, in your time zone, or their time zone.  The right panel shows the type of things that they are working on.  The rest of the report shows everything that they are working on, in detail.

You can see that I now have a management job where I comment on tickets but don't post code commits or handle merge requests.  There's a lot more detail further down the report.

We have a lot of credits for these new features.  Hank Lander worked through the requirements.  Ryan Yeske came in and added sophisticated new data structures to track the cumulative flow.  Felipe Artur, Kivanio Barbosa, and Andres Aguilar implemented the reports.  Paco Lule made design improvements. Leandro Camargo brought all these pieces together to bring the reports to completion. 

At Assembla, we have been working on going "Beyond Scrum" with new techniques for continuous delivery and scaling an agile project.  Our friends and technology partners at Perforce Software have joined the movement with a newsletter article: Beyond Scrum: How to Apply Agile Techniques to Distributed Teams and Large Projects.  This is the beginning of a tipping point in enterprise adoption.

Perforce built their presentation around one of our diagrams:

There is a lot of great material in this article. Much of it came from a joint webinar presented by Andy Singleton of Assembla and Randy DeFauw of Perforce. So take a look at the article, and if you want more detail watch the webinar too.

Have a complicated deploy process?  Want to simplify and standardize?  Assembla has just released a new tool, the SSH Tool.  It allows you to run any command remotely on a server straight from Assembla.  The script can be run manually, based on time frequency, or triggered by a repository event.  This allows you to setup deploy scripts, then deploy with one click - no matter how complicated your deploy is.  We use it internally to deploy assembla.com and to manage our servers.  

The possibilities are limitless with the SSH Tool, you can provision AWS servers, kick off Continuous Integration processes, and run deploys to any environment. What is extra nice is that you have a centralized place to review and monitor these processes as they run. For example,  Assembla has one script that lists all the current Staging environments running on AWS, very useful when trying to find an IP address of a Staging server.

Self Documenting & Traceable

Standardize

Technology

I talk to many Assembla Customers in a day, I figure that others can benefit from this direct communication with the VP of Engineering at Assembla.  

I am hosting an IAMA this Thursday, January 24th between 1600 and 2000 UTC.  Please join me and Ask Me Anything.  I will answer as truthfully as possible by a human.

Some Topics that might be discussed:

• How to use Assembla Code Review
• How to integrate Tickets and Code Commits
• How to use Stories and Tasks
• What is the future of Assembla
• What are the features of Assembla?
• What does it do other than store code or track bugs?
• Anything else you can think of.

So stop by and ask me anything: Reddit IAmA

 UPDATE: Thank you all who joined and asked questions, I learned a lot, I also really enjoyed it.  I will try to do another soon.  Those who missed it, feel free to read the past from the link above.

January has been a good month for Rails patches.  With the latest vulnerability released about 1 hour ago, we were quick again to patch our application.  Again our internal process was instrumental in allowing such a fast patch - within an hour from being notified of the issues.  This is the 3rd time this month that we have had such a situation and responded in similar fashion. 

This patch was a group effort with Lawrence Pit of Mirror42, the RedHat Security team, and the Rails Core Team.  The interaction of these groups is what makes the open source community work and so great to work within.  

Thanks goes out to Artiom Diomin, Stanislav Kolotinskiy and of course Michael Koziarski and the Rails community for fixing this vulnerability so quickly.  Without the work of the various members of the different teams, we would not be able to continue such fast patches.

As 2013 ramps up, we wanted to take a moment to reflect and thank you for a successful 2012. Below are some notable improvements our team accomplished in 2012 and a preview of what’s to come in 2013.

2012 Highlights

• Released the tickets Planner view which provides a simple, lightweight way to create, prioritize, and work on tasks
• Improved the way teams work on tickets with an updated ticket layout
• Improved team collaboration with @mentions, in-stream messaging, and more fine-grained email notifications
• Became the first provider of Perforce repositories on-demand
• Released advanced merge request for Git and later released similar code review and merge for Subversion users
• Released a new API and developer documentation site
• Built Jenkins plugins for Assembla team authentication and triggering builds
• Created a new support site to help user find documentation and interact with Assembla’s support team
• Released iPhone and Android apps for Assembla task management on the go

One of the biggest internal changes we made in 2012 was increasing our release frequency from once a month to daily, and many times, multiple times per day. This allows us to fix bugs quicker, release new features sooner, and ensure smoother releases with no scheduled downtime.

Migrating from iterative to continuous releases has taught us some aluable lessons that we have posted on the blog and presented in webinars. If your team is considering the move toward Continuous Delivery, we highly recommend you check out the resources below and feel free to ask us any questions. 

• The “Beyond Scrum” Roadmap
• Continuous Delivery and Scalable Agile - Find Out the Secret
• Avoiding Premature Integration or: How we learned to stop worrying and ship software every day
• Continuous Delivery vs Continuous Deployment vs Continuous Integration
• Git Review and Merge like a Boss

A Peek into 2013

In 2013, we're working on "beyond Scrum" agile software development. The current agile methods built around Scrum, co-located teams, post-it-notes, and monthly releases don't work well for our teams. Our teams are globally distributed, growing, and working continuously. The new approach combines task management, code management, online collaboration, and cloud infrastructure to thrust improvements from idea to deployment. Our users are doing it, and we're paying attention, and we're working to package up what we learn.

We kicked off 2013 with the release of our SSH tool, ticket stories with subtasks, improved reports, and various improvements to our UI and global styles. This is just the tip of the iceberg. Our team is working hard on many new features and tools that will be released in the upcoming months. If you have a feature request, please submit it on our feedback site.

The Cumulative Flow Diagram (CFD) is an extremely valuable management report. It gives you an “at a glance” picture of key process variables such as velocity, WIP and ticket cycle times. It can help you release more features faster by identifying bottlenecks and problems in your development process.

In Assembla it takes less than a minute to generate a CFD with your own ticket data.

In this blog post we will show you how to create a CFD, measure velocity and find bottlenecks in your development process. In the next post we will discuss cycle times and how the CFD can warn you about scope creep and other process problems.

Generate Your CFD

Cumulative Flow Diagrams are one of the management reports available as part of the Assembla Tickets tool.

To create a Cumulative Flow Diagram based on your ticket activity, just 

1. Click on the Tickets tab.
2. Click on the Metrics subtab.
3. On the list of reports, click on Cumulative Flow Diagram
4. Select the Milestone, Start Date and End Date and click the Update button

What is on This Graph?

You will see a graph that looks somewhat like the one below. It shows the number of tickets in each of you status categories, for the milestone and the time period you have selected. 

If you draw a horizontal line at any point on this graph you will see a snapshot of your tickets on a given date (how many with status “New,” “In-Progress,” “Test,” etc.). In fact, if you move your cursor along the top boundary of any layer a popup box will list the number of tickets in that category on each date.

So the CFD is really just a picture of your tickets by status over time. But this picture can tell you a lot about your development process. 

Note: In your graph the shape of the layers may differ from Figure 1 depending on whether your development process is based on iterations and sprints, or on a continuous flow. You can see “ideal” Cumulative Flow Diagrams for Scrum, ScrumBan and Kanban processes in Andy Singleton’s blog post: Scrum + Kanban = ScrumBan, an Easy Scrum Upgrade.

The Departure Rate (Velocity) Helps You Project Completion

The bottom layer on the graph (usually labeled “Fixed,” or “Done” or “Completed”) shows the number of finished tickets at different times. The upper boundary shows the cumulative number of tickets completed or “burned up” in the iteration or milestone. 

The slope of this line is the “departure rate”; that is, the average number of tickets completed per time period. In Kanban and other flow process this is usually called the “velocity” (in this diagram measured in tickets completed rather than points).  Either way, it is a measure of throughput and productivity.

The departure rate can help you estimate:

• The time needed to complete the current milestone.
• The time and resources needed to complete future projects with a given number of tickets.

Of course, these estimates are not going to be exact, because different tickets require different amounts of work. But over time they should average out and let you make rough projections. (Also, if you have a few very large tickets you should try to find ways to break them up into smaller ones.)

In addition, changes in the departure rate might indicate problems with your development process. For example, in diagram below, why were so few tickets completed between 2012/11/12 and 2012/11/26? There might be a good reason, but the CFD clues you in on where to look for possible issues.

By the way, the upper boundary of the top layer on the CFD represents new tickets arriving into the milestone, so the slope of that line is the “arrival rate.” 

WIP Levels Show You Bottlenecks

Identifying and eliminating process bottlenecks is a critical element of continuous improvement.

In the diagram below, the red vertical line represents work in process: the cumulative number of tickets accepted into the process but not yet completed. 

This information is useful because you can see how much work needs to be done at each level; for example how many tickets haven’t been started, how many are in progress, how many need to be tested, etc.

But even more important, you can see where your process developed bottlenecks. Those are at the places where a “boa constrictor” suddenly becomes fat. For example, in this diagram the “Deploy” layer goes from very thin to very thick between 12/11/26 and about 2012/12/07. It looks like something went wrong during this period and the imbalance in the process was only gradually worked out towards the end of the diagram.

Note that the cause of the problem may well be in the process step below the thick layer. In this diagram the bottleneck in the “Deploy” layer might have been caused by problems preparing new features for deployment, or by a constraint on actually deploying them and accepting them as “Fixed.” (If you “push” tickets, then the problem is likely to be in the fat layer; if you have a “pull” system it is probably in the lower or receiving layer).

The CFD makes it much easier to see when and where the bottlenecks started, so you can investigate the root causes and fix the underlying problems. 

In our next post we will look at cycle times and how to the CFD can help identify scope creep.

Cycle Times Warn You of Slowing Releases

One of our goals at Assembla is to help you release software more frequently. One of the best ways to accomplish this is to drive down the elapsed time between starting and completing individual tickets. If you can reduce ticket “cycle times” you can add value to the end product sooner, and you can cut down on the effort required to find and fix problems (developers are more likely to remember what they did yesterday than what they did last week). 

The CFD provides a great way to see if your ticket cycle times are improving – or to give you an early warning if they are deteriorating.

Cycle times are indicated by the horizontal lines in the diagram. These represent the average interval between starting work and completing a ticket. In the diagram below we can see that the cycle time has been growing, which is not great. 

But we can also look at the individual layers and get an idea of the underlying problems. In this diagram the cycle time for “In-progress” tickets was long early in the time period, then improved, while the cycle time for tickets in the “Deploy” category lengthened. The reasons need to be investigated (as discussed in the last post, the problem might be in the layer below), but the CFD tells you where to look.

Note: A good place to start investigating problems is the Stuck Tickets report, which is also available on the Metrics subtab. This shows you which tickets have not changed status in a specified time period. 

Spotting Scope Creep

WIP and cycle times are functions of the relationship between the arrival rate and the departure rate. If more tickets are flowing in than flowing out, then both WIP and cycle times will increase. That tends to slow down release cycles and hurt productivity.

The CFD helps you see how those factors are interacting. For example, if you have a steady departure rate, but you see the arrival rate increasing, then you might want to consider slowing the rate that you accept new tickets for the milestone. Forcing more tickets into the mix won’t make any more work come out the other end. In fact, increasing WIP and cycle times will probably reduce the number of tickets delivered in a given time period.

In a flow type of process you need to keep an eye on the size of the top (“New,” or “ToDo”) layer. If the layer is too small, then developers may not have a good choice of tickets to bring into the next layer (“In-Progress,” or “Design” or whatever). But if the layer gets too large, you may have tickets that never get worked on, or you may have a tendency to add tickets to the queue that simply can’t be delivered in a reasonable time.

If you have an iteration-based process like Scrum, then you need to watch for other patterns that indicate scope creep or overly aggressive commitments. For example, if you see a lot of tickets pushed into “Test” and out again at the end of a sprint, you might be short-changing QA and missing bugs.

Related Posts

Part I on this topic: The Cumulative Flow Diagram: Your Most Valuable Management Report?

You can see “ideal” Cumulative Flow Diagrams for Scrum, ScrumBan and Kanban processes in Andy Singleton’s blog post: Scrum + Kanban = ScrumBan, an Easy Scrum Upgrade.

Learn about other useful management reports in Assembla at: New Ticket Metrics – Reports that are actually useful.

We haven’t been blogging for a while, but that does not mean we haven’t been busy. As you have seen, one of the things we have been working on is rethinking how code is browsed and how to improve the experience for both developers and other team members.

Dig into your code with the redesigned Code Browser

• Browse the code faster with our ajax implementation of the source view
• Merge request, fork (Git-only) and compare controls are easier to find and use

What is your usual way of prototyping? Forget the file handoff and the email mess of sending those HTML prototypes. Collaboration with Designers is made easy in Assembla. Just check out the render button on any HTML document:

• render a file at any revision in Git, Subversion or Perforce
• get fully rendered HTML page - with CSS and JS

This makes the full-blown HTML prototype be only a commit away and you never lose it, because it is in your repository!

Learn more about collaboration here