On 9/25/2012, Assembla and Perforce presented a webinar titled "Beyond Scrum: Introducing Simple Scalable Agile Development." It is very clear that this is a hot topic with over 1,000 people registering for the webinar. For those that did not get a chance to register or attend, the video and slides are below. Enjoy. 

 View and download the slides.

Webinar Overview:

Scrum is the most popular Agile process, and aspects like the daily meeting are familiar to most developers and businesspeople. But it's not for everyone.

Scrum was designed for small collocated teams working on simple projects. Larger Scrum projects can experience hierarchical planning, integration nightmares, and inefficient use of resources.

In this webinar you'll see an Agile framework that avoids these problems by recognizing the concept that managing code is often easier than managing people.

Other Releated Resources from our Blog:

• Scrum + Kanban = ScrumBan, an Easy Scrum Upgrade
  
• Continuous Delivery and Scalable Agile - Find Out the Secret
• Intro to Scalable Agile: Scale Your Teams and Release More Frequently
• Combining Scrum, Kanban, and Scalable Agile Webinar [Video]

On September 25 Assembla and Perforce are presenting a new webinar: 

Beyond Scrum: Introducing Simple Scalable Agile Development

Scrum is the most popular Agile process, and aspects like the daily meeting are familiar to most developers and businesspeople. But it's not for everyone.

Scrum was designed for small collocated teams working on simple projects. Larger Scrum projects can experience hierarchical planning, integration nightmares, and inefficient use of resources.

In this webinar viewers will see...

• An Agile framework that avoids these problems by recognizing the concept that managing code is often easier than managing people 
• A demonstration of this framework that uses Assembla's hosted planning tools and Perforce repositories. 

Presented by:

Andy Singleton, CEO of Assembla, and Randy DeFauw, Technical Marketing Manager at Perforce

Tuesday, September 25 | 19:00 CEST | 1:00 pm EDT | noon CDT | 11:00 am MDT | 10:00 PDT

 

You can also try Perforce on Demand, hosted by Assembla here.

         

This article provides an introduction to Scalable Agile, a non-Scrum process that is designed to help you scale a development effort from 2 contributors to 2000 without abrupt transitions, work with diverse and distributed contributors, and release whenever you want.

Table of Contents:

Why do we need it?
Useful principles for the design of Scalable Agile
How we do it - the Scalable Agile Process Chart
Advantages of Scalable Agile
4 Key Technologies
Putting it together

Why do we need it?

When I talk to corporate people about agile software development, they are usually talking about "Scrum."  10 out of 12 of the software managers that we brought together for our Scalable Agile Design Group describe their process as Scrum or Scrum-like.  Here's a 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."  Here's a link to a picture.  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, all in one place, releasing at known intervals, Scrum can help you achieve the agile goal of frequent, high-quality releases.

If your development effort, like most, does not exactly meet the description of a "team of 5 to 10 people, all in one place, releasing at known intervals," Scrum will leave you with some problems.  If you have only two or three people, the cycle has too much overhead.  If you have more than ten people, you will need multiple teams, and you will need to make an effort to coordinate them for an iteration plan.  You won't be co-located.  Most modern development projects, and all big ones, include people from multiple locations.  As you get close to a release, you merge stuff together for testing, and there is never enough time for that.  If you run an online service, or you have a lot of components to update, you face pressure to release more frequently.

Most development efforts will face some of these issues.  Cloud development projects face most of these issues.  On Assembla projects, we always have all of these issues.

Problems cluster around two things that happen in a batch – iteration planning and testing for release.  These activities don't scale well.  Iteration planning is a problem for any distributed team or multi-team project that is not meeting in one place.  Test and release in a fixed time interval is a problem if your system is big, or if your developers are exceptionally productive.

So, one of our goals it so eliminate these batch activities and set up a continuous process that allows us to plan every day and release every day.  We want to relieve the stress that builds up around a fixed release schedule.  That goal is especially relevant in the age of cloud software development.  Our research shows that cloud and online product developers are very concerned with continuous integration and rapid release cycles.

Another goal is to include diverse types of contributors.  Training people to work together in self-managed Scrum teams is a laborious process.  If you have such a team, that's fantastic.  If not, if you are a lone hacker, or you work in a hierarchical organization, we still want you to be an effective contributor.

A related goal is to include contributors from any location.  Distributed work is a requirement for any modern project.

