About six months ago, we started working internally on our "beyond Scrum" campaign to improve agile software development so that it works in a cloud-based world. As noted in my article, 7 Things I Hate About Agile, I don’t agree with Scrum, the dominant agile methodology. I was called everything from "ignorant youngster" to “bitter old man” to a “Moron with a capital M.” However, the response was big. 50,000 people read the article. 1200 signed up for a “Beyond Scrum” webinar that we did with Perforce. It’s clear that a lot of people are ready to move on to the next step.

Here is our roadmap for the positive steps beyond Scrum.

In moving our own teams and development process along this path, we were to increase our release frequency from twice a month to almost 60 releases in September - all while fixing issues faster, releasing more features, and overall happier team members. It worked!

Let’s look at this roadmap in more detail.

Distributed Teams and Scrumban

Why?

Because modern software teams really are distributed around the world. Once you accept that fact, your project will run much more smoothly at any scale bigger than one person, and you will find the people you need.

A simple first step is a Scrumban process that works with co-located and distributed teams. Scrumban will save you precious time by removing upfront release planning and allow your sprints to be more flexible for bugs/issues, chaging requirements, new features, etc.

Key Principles

People work where they are, which is usually distributed

Unite the team with strong social features and activity stream

Tasks and code are shared online

Team members pull one task at a time. Manage WIP (work in process)

At the end of the iteration, freeze new tasks and stabilize what is ready

Release on schedule

Assembla Product Features

This could be a really long list. Assembla Workspaces was designed to support distributed teams. Workspaces provide a place to create, plan, and manage tasks, share code (Subversion and Git and Perforce), and collaborate on project specs/requirements. We find that a key driver of team performance is the activity stream, which allows you to see what other team members are doing, and we have enhanced this with popular social features like @mentions.

Continuous Delivery

Why?

Continuous delivery is the art of releasing software whenever you have a valid change, often many times per day. It’s a natural goal for online services that are centrally deployed and updated. If your product gets released less frequently, you can still run continuous delivery in the development group.

1) It's hot

2) Moving to multiple releases per day resulted in big improvements for us, and we’d like to help more people get the same benefits. It dramatically reduces release planning and release related stress. You can do more because each task takes the right amount of time. It simplifies the interactions between teams and team members. And, it’s faster. If your competitor is running continuous delivery, you will eventually have to do it, or be overrun. It also helps with scaling, since it removes the big meetings for iteration and release planning. As we hear more about what is happening in Silicon Valley, we are becoming convinced that continuous delivery might be the only effective way to organize a big agile effort.

When I first heard about , I thought it was crazy, assuming that every release of a serious product needs testing phase. When we started studying it, we found a few specific tactics that will move any project to continuous delivery.

Key Principles

Multiple test environments, on-demand, or one for each contributor or contributing team

Continuous delivery requires code-related features to support multiple test environments, like the merge request workflow, various types of continuous integration, and the new SSH build tool. It also requires a new Kanban style approach to task management. We’ve redesigned our ticket workflow to fit.

Agile Planner and virtual Cardwall

Merge requests with code review

Cumulative flow diagram and other metrics to measure velocity and throughput

We have also fired up some services that are not related to the product. We are working with customers that need help with consulting and continuous integration, build and test scripts, and other DevOps stuff. We hope that we can help them get to the next step with whatever tools and process they already have.

Scaling

Why?

Scaling to get more development done, faster, with bigger teams, is the most expensive problem in software. We can use Internet technology to make it less expensive and much less painful. We have found tactics for working with globally distributed teams, breaking one backlog down into multiple teams, and adding and evaluating teams. We can help them work together by removing the big meetings for iteration planning, dependency planning, and release planning so each team can work at full velocity on its own schedule. If necessary, you can go big – big like projects we studied at Facebook and Google Android. At smaller scale we can use the same simple mechanisms to scale up AND make projects more agile.

Key Principles

Eliminate batch processes and big meetings

Add people or complete teams

Distribute tasks from a shared backlog

Evaluate and report on contributors

Assembla Product Features

We built Assembla Portfolio specifically for companies that want to scale and make large projects more agile, and we are making major enhancements to it.

Yes, automated tests with continuous integration are very important for continuous delivery. You will need to run automated tests in an environment that matches your development platform. Assembla doesn't try to standardize that. However, we are making it easier to run the tests at the right time, with these features: * SSH build tool - set it to run test or deploy commands after various kinds of commit events, and save the results. * Jenkins authentication plugi, which makes it easy to attach a Jenkins server to Assembla to run your automated tests. Jenkins is a popular continuous integration server that we use at Assembla. The Jenkins plugins will be open source, so you can adapt them to other platforms and CI servers * Jenkins plugin to run tests and vote on merge requests. Ideally, you want the CI server to look at every change. This plugin tests every change that you submit as a merge request. It's a workflow that is popular in the Gerrit community. It's open source and it shows how to use our API and SCM branching for automated testing.

At Assembla, Jenkins runs in a "custom tab". We'll be documenting the complete configuration. We'll also provide some recommendations for cloud hosts that work with Jenkins and various development platforms.