How does Assembla do Agile?

Sergiy Golub on August 15, 2016


Given that we are a project management software for developers, we constantly get questions from Assembla users on how to do Agile - what does it mean to do Agile? I’d like to provide insight on how the Assembla development and engineering team does Agile.

Our Process — Hybrid Approach

We currently use "Scrumban" and Assembla. We use Assembla as an operations tool for the planning and execution of all product delivery - from one year goals to hourly tasks. Our process is the marriage of two agile process' - Kanban and SCRUM. Both have their merits but the intersection of the two really amplify efficiency yet keep predictability high. Pure Kanban has its challenges with a geo-diverse team when it comes to cadence and sales/marketing campaigns for a high growth SaaS business.

Jacek, our CTO, agreed to move to this hybrid approach based on our own experiences. We’ve e run many teams using many different models and we decided to marry the two approaches to create the optimal product development process. With our small team we get a lot done quickly and still maintain cadence. I’d like to share with you on how we do it.


                       "Goals + Ideas"                                              "Kanban execution"

Let's do a quick recap on Agile before we get into the details of Kanban or SCRUM.

Once a software team leaves the familiarity of waterfall and other traditional project management styles they often ask "how do I go about doing Agile?" Fortunately, Agile development uses four delivery vehicles to bring consistency to any agile project: user stories, sprints, epics, and versions. By working with these, teams are able to organize their work such that they can respond to customer feedback and change from the original plan of the project without feeling like the floor is breaking underneath them.


The ability to change and pivot future plans based on current insights is a hallmark of agility. In fact, what teams are learning is that unexpected situation are always part of life - a business plan typically doesn't survive its first rounds. Jacek, our CTO, once said

"Agile is like Security - it's not about prevention anymore - that's dead, it's really about coming to grips with reality - they will get in - the reality is all about how fast and effective you are at detecting and dealing with problems as they arise in real-time."

This adage holds true for modern software development and is particularly important for SaaS based businesses.

Let's take a look into Agile's component vehicles a bit closer.

Info Gathering: Stories

In an Agile model, user stories are the smallest units of work. The goal of a user story is to deliver a particular value back to the customer. Note that "customers" don't have to be external end users, they can also be internal stakeholders within your company who depend on your team. User stories are a few sentences in simple language that outline the desired outcome.They don't go into detailed requirements.

User stories are often written using the following:

As a <user>, I want to <goal> so that I get <benefit>

Let's use a SaaS app as a simple example to create a user story.

As a user, I want to be able to login using my gmail account so I don't have to manage another set of credentials.

User stories are typically defined by the product owner, and the full product team collectively decide on the more detailed requirements. These are the granular pieces of work that help define the implementation items for the story and the upcoming milestone. In the above example, there are a set of tasks required to make the login feature work: database changes, new backend code, as well as new UI or UX pieces. These tasks should be fleshed out during estimation of the user story and linked in the team's issue tracker. That's precisely what we do at Assembla for every single piece of value we push out to our users.

Development Cadence: Sprints

In SCRUM, teams forecast to complete a set of user stories during a fixed time period, known as a sprint. Sprints are usually one, two, or four weeks long. It is up to the team to determine the duration of a sprint - we recommend starting with two weeks. That's long enough to get something accomplished, but not so long that the team isn't getting regular feedback. Once a cadence is determined, the team perpetually operates on that cadence. Fixed length sprints reinforce estimation skills and predict the future velocity for the team as they work through the backlog.

Two important things to understand about sprints:

  1. Once a team forecasts a set of user stories for the sprint, and the sprint is started, somebody has to be is in charge of fending off changes to the user stories. Sometimes these are called SCRUM master roles. This role keeps the team focused and combats "scope creep" (when a team adds work to the sprint after the sprint starts). Adding work mid-sprint compromises the team's ability to forecast and estimate accurately. These compromises are a double edged sword - be careful not to be too pedantic as I have seen compromises be rejected ignoring that something is just not ready yet to be completed.
  2. At the end of each sprint, the team is required to deliver a working piece of software. In SCRUM, that's called a potentially shippable increment (PSI). The product owner decides when the PSI gets released to customers, but the work should be complete enough to be suitable for release at the end of the sprint. Again, pay careful attention to how your team and your customers work - sticking to a totally fixed model may cause more pain than gain.