Finally, we want to scale.  The value of process and methodology is much greater for a large group, as getting efficient work from such a group is a difficult and expensive task.  An agile process should be designed to help us with that task.

"Scaling" doesn't only mean going to larger project sizes.  Most software projects are smaller than a cross-functional Scrum team.  An effective process for 2 or 3 people can be summed up as "prioritize and communicate."  For these groups, the transition to a Scrum process with "3 artifacts" and "3 rituals" can be harsh.  Shouldn't we instead try to bring easy and informal cooperation into larger groups?  A truly scalable agile process should provide some guidance to a team of 2, and allow 100 more contributors to join, without abrupt transitions.

Useful principles for the design of Scalable Agile

I applied some basic principles for managers interested in scaling any effort:

• Recognize reality.  For example, teams are distributed, specialists are shared, and projects will cost as much time and effort as they are worth, and not what you estimate or recommend.
• Let contributors decide what to do and get the resources they need.  Most management problems occur because managers have limited knowledge.  They just don't know as much as the people doing the work, and it is unreasonable to expect them (or expect yourself) to make a perfect project plan, or to know what each of 20 other contributors can do or should do.  21 people are smarter than one person.
• Expand the resource base.  Add new contributors when you need them.  Try to get everything on-demand.  The Internet is very large and it connects you to a lot of people and things that can help you.

We're going to start with what is basically a Kanban process.  Here is one of my articles with a picture of Scrum, Kanban, and a recommended variant I call "ScrumBan."  I try to remember three important things about Kanban:

1) People "pull" work.  This is a simple way to make sure that work never piles up in the wrong place, and it saves a lot of time and effort for managers who would otherwise have to figure out who to assign things to, and when.  See my discussion under "empower individual contributors."

2) It's a continuous process.  Instead of planning a batch of tasks, each contributor takes one task, works on it until it is finished, and then gets one new task.

3) It's based on a Lean principle which says that you should not keep "inventory."  In a software project, inventory is the stuff you worked on that isn't finished.  In principle, you should finish each task before you start a new one.  The software Kanban board takes care of this in a very simple way by limiting "Work in Progress", or WIP.  WIP is similar to a sprint backlog in Scrum.

Scalable agile adds specific recommendations which will help you with continuous delivery - releasing every day or whenever you want.  Scalable agile also provides a structure for including diverse types of contributors.

How we do it  - the Scalable Agile Process Chart

In a Scalable Agile process, you plan your release at the end, and not at the beginning.  You just skip all of the iteration planning and other batch processes, which is an immediate productivity booster.  People work at their own pace, which you measure for forecasting and incentive purposes.  Then, when you are ready to release, you take what is ready, and you release it.

Here is a chart that shows the process.

 

(1) We make a prioritized backlog of features, tasks, and bugs that you want to work on.  This is the same backlog you will use for Scrum or any other agile process.  The "product owner" selects a subset of items that we are ready to work on, which we call "Current" work.  "Current" is very similar to a sprint backlog, with the difference that you don't have estimate its size.

(2) Contributors grab tasks out of Current and start work.  They can grab a task of any size (tasks have very different sizes – that's one of the realities we need to recognize).  In keeping with Kanban principles, they should only grab tasks that they are sure they are going to work on it in the very near future, and they should never be allowed to hoard tasks just because they are experts in a particular subject.  We haven't specified what a "Contributor" means.  It could be a lone hacker, or the person in the next desk.  It could be an established high-performance Scrum team, which can grab a sprint backlog, and commit to delivering it on their normal sprint cycle. This process is 100% Scrum compatible.  A contributor could also be an outsourced team, or a big partner, that uses hierarchical management and grabs individual tasks.  They can all work with their own process as long as they plug in correctly at the next step.

3) Each contributor has a separate environment for building and testing.  You can do this step manually on developer workstations if you have a small team and a highly skilled tech lead or "maintainer".  However, this is normally the step where you pull out the high technology, such as automated tests and on-demand cloud based copies of your production environment.  You will also want to reorganize your QA professionals to serve as resources that can test on any of these environments.  This type of organization is a necessary (and probably sufficient) step toward releasing every day.  You can read about it in more detail in my article "Continuous Delivery and Scalable Agile - Find Out the Secret."

4) Contributors submit code (and other changes) for review and release.  There is a centralized release manager or release team, which has ultimate power at this stage.  The system should  be set up to handle changes in the form of specific merge requests (Assembla) / changes (Gerrit) / pull requests (Github), which can be reviewed and accepted or rejected.  This review process is usually used to put changes into the contributor test builds, and then again to move changes into the production release.  When a change makes it through both reviews, we assume that it is ready to release.

