We use a lot of the Scrum process in our own development. Scrum is a good way to get to the “release early, release often” tactics that make you agile. However, it's not the last word.  So what is coming up next? This article will look at three techniques that can make an agile process more scalable and goal-oriented.

1) Technical leads

At Assembla, don't use Scrum Masters.  We use "Technical Leads".  A scrum master is responsible for non-technical parts of the scrum development process, guiding the team in improving the process, increasing team participation, and getting around obstacles and missing resources.  The scrum master role makes sense when you see the scrum master in a room with the rest of the team, one among equals, and “not the leader of the team, as the team is self organizing”.   This is a utopian vision, except for one unanswered question: How screwed up is an organization that needs to employ someone who does not code, and does not lead, and only clears away procedural problems?

In a distributed team, the scrum master role starts to look irrelevant.  Every member of a distributed team is in front of a computer, looking at actual tasks and software.   A technical lead is a coder as well as a manger and helper.  He is focused on the output, not the process.  He drives the process of converting ideas, to architecture, to tickets, to code.  And, he is clearly part of a management hierarchy.

2) Code Contribution

A lot of innovation in development has been in what I call “code contribution workflow”, which is closely tied to the evolution of code repositories or “version control systems”. I have seen four steps in this evolution.

Lock: Years ago, developers used to copy a part of the code base to work on, and formally or informally lock it, so that other developers wouldn't work on that part.  The early version control systems had “lock” operations to support this.

Merge: The next development was merging.  Developers could work in parallel on the code, and they could “commit” code whenever it was ready, but if they were committing a file that someone else had also changed, they needed to merge.  The next generation of version control systems had better support for this merge process, and largely ignored locking.  This commit and merge process enabled faster development because you weren't always waiting for someone else to finish. However, it created a new problem.  If you have enough developers making enough commits, they tend to commit errors or conflicts, and you get broken builds.  So, you limit the number of people who can commit, creating a new scaling bottleneck.

Pull: This motivated to the development of distributed version control systems like git, where developers can commit, merge, and test in their own repositories or branches.  A technical lead or “maintainer” can then pull the changes, test them, and commit them to a master branch.  The pull process greatly expands the pool of potential contributors and the effectiveness of open source development.  However, it depends on the capacity of the maintainer to pull and test code.  If you have a big commercial project, you need more capacity.

Review and Accept:  In the next wave, the maintainer will not be a bottleneck.  When developers post a changeset, it will go through automated tests, and gather votes from code reviewers.  If it passes all tests and gets enough votes, it gets accepted and merged into the master branch.  This process is scalable because you can have many people that are authorized to vote and and approve code.  There is a system that does exactly this, called Gerrit.  It was developed to accept and review contributions for Android system development.

Code contribution workflow is “separate but equal” when compared with project management processes like scrum.  They can work together, or separately.  You can apply any of these code contribution techniques to deliver code in a traditional scrum process.  The team can “commit” to a set of stories, and then run the code contribution process to implement  them.  However, you can also run the process with no commitment.  Developers take stories roughly in priority order, and they contribute when code is ready.  Release planning can be done at the end of the process, when you decide what to contributions to accept, rather than at the beginning, when you commit to implement stories.  If your acceptance process is good enough to leave you with release quality software, you can even skip the release planning.  So, code contribution doesn't need to run in a batch, which is very convenient if you want to run a continuous process like ...

3) Kanban

The thing that I like most about Scrum is releases.  The thing that I like least about scrum is batch planning.  There is a lot of planning and design at the beginning of an iteration.  This is a bottleneck to productivity, because it means that you only have small windows where you are doing this  type of  planning and design.  And, is there really anyone, anywhere, that doesn't change priorities during an iteration?  Planning and design are important, and you should be able to do them at any time, and you should be doing them continuously.

Fortunately, there is an emerging agile methodology called Kanban that does run as a continuous process.  The principles of Kanban have been around for longer than the principles of scrum, so it is risky to call this “emerging”.  However, we are going to present it as a new idea because Kanban is enjoying a surge of popularity and evolution as a software development methodology.

The basic idea of Kanban is that you are continually moving tasks or stories from idea to deployment in a series of steps:  For example, a web applcation might have steps for mockup, coding, testing, deployment.  Your goal is to move tasks through to deployment as quickly as possible, without letting them get stuck.   So, you measure the number of tasks at each stage, and the amount of  time  they are spending at each stage, to make sure that they are not piling up in one place.  This directly solves some common problems, such as tasks piling up for testing and rework just before a release.  If that happens, you see the extra tasks in the testing phase, and you adjust your team capacity by asking developers to move to the testing team.  It runs as a continuous process, so you are always doing planning and design, increasing your capacity.

Putting these pieces together so that they work smoothly will take some study, some practice, and some trial and error.  It might even look silly the first time...