Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

How We Started Releasing Features Twice As Fast (Case Study)

When businesses rely on your app for their day-to-day work, you have to be agile enough to quickly address their needs. If you don’t, others definitely will. In the unforgiving world of SaaS, delaying a critical feature (or rushing a bug-ridden piece of code) will mean losing clients. A solid agile workflow can make all the difference.

Agile development process1
The development cycle, the core of any agile approach, is constantly being revised and improved. (View large version2)

We’re the team behind Active Collab, a project-management app with an ever-growing set of features and a sizeable user base. This means that even the smallest change in functionality will affect a large number of people.

Further Reading on SmashingMag:

Therefore, the development process needs to run smoothly and up to a standard, with delays reduced to a bare minimum. Before any change makes its way to the end user, it goes through five crucial phases: feedback, design, development, quality assurance and deployment. In this article, I will share what we’ve learned (the hard way) about each of the stages from over eight years in the business.

A Wake-Up Call Link

Before I get into the details, let’s look at how this all came about. After years of adding features without enough scrutiny, our app was suffering from feature bloat. We’ve added so much functionality over the years that new users were intimidated by the sheer complexity of the UI (never to return again). We knew we had to rebuild from the ground up, even if that meant rewriting every single feature from scratch.

Then came the delays. The features for new versions were constantly lagging behind schedule. For example, a junior developer was supposed to develop an integration with QuickBooks. We didn’t accurately predict the complexity, skills or knowledge needed. Plus, he was the only one assigned to that task, and no one could quickly jump in to help him out. As a result, what was supposed to be a two-week job ended up taking five. Those were a few red flags.

Missed deadlines can have severe implications. (View large version8)

It was clearly time to switch to a more agile approach. We took what we liked from various agile (and not so agile) methods, combined it with experience, and came up with our own version, which has been delivering great results ever since.

Let’s take a closer look at the road that a feature must travel before it’s offered to the end user.

To ensure quality, a new feature is introduced only after it has gone though all of these stages. (View large version10)

From Suggestion To Feature Link

In our workflow, a new feature starts taking shape long before it reaches the development team, and it’s usually born of user feedback. This is no coincidence — we used to release features no one needed, usually just because one user was particularly loud or we simply thought something would be great to have. Instead of imagining what features our users might need, we now make decisions based on actual demand.

If you’re into lean manufacturing, you’d say that our customers “pull” certain features by requesting them more often than others. Our support and sales teams are a big part of the process because they’re constantly in touch with users who share their needs and ideas.

Based on the feedback, our teams update a form that looks like this:

Feedback form11
Feedback collected and saved using this form is essential for deciding which features make their way onto the road map. (View large version12)

When we don’t have all of the information we need, we’ll reach out to customers directly. This is usually done with targeted surveys on a carefully selected sample. The point is that we listen. No feedback is lost on us. It’s always acknowledged and documented.

The next step is analysis. We tally the scores each month to see which feature got the most votes. Also, with proper categorization, we get a broader perspective on which parts of our software need work. For example, if the calendar is getting many complaints, we’ll consider revamping the entire section, rather than introducing the feature that got the most votes (such as calendar exporting).

However, even when the results are in, the decision to introduce a feature isn’t final. Before it makes it onto our to-do list, we always do a thorough sanity check:

  • What benefits will this feature bring to users?
  • Does it fit our product philosophy?
  • Will it add unnecessary complexity?
  • Does it blend in nicely with the existing interface and functionality?
  • Do we have the resources to deliver it in a reasonable timeframe?

When a feature passes the checklist and the product owners approve it, it’s time to go to the drawing board.

Designing For The User Link

Experience has taught us that adding a new feature doesn’t just mean sticking it on top of the UI — you have to blend it with the existing design, with the user in mind. If you don’t do this, you’ll soon end up with an app so complex that only a brave few will make it through the first five minutes of the trial (yes, we’ve been there). Aesthetics are also important for a good first impression, but our main concern is ease of use. A feature needs to be added in a way that feels natural to the user.

We keep things in perspective by asking, Where would the user expect this option to be?

For existing users, it’s important that the new design follows the patterns they’re familiar with and doesn’t disrupt their workflow13. Also, there are industry standards and conventions that we’re all (unconsciously) used to. Never expect your users to change their habits completely. They’ll more likely look elsewhere if the interface is not intuitive.