Advantages of Scalable Agile

It's faster.  It's continuous delivery.  We enable releases "on demand" by having multiple "on-demand" test environments and accepting changes when they are ready.

Statistically, we have found that smaller changes result in fewer bugs with smaller bug impact.

We make the process work for distributed groups by eliminating mass meetings and the requirement for mass consensus.  We do this with "the principle of pull" where contributors pull and contribute when ready, knowledgeable tech leads who can manage both code and people, and clear online visibility of all work.  This allows many discussions to take place asynchronously, or one-to-one.

We make the process scalable to an indefinite number of contributing individuals and teams by eliminating centralized iteration planning and centralized testing.

We open the door to many types of contributors, not just Scrum teams, or people trained in a particular process. At Assembla we like to think about "blended teams" that can include our tech-lead driven distributed teams, partners or outsourcers with hierarchically managed teams, shared functional specialists (like design and ops), lone hackers, and individual experts.  It's Scrum compatible!  Established Scrum teams can grab a sprint backlog, and work as contributors with no process change.

If we are bringing in contributors we don't know, how do we control them?  We aren't necessarily managing them.  They are managing themselves in unknown ways!  Will our project fly out of control?  Actually, we have two very strong points of control.  First, we control the backlog, so we control what people work on.  Second, we control the code changes and other changes that we accept.  So, we have an absolute control over what goes in the product.  The review and acceptance process actually gives us a much stronger way to enforce standards for quality, architecture, and testing than we get in most other methodologies.  Finally, the continuous process prevents contributors from causing problems if they get stuck.  Work from other contributors will just flow around them.

4 Key Technologies

There are modern projects, mostly cloud-based, that use variations on the Scalable Agile process that I describe here.  However, it is a recent development, because it is dependent on four key technologies, and some of those technologies are new.

1) Ticketing and task management

In its simplest form, the list of tasks is a stack of cards, or post-it notes, or lines in a spreadsheet.  The quaint stack of cards is idealized as a good focal point for Scrum or Kanban teams, but it's not what we want for scalable agile.  I'm going to describe it as a technology because a distributed team always has an online ticket or issue list that is globally visible.  It may contain some of the following features:

• Customers and stakeholders adding requests
• Ways to organize large backlogs
• Requirements and mockups added with increasing detail
• Ongoing real-time discussion and collaboration
• Workflow steps, including testing
• "Traceability" linking a ticket to related code commits, tests, and deployments

2) Global team collaboration and management

Internet workspaces for distributed teams (like Assembla) and related management tools.

3) On-demand build and test systems

Continous delivery requires separate integration test environments for each contributor, so you can test each change.  To make it scalable, you want to satisfy "the principle of pull" that a contributor should be able to get what he needs without going through some centralized system for building and testing.  Fortunately, there are now many suppliers of on-demand cloud servers. 

You will want to invest in automated testing and continuous integration.  Test and integration environments are specialized for each project.  Fortunately, there are also many new systems and platforms for automated testing, continuous integration, and automated deployment.

4) Code management and merge

Source code management and code review tools are an essential part of the process.  New merge workflows have given a big boost to the type of continuous delivery process that I describe here.  Code management tools were neglected in the last generation of agile methodologies, which focused on interactions between people.  However, the reality is that managing code is a lot easier than managing people.  It's difficult to personally manage 20 developers, and it gets more difficult if they are in 20 time zones, but you can scale a code contribution and review system to include thousands of contributors.

Putting it together

The Assembla product will provide tools to help you run "Scalable Agile" and other continuous delivery processes.  Here is an overview of relevant new and planned features:

Continuous flow for tasks:  Traditionally, the Assembla ticket system organized tickets into multiple "milestones," or iterations.  In the new Planner view, there is only one Backlog and one Current container (WIP or Sprint Backlog), so work can flow through Current in a continuous process.  You can see Current on the cardwall, a traditional Kanban view.  This week we will put a continuous flow diagram on the metrics page to provide a measure of progress that is useful in the continuous flow system.

Large backlog management (unreleased):  We found that when we put everything in one backlog, the list was too long to visualize, and we needed some new tools. We are compressing it with epics, stories, and tasks.  We are also testing in filtered views, so that you can see only the tasks that apply to your team or epic on the Planner and Cardwall.