A great tool for any scrum team are burndown charts and velocity charts.


Above all, these charts provide supporting data in discussions about the progress of a sprint. Sprints are only a part of the SCRUM model. Kanban, by contrast, work on the next item in the backlog as capacity permits. Key word is capacity. No forecasting is required. At Assembla we see power in a hybrid approach because in our opinion forecasting is absolutely critical when doing product development in a high growth SaaS business.

We're Going Up: Epics

Epics are significantly larger chunks of work. Epics are feature-level work that encompasses lots of user stories. Using the above example, an epic might be the entire login system.

Unlike sprints, scope change in epics is a natural aspect of agile development. Epics are almost always delivered over a set of sprints or milestones. As a team learns more about an epic through development and customer feedback, user stories will be added and removed to optimize the team's release time. This is the freedom a product owner gets with an agile model, because they can focus on ensuring the team is working on the most pressing things.

Velocity charts can also be used to visualize epics, which keep teams motivated and the executive stakeholders informed. A good epic chart shows the agile nature of development. It's clear how the team is performing. Having data points available to the team in a visual manner keeps everyone on the same page.

Feature "flags" are an effective way to develop larger epics because they let new code hide behind an on/off switch during development. Feature flagging gives the development team the ability to ship the code for an epic and let it be part of the production application, but not make it visible until it is fully implemented. At Assembla we use feature flags very heavily as we typically preview new versions of software to internal stakeholders or BETA customer quorum's weeks ahead of public release to ensure the end product is that much better for our total customer base.

Getting Fancy: Versions

Versions are the releases of software out to customers. Remember, at the end of each sprint the team should be able to ship software to customers. Versions are the curated changes the product owner actually ships.

In SCRUM, versions are often developed over a set of sprints, much like epics. Good product owners may choose to deliver an epic over several versions. An epic does not have to be fully contained within a version. By delivering an epic over several versions, the product owner can learn how the market is responding to that epic and make calculated decisions about its future direction rather than doing one giant release.

At Assembla we think of Versions as really a tag of what epics we are shipping in a given state. As we release and collect more feedback we will "re-ship" the same epics but with improvements based on new stories being added to the epics - hence a new "version".

Looking at our login scenario above, a product owner may structure the release strategy as follows:

  • Version 1: basic login, logout, password management with gmail integration
  • Version 2: other login methods (Slack or Twitter)
  • Version 3: saving preferences

Releasing software is one of the most exciting things for a team. Ensuring that release is an easy process is KEY. The KEY to this automation. At Assembla we have a fully automated deployment process that marries Assembla, Jenkins, Chef, AWS and Slack to push product out in under 10 minutes. Post-deployment with use other tools such as New Relic, AWS, Chartio and Errbit to monitoring usage, performance among other topics.


Kanban is another model used to implement agile. From the book:

"Back in the 1940s, Toyota optimized its engineering process by modeling it after how supermarkets stock shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match with consumption patterns, the supermarket gains significant efficiency in inventory management and optimizing for the customer. When Toyota brought that idea to its factory floors, teams (such as the team that attaches the doors to the car's frame) would deliver a card, or "kanban", to each other (say, to the team that assembles the doors) to signal that they have excess capacity and are ready to pull more materials. Although the signaling technology has evolved, this system is still at the core of "just in time" manufacturing today."

Kanban does the same for software teams. By matching the amount of work in process to the team's capacity, kanban gives teams more flexible planning options, faster output, clear focus, and transparency throughout the development cycle.

Planning Must Consider Curveballs

