Blueprint by Tiny
Return to Tiny.cloud
Return to Tiny.cloudTry TinyMCE for Free
Search by
A laptop, notepad, and pen sit on a wooden table in front of a whiteboard that’s covered in notes.

Agile at Tiny: How we’ve adapted agile principles to work for us

Ben Long

April 23rd, 2020

Written by

Ben Long
Ben Long

Category

Engineering

Tagged

Like many tech companies these days, Tiny uses agile methodologies and practices to organize our teams and get work done. 

So, we thought we’d share a bit about how we do agile and how we’ve adapted it to work for us. Hopefully it’ll inspire your own team if you’ve recently transitioned to a more agile way of working, or you’re thinking about making the switch.

First of all, let’s cover the basics.

What’s agile?

Agile is a way for teams to efficiently work together and manage projects while focusing on the customer experience. 

The Agile Manifesto sums it up nicely:

Agile teams value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

While agile was mainly created for software development teams, agile principles are now being used by wider organizations and teams. (Basically, all the cool people are now doing it.)

What are the agile principles?

You can read the official agile principles here, but here’s what you need to know...

Customer satisfaction is #1 

The customer’s experience should be a key driver in all decisions from your choice of technology to what direction your product goes. This comes down to collecting and analyzing the data to understand what customers want and need.

Be open to change 

In agile, it’s all good if things need to change even late in the game. Sometimes you’ll get new information and priorities, which will mean canning a project you’ve been working on for a few days or weeks. But it’s better to change now than release something that your customer doesn’t want or need. 

Sometimes you learn something and it changes everything. There’s no point in releasing an update if you know it’s not solving the problem or there are more problems. Sometimes you can put your heart and soul into something and someone will just rip it out from underneath you. It doesn’t happen all the time, but once in a while it will.

Early and continuous delivery of valuable, working software

Agile principles focus heavily on rolling out changes with every sprint, if possible. The idea is that the more you release to production, the easier it is to manage. Previously, the waterfall approach meant big changes happening all at once in a “big bang” release, which meant that a lot of things were overlooked in testing. It’s easier to test smaller, more frequent releases, and it means less context switching for developers.

Collaborate

Face-to-face collaboration is ideal wherever possible. This can sometimes mean getting everyone in the room, from business operations through to developers, but this will depend on the complexity of the task and situation.

Face-to-face over tools. Tools are great for tracking and being able to drop details and data into, but at the end of the day, face-to-face is best. Body language can tell you a whole lot more, and tone is easy to misinterpret in a (chat) message.

Be sustainable

Set up processes that can be sustained at a constant pace. Streamline everything to make it comfortable for your team to get the work done. Sometimes you’ll have urgent changes come through and you’ll have to push through it, but it’s important to generally schedule your sprints so that the work fits your team’s velocity.

Keep it simple

Don’t overcomplicate it.

Reflect and adjust

Regularly reflect on behaviors and adjust. Do retros every single sprint so you can identify problems early and adjust quickly. Plus, talk about the good things your team has accomplished recently, too.

We don’t want a team member to be brewing on a problem internally when it could be easily expressed. Retros are really valuable to ensure you’re getting closer to smooth waters with the team. But it’s also a great time to highlight what’s worked well and share new ideas.

5 ways we’ve adapted agile to work for us

Tom Cruise in movie

You can have a hybrid of agile and other ways of working. You’ve got to adapt and adopt for each individual team. And that can be based on the product, people, and technologies.

Not all the agile principles will work for your organization or team - 100% agile isn’t realistic. And you certainly can’t magically transform into agile overnight if you’ve been working a different way until now - this process can take years.

So, how do you adapt agile?

Like most agile organizations, Tiny’s development teams adopt the principles that make the most sense for us and adapt some of them to suit the way we work. We’ve talked to some of our teams to hear about how they’re using agile principles and methodologies:

1. Using increments

Here at Tiny, we structure our work into two-week sprints, and we have all our teams that do agile start and end sprints at the same time to line up dependencies.