Multi-team task management (unreleased):  You will be able to throw a filtered view of tickets out into a related "child space" for a new team to work on.  You will also be able to report on the progress of the complete backlog, or any contributor or team.

Merge requests / code review:  A few months ago, we released advanced merge requests for Git.  They allow code contributors to package up a set of changes, and submit them for code review and merge.  We have used and refined this feature as we moved our release interval from 2 times per month to many times per day.  We have improved the integration with tickets so that changes can move from idea to release in one smooth process.  We added "tickets affected" by a marge request- a type of automated release note makes my life much better - and in the new ticket layout, a view of merge requests related to a ticket.  We have implemented merge requests for Perforce, and we have been working with the Perforce team on their own highly scalable form of continuous delivery.  We are currently working on merge requests for Subversion, which will fit with the "symmetric merge" improvements coming in Subversion 1.8 later this year.

Continuous integration plugins for Jenkins:  Jenkins can help you build and test every proposed change.  These plugins help you configure Jenkins to run continuous integration with tests for any merge requests, authenticate using Assembla accounts, and even include it as a space tab.

Professional services, under the Studios label: These services range from basic DevOps services, to setting up scripts for continuous integration and continuous delivery, through full management and project delivery.

Talent: You should be able to expand with new individuals and teams.  We're working to make it easier.

These simple charts show how we can combine Scrum (with periodic releases) and Kanban (with very frequent releases) and combine them in a “ScrumBan” process that has periodic releases, and is an improvement on the normal Scrum process.  It's better for distributed teams, and closer to the way many of them actually work now.  It's a simple step toward the fully scalable process that we will propose later.

Scrum

Here’s what a Scrum process looks like in a “continuous flow diagram:”

You select your current work as a “Sprint backlog.”  Then, you burn up the completed  tasks until (hopefully) you are ready to release.

In actuality, you don’t usually see sprints that match this chart.  Tasks get added near the beginning, and removed near the end.  You can get a lot of bottlenecks when you get near the end of a release.

Kanban

In a Kanban process, you select a list of "Work In Progress (WIP)."  As you finish one task from this list, you select a new task.  This continues without stopping at special release points.

Note that WIP in a Kanban process is usually not expressed in terms of size or points.  This is because Kanban uses a “lean” philosophy, where the idea is to avoid having tasks that are waiting around for someone to work on them. Kanban limits the number of tasks, regardless of size, so that each current task has someone that is working on it.  A task that will take 1 day and a task that takes 9 days require the same amount of attention today.  In contrast, a Scrum team will consider a task that takes 9 days to be similar in size to 9 tasks that take one day, sequentially.  The Kanban WIP limit is a simple and effective way to ensure that each current task is finished as rapidly as possible, it doesn’t require estimating, and it provides a natural way to work on tasks that take longer than one iteration.

The Kanban process has a lot of advantages, and it is great if you update an online service with daily releases.  However, most teams can’t release every day.  They send things to the appstore once per month, or have enterprise clients that will accept quarterly updates, or burn CD’s or PROMS every year.  They need periodic releases that are stable.  For those teams, we suggest the ScrumBan process.

ScrumBan

In our idealized ScrumBan process, you start your sprint with the normal Kanban process.  When you get closer to the end of the sprint, you do some things to get ready for a release which I have labeled here with my own vocabulary.

Triage:  Find tasks that you are not going to finish by release time, and get rid of them by moving them to a future release.  This is actually an important part of any process that delivers releases at a fixed time.  I have diagrammed all of the triage at one time, but  you should  actually do it whenever you find a task that is not likely to be  completed in time.

Feature Freeze: Stop adding new tasks to the list of current work.  Then, you  can stabilize your release by burning down the list of incomplete tasks and problems (shown here as burning up the closed tasks).

Stabilization: Finish or remove tasks, and fix problems, until you have a stable release.  The cumulative flow diagram converges to the end of the iteration, One hint for the stabilization phase is to not allow developers to move on to new tasks until the release is finished.  This creates psychological pressure to finish a good release.

I find that the stabilization process often takes about 1/3 of the release cycle.  A good rule of thumb for your first release cycle is to do an aggressive triage and  a feature freeze by the  time  you have used up 2/3 of your  time to release.  If you can stabilize in a shorter time, you might be ready for a straight Kanban process, using this testing secret.

If you are using Scrum sprints, I recommend that you try this Scrumban process for your next sprint.   You get two immediate advantages:

1) You don’t have to do estimating and sprint planning.  Hooray!  You get an extra day for design and programming.  If you have one or more distributed teams (like the Constant Contact project shown below), you avoid the logistical challenges of agreeing on a sprint plan.

2) You can add bug fixes at any time.  In the idealized Scrum process, it’s annoying how bug fixes go into a separate work queue.

Compare the ideal Scrumban diagram to this real continuous flow diagram presented by Gil Irrizarry of Constant Contact.

Last week Assembla posted a bunch of “agile” words on our home page.  I resisted doing this for years, because the word “agile” doesn’t necessarily have a good feel to it.  It’s a refuge for a lot of organizations and people that aren’t very agile.  The original idea is great.  It stands for releasing software frequently, with short lags for the implementation of valuable new features and ideas. The productivity of software development increases every year, and in theory you could use the word "agile" to describe many of the things that are light and bright, great and good, fast and fun about our new world.  But, if we want to use the word “agile” for this, we have to burn off the stink of stagnation that surrounds the old “agile.” So, here are seven things I hate about “agile.”

Old people: Agile has the smell of death on it.   If you go to an “agile” event you will see few people under the age of 40 and many over 50. These attendees are on average much older than the average age of programmers, and often older than the people running today’s hot software companies.  Why aren’t more younger people grasping at agile straws?

Stagnation: "My development guys don't think 'agile' is interesting," reported the president of a major software tools vendor, sitting among cubes covered with agile task cards. The modern agile movement is chained to an aging orthodoxy based around Scrum. What's new in Scrum this decade? Most organizations which use the word "agile" are using the word precisely because they are NOT agile, and want to be more agile. This has created a demand for a whole industry of people who try to push "agile" further into non-agile organizations amplifying the link between "agile" and really not agile. Making matters worse, they are seen as management stooges attempting "process change," which is a boondoggle that nobody wants applied to his real-world job. Most victims would rather go to the dentist.

Imposing values:  Read the agile manifesto here and think about whether this is a good tool to get a diverse group of people to work together.  We value this.  We value that.  I don’t think values have anything to do with productivity or collaboration.  The Americans and the Russians didn’t share many values, but they teamed up into a mighty fighting force during WWII because they shared a goal.  The people that make an iPhone make a beautiful product efficiently.  They live in the US, Japan, China, and many other countries.  They live in mansions, boats, and dormitories.  Do they share values?  I doubt it.  They don’t have to.  They share a supply chain.  Productivity is comes from shared GOALS, not shared values, and from a process that is structured to allow people to do their separate jobs, and work together.  As long as they share a goal and have room to work, they can ignore each other’s values.  Team productivity research shows that a shared end goal is the best predictor of high performance teams.  If you are going to insist on shared values, you are going to have a very short supply chain – probably just 5 or 10 people sitting around a campfire singing Kumbaya.  That sounds like a Scrum team!  I’m going global.  Get the hell out of my values.  And while you are at it, let me cram what I value down your throat - code that we can release.

Scrum Master roles:  Some scrum coaches rank among the nicest and most thoughtful people that I ever met.  However, the general concept is very suspicious.   A scrum master is not supposed to lead the team, code, or take responsibility for deliverables.  What do they do?  Massage?  Get a real job.  We use tech leads, who can understand the code that flies around a distributed team, and take responsibility for deliverables. I shed more light on this back in Novemeber with a popular post - Tech Leads will Rule the World. 

Estimating:  A good, detailed estimate with task breakdowns is very reassuring if you are using it to make a budget decision or a go/no-go decision.  If you already know what you want to do (eg the top stuff on your prioritized backlog),  then estimating is a waste of time.  It reduces productivity by wasting time.  That’s true in a startup and it is also apparently true for the bigger projects in our “Scalable Agile Design Group” survey.  Our analyst talked to 12 of these project leaders and came back with this summary:

Some Agile textbooks recommend estimate development times for tasks, then measuring actual results against estimates. But members of this group were cautious about making estimates, and downright opposed to evaluating people and groups based on actual versus estimate comparisons.  Most managers expressed one or more of these views:

• Estimates of software tasks are inherently unreliable.
• The benefits of estimates are outweighed by the time required to make them.
• Most developers won’t take the time to enter actual hours.
• Measuring people against estimates sends the wrong signals and will distract people from being flexible and innovating.
• Measuring people based on estimates causes them to game the system.