Take keyboard shortcuts. You could make your own set of shortcuts and expect users to learn them (they probably won’t). Or you could add ones that people already use. A lot of our users already use Slack, for example, so we added a shortcut they are already familiar with (Command + K for quick jumps works in Active Collab as well).

Quick jump window in Active Collab14
Command + K opens this window, which enables a user to quickly jump to a page in Active Collab. (View large version15)

When the user flows are in place, our UX designer mocks up the design in Sketch. We rarely use HTML in the early stages. Well-thought-out Sketch visualizations give us enough flexibility that we don’t have to do any backtracking when we start coding. The initial design usually ends up matching about 80% of the final product. The rest is added and adjusted along the way.

Feature design mockups16
Initial design mockups are the basis for further development. (View large version17)

Another important step of the design process is copy. Our copywriters devote a great deal of attention to every single word. We even have our own style guide, to sound as approachable and to be as easy to understand as possible. For example, saying “security certificate” instead of “SSL certificate” conveys in layman’s terms something an average user might not be familiar with.

When all this is done, the feature is assigned to a development team. The team is made up of a project manager, a lead developer and a number of back- and front-end developers, depending on the workload. The project manager makes sure everything runs smoothly and on schedule, while the lead developer takes care of the technical side of things. They also coordinate and mentor junior developers.

Time To Kick Things Off Link

Our kickoff meetings aren’t boring motivational get-togethers. They are opportunities for a development team (consisting of junior and senior developers) to meet with the project manager and product owner.

Instead of allowing empty monologues, we focus on putting everyone’s words into actionable tasks. Throughout the day, three important meetings take place:

  • The product owner presents the given feature to the team, the ideas behind it, the initial designs and the expected results.
  • Then, the team has its own meeting in which it discusses the action plan, potential problems and the testing schedule.
  • The final meeting is attended by everyone involved, and the plan takes its final shape. At the end of this meeting, the team gives estimates for demos and a final due date.

Three meetings might sound like a lot for one day, but that’s how we make sure problems are solved early on. Filling in the blanks at this stage saves our developers a lot of time, false starts and backtracking. The meetings also encourage teamwork and make everyone feel that their contributions are welcomed.

Team meeting18
Teams spend as much time as they need discussing all aspects of the work ahead.

After the meetings, the team will have all of the necessary information:

  1. What?
    This is the scope of the feature and includes everything that needs to get done, as well as potential blockers and bottlenecks. We try to anticipate as many scenarios and edge cases as possible. Predicting all of them is not easy; they often come up as we go.
  2. Why?
    The product owner estimates the business value of a feature and explains why it’s worth the effort. This way, the team gets a clear picture of the benefits to customers and the product. The prime motivator here is that everyone should understand why their work matters and how it contributes to the company as a whole.
  3. How?
    By outlining the steps required to complete a feature, we make sure our developers never lose their compass. We also set realistic expectations by adding a complexity tag. We went with t-shirt sizes — S can be solved within a few hours, while XXL takes weeks or more to complete.
  4. Who?
    The team lead is responsible for finishing a feature or task on time and for updating the product owner on the progress. Other team members are assigned to their own set of subtasks, so that it’s perfectly clear who is accountable for what. Keeping this as transparent as possible helps us to see whether someone is struggling or causing delays.
  5. When?
    With everything taken into account, a due date is estimated. If a task is delayed, we analyze the reasons and use that experience the next time. That way, a missed deadline becomes a learning opportunity and not a source of stress.

Kickoff day can get hectic, but it’s also very fruitful. Everyone pitches in with ideas and comments. A task transforms from an empty slate to a hub for comments, edits and updates. By the end of the day, the development team has a clear picture of the work ahead and solid ground to build upon.

A task in Active Collab19
All important information is available in the task item. This is also where team members communicate and post updates on their progress. (View large version20)

We go through this checklist before beginning work:

  • feature explained,
  • steps for completion outlined,
  • business value assigned by product owner,
  • complexity assigned by team,
  • feature and bug dependencies identified,
  • performance criteria identified (if needed),
  • demos scheduled,
  • start and end dates set by team leader.

This is the moment when a task moves to the “In progress” column.

Task moved to In Progress column21
When a feature is kicked off, the task moves into the “In Progress” column. (View large version22)

It’s coding time!

Teamwork On Display Link