A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to re-prioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in SCRUM.

Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. it's always a good practice to confirm changes with the engineering team to ensure there are no surprises. Kanban relies on a highly collaborative and real-time product owner model and may not fit every company. Isolated micro-service teams working closely together may get by using pure Kanban but typically it has too little control and too much reliance on the product owner to really effective in a high growth SaaS business.

Minimize Cycle Time

Cycle time is a key metric for Kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow – from the moment work starts to the moment it ships. By optimizing cycle time, the team confidently forecast the delivery of future work.

Overlapping skill sets lead to smaller cycle times. When only one person holds a skill set, that person becomes a bottleneck in the workflow. If you have read the book The Phoenix Project, we call these folks "Brent". To help teams employ basic best practices like code review and mentoring help to spread knowledge. Shared skills mean that team members can take on heterogeneous work, which further optimizes cycle time. It also means that if there is a backup of work, the entire team can swarm on it to get the process flowing smoothly again. For instance, testing isn't only done by QA engineers. Developers pitch in too. At Assembla we keep a sharp eye on our cycle times using reports.


In a Kanban model, it's the entire team's responsibility to ensure work is moving smoothly through the process.

Focus Brings Efficiency

Multitasking kills efficiency. The more work items in flight at any given time, the more "context switching", which hinders completion. That's why a key tenant of kanban is to limit the amount of work in progress (WIP). WIP limits highlight bottlenecks and backups in the team's process due to lack of focus, people, or skill sets.

For example, a typical software team might have four workflow states: to do, in progress, code review, and done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's good reason for it: code that hasn't been reviewed not only hasn't shipped yet, but may need significant re-work before it is ready to ship. So it's important to take action on code reviews right away, and setting a WIP limit helps the team hold themselves accountable to that. It forces the team to knock out those reviews before pulling in new work. At Assembla we have six because we have learned over the years that two extra states improves quality and visibility.


Making Metrics Fun and Visual

One of Kanban's core values is continuous improvement. But how do teams ensure they're continuing to improve? One word: visuals. When a team can see data, it's easier to spot bottlenecks in the process. Two common reports kanban teams use are cycle time and cumulative flow diagrams. The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop is an indicator of success.


A cumulative flow diagram shows the number of issues in each state. The team can easily spot blockages by seeing the number of issues increase in any given state. Issues in intermediate states such as "In Progress" or "In Review" are not yet shipped to customers, and a blockage in these states can increase the likelihood of massive integration conflicts when the work does get merged upstream. Humans operate best with visuals - which was one of the hallmarks of Kanban in general - map it to an intuitive human process.

Moving toward continuous delivery

We know that continuous integration (CI) - the practice of building and validating code incrementally throughout the day – is essential for maintaining quality. Now let's meet CI's older, more sophisticated cousin: continuous delivery (CD). What is it? Well it is the practice of releasing work to customers frequently – daily or even hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value.

The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on exactly that: optimizing the flow of work out to customers. At Assembla we release between 5-15 times a day - more during major version releases where we are iterating on feedback in real-time.

Stacking them up

Kanban and Scrum share some of the same concepts but have very different approaches. They should not be confused with one another. Scrumban on the other hand, hand picks merits from both and in our opinion works best for Assembla and for high growth small SaaS businesses with geo-diverse teams.

Cadence Regular fixed length sprints (i.e. 2 weeks) Continuous flow Continuous flow and Cadence on on-demand goal resolution "refinement"
Release methodology At the end of each sprint  - if approved by product owner Continuous delivery or at the team's discretion Continuous and regular pushes
Roles Product owner, scrum master, development team No existing roles. Some teams enlist the help of an agile coach. Depends on organization needs!
Key metrics Velocity Cycle time Velocity and Cycle Time!
Change philosophy Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation. Change can happen at any time Change is part of business

Have an agile day!

-Sergiy and Jacek @Assembla

The feedback and comments from Assembla users were the driving force behind this refinement. We thank you for them and will continue to improve Assembla based on customer feedback. We are working on a UX roadmap including treats for you #projectplanners and #agile developers using our task management tools and repositories. Stay tuned for a follow-up blog about our plans!