Pair programming:  Great for vendors, bad for customers.  Pair programming is like those girls that go to the restaurant bathroom together.  What are they doing?  If you are a vendor selling “pairs”, you have an awesome situation where you can charge twice as much, and you can easily churn guys on and off the pairs, one at a time, to steal talent for turnover or new projects.  If you are customer, you pay twice as much and you get churn.  I recommend a more efficient alternative – review pairs.  Person A and person B use a code review system to review each other’s code before release.  You get the same benefit without the neck cramp and the BS.

Scrum reality warp:  Let’s look at a few of the fantastical things that scrum advocates believe should be true about a Scrum team.

• According to the Scrum manuals, development teams should be co-located (everyone in the same place for daily discussion).  Where are the foosball tables that these guys are crowding around for their daily standup?  I haven’t seen a fully co-located team in years. Even if they are co-located in theory, there is always someone who stayed home or moved to Vermont.
• Self-contained, cross functional teams.  In this world, you have a full-time person on your team for every function – design, database, etc.  I love the idea that a team can deliver a complete feature end to end.  However, reserving talent for one team isn’t a practical way to do it.
• Teams with the same capacity every week.  People don’t move to new projects, get hired and trained, or even move over to  help other teams  that are further behind.  Apparently that would be idiotic, because you would get work done, but you would screw up your precious velocity calculation.
• No bugs.  You plan your next iteration, and then you don’t get any extra work because your last release has no bugs.

I was at an event where Alex Brown, COO of Scrum, Inc. was talking about his work, and when someone said “that doesn’t sound like Scrum,” he said “We’re a Scrum company, so we call everything Scrum.”  We can all recognize reality and lighten up.

We're going to be calling our stuff "Scalable Agile".  If you are interested in new solutions to some of the issues listed above, please follow this blog over the next few weeks.

The Closed column in the planner now gives you an accurate view of what happened and how fast you are moving.

To look at these changes, select "Show closed tickets" in the Current column. This will show you the Closed column, with recently closed tickets sorted in the order they were closed. That's what happened.

The fun new feature is velocity - a measure of the tickets that you closed recently.  You'll see a velocity number in the header. This is the number of tickets or points (if you use point estimating) closed in the last week and an average of the last four weeks.

Select the link labeled "View historical velocity here" to pop up a bar chart (below) showing tickets or points completed in each of the last  four weeks.

Why is this important?

The recently closed tickets list answers questions about what you have been doing, and gives you a place to check on tasks that disappeared from the Current list.  Remember to celebrate when you finish something good.

You can use the average velocity to set your capacity for an iteration.  Your capacity is roughly your average velocity, multiplied it by the number of weeks in an iteration.  You can enter this in the red capacity box on top of the Current column.

If you are running an iterative process, remember to use the "Close Iteration" button at the end of each iteration.  This will move the closed tickets out of Current into a historical milestone, and make room for the new iteration.

You can use the chart to see variations in velocity each week.  The variation should match your intuitive feeling about what happened during the week.  If it does not, you can investigate.

When we first introduced the Agile Planner, you asked for a free version and we promised to deliver. Here it is, a free Agile Planner configuration.

Planner works with three columns on one page.  Use “New” to collect feature requests, tasks, and bug reports. Then, sort them into a prioritized “Backlog” so that you work on the most important stuff first. Then you move tasks to “Current” where you can assign tasks, discuss, share screenshots, and eventually move them “Closed” when a task is complete. Read these instructions to learn how to run an iterative (Scrum style) or continuous (Kanban style) project in just a few minutes.

Here is a video of me getting started:

Why are we offering a free Agile Planner?

We want to make your life easier by making our product simpler. The Agile Planner is simple, works immediately, and the free version has no configuration options. Is this a benefit or a bug? You decide. Personally, I have started using the Planner almost exclusively when organizing projects with partners.

This freemium offer is also a good way for us to find new customers for our oter tools. Many current customers found us through our simple/single/free Subversion and Git repository tools. Now we can help people get started with lightweight agile task management.  We can work with you to build distributed agile teams, and finally, run scalable agile development with multiple teams.

New features:

We recently released some new features, and many other upgrades are planned or in development. For example, we are testing a mobile app, and we are testing an all-new ticket layout that will provide all of today’s features in a more usable format.

How to get started:

Create a free Agile Planner configuration in seconds.  It's free for up to 4 users and unlimited tasks.  If you would like to try our advanced tools, click on the upgrade tab of the free space and upgrade to a 30-day trial.

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.

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.