Our developers never work alone — it’s always a team effort, and it’s by far the most efficient way to release new features. Before teams were introduced, a (junior) developer would get stuck with a problem and might have gone round in circles for days (without anyone realizing it). Or, if they weren’t the lone-ranger type, they’d constantly be distracting colleagues and managers.

On the other hand, with teams, we mix people with different skill sets and levels of experience. This means that everyone is assigned a set of tasks appropriate to their level. Plus, seniors get the benefit of learning how to manage and coach junior teammates — and juniors get to ask for help. Because it’s a team effort and everyone is working towards the same goal, questions aren’t regarded as distractions, and the team can tackle any issue much more efficiently. The team becomes a self-organizing entity, splitting work into phases (or sprints) and presenting their work during demos.

Show And Tell Link

According to the schedule, the team will demo for the product owner. The purpose of the demos is to show how well a feature is performing in its current state and where it needs more polish. It’s a reality check that doesn’t allow for excuses like, “It just needs a few finishing touches” (touches that would take another month). Also, if things start to take a wrong turn, product owners get to react quickly.

Weekly Meetings Link

We started off with regular short daily meetings attended by all developers. Each developer would briefly describe what they were working on, their problems, their blockers and whether they needed help. It soon became obvious that these meetings needed to be more focused and to provide tangible results. So, we switched to having meetings with individual teams about once a week. This is how the product owners and project manager are kept in the loop and all potential problems are dealt with on the spot.

Putting It To The Test Link

The code is written, the demos have been successful, everything seems to be wrapping up nicely… until you release the feature and see that the app crashes. That’s why every feature we make goes through quality assurance (Q/A). Always. Our tester meticulously goes through every possible scenario, checking all options and running tests in different environments. A feature rarely passes Q/A on the first go.

Searching for bugs23
Q/A makes sure no bug slips through. (View large version24)

To increase productivity, we used to let developers start on new features during this phase, but that just resulted in a lot of delayed, half-finished features. So, now the development team keeps busy by working on small maintenance tasks while their feature is being reviewed. If Q/A finds a problem, the developers immediately fix it and resubmit. The process is repeated until the feature passes Q/A and moves on to code review.

This is when a senior developer makes sure the code is written according to our standards. One final step before the release is writing the documentation — you don’t want to get swamped by support emails after releasing a feature that no one knows how to use. Our copywriters also update the release notes and write marketing materials, such as email announcements and blog posts.

Here’s our definition of “done”:

  • auto-tests written,
  • Q/A done and all resulting tasks completed,
  • code review done and code merged to master,
  • release notes updated,
  • feature and bug dependencies identified.

The task has reached the final stage, called “Release Q.”

Release Day Link

Release day: Tuesday25
We aim for a Tuesday release. (View large version26)

When choosing a day for new releases, we immediately decided against Friday and Monday. Friday is not good because any potential issues wouldn’t get resolved until Monday; plus, the support team was already pretty busy then. Monday is not the best time because any major update requires preparation, which would have to be done on the weekend. It’s always good to leave a day for final touch-ups. This narrows down the options to three days — and we went with Tuesday. Here’s why:

  • We have Monday to review the release and add finishing touches before deploying.
  • If there are any untranslated phrases (our web app is available in seven languages), we have enough time to finish the translation.
  • The marketing team has plenty of time to send out newsletters and announcements via social media.
  • We are available to provide upgrade support quickly and efficiently for the rest of the week.
  • If a deadline has passed for whatever reason, we still have Wednesday or Thursday to complete the work.

Free Activity Day Link

The day after a major release is a free day for the team. This is when they learn new skills or do anything work-related that they find interesting. Even though everyone’s eager to know which feature we’ll be kicking off the following day, the team doesn’t discuss that just yet. Instead, they’ll relax and maybe watch a presentation about the history of Erlang, or finish reading that article about why PSR-727 and middleware are important to modern PHP development, or have their own retrospective discussion. It’s a well-deserved day to recharge their battery and celebrate a job well done.

Bug Hunt Day Link

Apart from developing major new features, there is always work to be done on existing ones. Whether it’s a bug fix, a design update or a small change in functionality, the team needs to take care of it in a reasonable time.

Hunting bugs28
Clearing the backlog of bugs is much faster when a day is dedicated just to that. (View large version29)