We measure velocity in story points, which help us understand what issues and user stories we can realistically cover in a two-week sprint. We also track progress during the sprint using burn-down charts.

Before each sprint begins, we do fortnightly sprint planning so we’re all on the same page about what features and bug fixes to work on. We practice “just enough” backlog grooming to break down each feature and detail the complexity. Then we get our teams to commit to the planned work.

In agile, it’s all about the team committing and having an input into what they’re going to achieve. They will be more inclined to achieve it if they said they were going to do it in a given amount of time.

 

All teams doing agile start and end sprints at the same time to make it easier to measure velocity. The first time you do fortnightly sprint planning it can take a while, but now the team has it down to around 30 mins.

Alice Walker, Senior Product Designer @Tiny

2. Team structure

For the most part, our teams self-manage their commitments and decide what they’re going to be working on. Because some of our teams are on the tiny side, we do a lot of cross-skilling, cross-functioning, and multiple-hat-wearing.

3. Standups

One of the most well-known agile principles is the daily standup meeting, and it’s one of the most important ones for our team here at Tiny. Standups help keep our teams more connected. Plus, they keep us all on the same page as we share what we’ve worked on, what we’re working on next, and any issues or blockers.

Our standups usually involve all the core team members and go for about 5-10 minutes.

The first agile principle we started doing was standups. That completely changed the tone and communication in the team for the better.

Alice Walker, Senior Product Designer @Tiny

4. Continuous testing and releasing

Bart Simpson sits up and says

Here at Tiny, we continually develop, test, and release features and updates, which is in line with the core agile principles. Although, there is one main exception here.

Our releases for TinyMCE come out at different times depending on whether you have the open source or enterprise version. Open source is always the first to receive new features so developers can provide feedback and we can iron out any issues. Enterprise generally takes a bit longer because we need to ensure everything is properly documented, fully tested, including reports on what’s changed. This is to ensure stability for our enterprise customers.

5. Working with distributed teams

Tiny’s teams don’t work all under one roof. We’re a highly distributed team, with offices on 3 different continents, across 9 different cities. While we can’t always meet face-to-face, we do have regular video calls, chat regularly on Slack, and keep everything transparent and accessible in our cloud storage and project management systems.

During the COVID-19 outbreak, we’ve been able to work in the office one day, then at home the next. It was really just a matter of taking equipment home for some or just signing on at home. We did attempt one text-based chat standup meeting, but we’re making an effort to connect face-to-face and chat over Zoom as much as possible.

6. Adapting agile to non-dev teams

While some organizations only do agile among their development teams, Tiny applies aspects of agile principles across most of our teams, including design, marketing, operations, etc.

For example, in our marketing team:

  • We’re clear on roles and responsibilities
  • We do standups every morning (at the moment, this happens on Zoom, due to COVID-19 and our whole team now working from home)
  • We’re in constant contact and communication with each other
  • Regular games of pool help us break down barriers (when we’re in the office)
  • Each person has their deep area of expertise, but this is complemented by broad expertise across other roles
  • We do a lot of “experiment, reflect, repeat”

How do you do agile?

There’s no one-size-fits-all, so chances are, your team does agile a little bit differently than any other team (including our people here at Tiny).

We’d love to know how you apply the agile principles at work - as well as how you’re adapting them if your team is working from home right now. Share your experience of agile over on Twitter @joinTiny.

Agile
Ben Long
byBen Long

Developer Advocate at Tiny. Computer scientist turned storyteller. Reminisces about programming on the MicroBee. Writes picture books for kids. Also the wearer of rad shoes. “Science isn’t finished until you share the story.”

Related Articles

  • Time-lapse photo of highway road at dusk, a stream of white light on the left and red on the right.
    Engineering

    A Tiny road to Reason

    by Andrew Herron in Engineering
Subscribe for the latest insights served straight to your inbox. Delivered weekly.

Deploy TinyMCE in just 6 lines of code

Built to scale. Developed in open source. Designed to innovate.

Begin with your FREE API Key
Tiny Editor