This is why we have bug-hunting days at least once a month. It’s when all developers stop working on their main projects and turn their attention to maintenance. This focused effort has proven to be a great success. When everyone works solely on bugs on the same day and is available to help each other, the team solves a huge number of issues.

What Is The Result? Link

Releasing a big feature now takes about three weeks on average, from the kickoff to development, testing, code review, documentation and final release. A feature of equivalent complexity used to take us 45 days. From our perspective, that’s a 100% increase in productivity. We accomplished it with the same resources and people, the only difference being an improved workflow.

So, if we have one takeaway for you, it’s this: Nurturing a company culture that eliminates fear of change will make your team better at what it does. Whether you call it Scrum, Kanban or Lean doesn’t matter, as long as it helps your company grow. Experimentation and innovation lie at the heart of any agile approach. Don’t be afraid to test different solutions, measure results and, based on the results, modify existing practices. Good results will follow.

(ms, vf, al, il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29

↑ Back to top Tweet itShare on Facebook

Vanja is a marketing professional and writer, with years of experience in the software industry. He has worked on digital marketing projects for many international companies and has experience in both agency and in-house setup. Vanja is currently in charge of content marketing and social media at Active Collab.

  1. 1

    Your processes are so close to ours in my company that I double-checked the author name if you were not from my company :)

    Some minor differences :
    – new features every end of the month, new patch (bug fixes, small changes) weekly
    – release on Tuesday evening (western europe time)
    – we ended up daily meetings and do some bi-weekly recap’ meeting for now. We stopped doing daily meetings because my team (I mean product, quality and dev people) is gathered in the same open space. So any problem are directly solved just by walking to the office next to you. It works for my team but may not work for everyone (specially if the team is really big… we are ~12 but I guesse this would not work for 20 people).

    Thanks for the article anyway.

    • 2

      Vanja Mimic

      July 12, 2016 4:02 pm

      Thanks for reading! It’s great to hear a similar process works for you as well. It must mean we’re on the right track here :)

      As you said, small teams can allow themselves more flexibility when it comes to meetings. We do have some team members who work remotely so we tried a few different options. Daily ended up being counterproductive but once a week currently works really well for us. Product owners also get involved so it’s not always just a status update. It often involves some serious problem solving.

  2. 3

    Congratulations. You just invented Waterfall.

    • 4

      Jan Klosowski

      July 13, 2016 8:51 am

      You have probably never experienced Waterfall project. Good for you! I can assure you that three weeks for a big feature is NOT any close to Waterfall. It’s a longer sprint. The waterfall projects last for months before the “release day”.

      • 5

        Vanja Mimic

        July 13, 2016 1:55 pm

        Thanks Jan. Yeah, not every project is a Deathmarch, but when you go through one, you never want to repeat that experience. This is nowhere like it, because results are always a couple of weeks away, at most.

      • 6

        No, I’ve experienced plenty of waterfall projects. I’m a project manager. The choice to work on feature releases instead of a monolithic release doesn’t make this “not waterfall.” It just means you are using smaller waterfalls.

    • 7

      Well spotted David :)

      Please see my reply to Zackary below.

  3. 8

    Would like to know your approach to Continuous Integration/Delivery. Did not find it mentioned (or did I miss it?) in this.
    Great XP!

    • 9

      Vanja Mimic

      July 13, 2016 1:20 pm

      Hey Rajith,

      At the moment we use Promiscuous Integration, which shows elements of higher maturity, so it’s likely that we’ll move to real Continuous Integration in the following months. The team uses feature branches a lot, and merges them to the mainline when they are well rounded and reasonably stable (master is integrated in feature branches quite often, for dev and tests). Once a feature is merged to master, it is flagged, and we use it internally (edge) or with a small group of clients (beta) for a while. When we feel that it’s all good, we release it to everyone (stable).

      This is not the ideal solution but we are in a specific situation. We offer self-hosted version of Active Collab as well. Having real CI with self-hosted product could create a lot of extra work and problems for the customers. We need to have actual releases so customers know what they are getting when they upgrade and it needs to include a meaningful set of improvements to justify the effort.

      Regarding tooling, we use self-hosted GitLab with Docker runners that run tests on each push. Deployment is automated using Jenkins (not pretty, but it is a trusted workhorse). We have some jobs that are triggered automatically on push to master (website and help builds for example), but not for Active Collab itself because we are still dependent on releases. These builds are triggered manually, usually a couple of times a day, depending on which channel we are deploying to (edge, beta or stable).

  4. 10

    Hi Vanja,

    You say this article is about establishing a “solid agile workflow” but what you have described is literally a waterfall process. Don’t get me wrong, maybe the workflow works for you, but what you are describing is the very definition of a waterfall process, not agile. In fact, I really struggle to understand how anything in the article is very different from very traditional software development process. Maybe it’s just that you do a mini waterfall for each feature? Can you describe in your own words what exactly is different about the process you have here from normal waterfall, other than the fact that you’re doing waterfall per feature, as opposed to something more monolithic?

    From wikipedia:
    “The waterfall model is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.”

    • 11

      Hi Zackary,

      To us, Agile is not a destination. We see it as thinking, learning, and constant improvement that yields measurable results (measured in how well we are meeting customer demands). That’s what it’s all about.

      Dave Thomas says that agility is what matters, and that it’s a really simple framework (no book or coach needed):

      1. Find out where you are,
      2. Take a small step towards your goal,
      3. Adjust your understanding based on what you learned,
      4. Repeat.

      The whole talk is great, btw:

      Some may not like what he is saying, and may prefer prescribed management and development processes more than the one that’s in constant motion, but saying that such a process (and thinking that got the team to devise it) is not agile would be wrong. The process itself may be ‘waterfally’, but that is how flow works (it flows through work-cells) and it’s great when you are building a known solution to a known problem (Active Collab turns 10 this year, so we know our customers, what they are looking for, and how to built it).

      What we described here is a snapshot of our process at the moment when the article was written. There are many lean and agile concepts that are built into the process that we could not discuss in more details (if we did, we would end up with a book, not an article):

      1. one-piece flow (capacity set to 1, no set sprint length, team works exclusively on one feature, even when it hurts),
      2. need to balance the team (so we don’t get to the hurt part in #1),
      3. pull (customers say what is going to be worked on, not Marketing or Management),
      4. continuous integration and dogfooding (we start using a feature as soon as it reaches level of usefulness for our team, usually weeks before it is well rounded to be presented to customers),
      5. waste reduction (part of the improvement process: take a bit of time to think and discover waste, see if it can be removed, remove or reduce it, learn),
      6. focus on lead time and throughput (who cares how it is called, if it delivers customer demanded results twice as fast and gives you the option to improve even further),
      7. bottlenecks (find them, understand them, see how they affect the value added work, address when needed).

      These are just the higher level concepts that come to my mind at the moment, and each can be discussed in a single article that is as long as this one.

      PS: Starting from the perspective that all Waterfall projects are Deathmarches and that Waterfall is bad (say this in authoritative voice: “That’s the way of the old! It should be avoided! Period! No discussion!”) would seriously limit the team’s ability to think how to improve and better do what they are hired to do. They should be thinking about the customer, value stream, bottlenecks, not getting burned out etc, not what their process is called. Maybe this is “just a bunch of small Waterfalls“, but that alone is hugely different from a Deathmarch, from our customer’s, team’s and business perspective.

      • 12

        I’m not starting from the perspective that waterfall is bad. It works in a lot of places. But, I guess what I am saying is that this doesn’t really introduce anything new? I mean, adopting and inspection mindset and working on smaller chunks is definitely better than not doing those things, but does it make this not-waterfall? And you limit work in progress, which is great and sounds a bit like Kanban, so….. maybe that’s what you are thinking is agile?

        I guess this just seems to me like a slight modification to the standard waterfall process, and it’s just kind of…. well, normal?

      • 13

        From my perspective it sounds like an agile cadence that you’ve born out of practice and formalized into process. That’s not a bad thing and it’s not NOT agile. However, people see formalized process and immediately jump to “that’s waterfall”. The difference between agile and waterfall in my mind are two things 1) rigidity of process 2) rigidity of schedule. If you must hit every checkpoint in a process with a defined artifact at the end and you can’t skip steps, reduce/eliminate artifacts, or even revise the process midproject – that’s more on the waterfally side. Likewise if you must hit defined dates or spend X amount of time in one phase before transitioning to the next and dates are not readily changeable – that too is more waterfally.

        When I see agile with a defined internal process I think LEAN; We’ve gone through our agile practice and identified what provides value enough to be formalized and promoted as a consistent practice.

        Good article.


↑ Back to top