4 Ways Unito Is (Still) Using the Agile Manifesto
If you’re a developer, you know about the Agile Manifesto. Even if you’re not a developer, if you work in tech, you’ve heard of the manifesto. Its four core values have permeated the industry and transformed the way many of us work.
But as people have rushed to apply Agile concepts to their workflow, the word itself has become a buzzword more than anything. It’s bad enough that one of the people behind the manifesto, Dave Thomas, has written about it in his post Agile is Dead (Long Live Agility): “The word ‘agile’ has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.”
But just because the word “agile” has lost its meaning doesn’t mean the concepts outlined in the manifesto have lost their value. Thomas’ view is that we should still strive to work with agility, without calling ourselves “agile.”
As a small team, Unito strives to work with agility. Here’s how we’re (still) applying the Agile Manifesto to what we do.
Individuals and interactions over processes and tools
Scrum is a well-known agile methodology that values collaboration and self-organization over sequential processes. A key part of this method is the morning scrum meeting, in which the members of a team stand up and tell everyone else what they’re working on. This is also a great time to share blockers.
In the typical scrum methodology, this meeting is done in person. At Unito, we use an asynchronous scrum, done over Slack.
We’ve written about our asynchronous scrum before, but here’s how we do it. Each morning, every employee posts in the “daily async scrum” channel. They list what they accomplished the previous day as well as what they’re planning to get done today. That means we get a quick summary of what everyone else is up to. We can estimate the workload of other departments and see spots where someone can jump in and help.
We make sure everyone in the company contributes to the scrum. That gives people a chance to spot opportunities for collaboration they wouldn’t otherwise. We’ve prioritized interactions by taking the typical scrum process and adapting it to our team.
Another way we strive to work with agility comes out of necessity. We’re still a small company, meaning we have a small development team. So we can’t have developers overspecialize in one part of the product. Our team needs to be flexible — and it needs to rely on other departments more.
That’s why we use squads. A “squad” is a team of people from across departments that work together towards a single purpose on a per-project basis. A squad might include several developers, a member of the sales team, and a designer, for example. That gives the squad insights on the product that a dev-only group might not. We make sure to shuffle squads after a few projects. This promotes the cross-pollination of ideas and keeps people working at their best.
Working software over comprehensive documentation
Breakthroughs happen when developers are free to experiment. That means bending rules and sometimes ignoring processes entirely. To give developers that kind of freedom requires rigorous testing.
Unito doesn’t have a QA team so that responsibility lies with our developers. We rely on them to create code that works, as well as designing and carrying out their own test plan.
We use test-driven development and automated testing to give our developers the ability to work with agility, even without a QA team. Unit tests run in the background to find issues in individual components, while integration tests cover the global system so that everything works together. Because we’re continually running these tests, our developers feel comfortable working quickly without fearing that they’ll break the product or delete the database.
There’s another way we give our coders greater control and ownership over what they do; we make them use the product. We have a wheel with the different work management tools we integrate (eg. GitHub, GitLab, Jira) sitting in one of our conference rooms. Before each project, we spin the wheel. Whatever it lands on, that’s the tool we’re using to manage that project. Then, when our coders need to coordinate with someone who works in a different tool — like a product manager — they use Unito.
Because our developers have to use the product — and tools that might not be their favorite — they have a stake in making it work.
Customer collaboration over contract negotiation
Developers aren’t usually the frontline when it comes to customer support. Issues, feedback, and user stories usually have to go through several filters — be they human or digital — before reaching the development team.
Ever played the telephone game? How warped is the original message when it comes out the other end? How long does it take to get there?
Betas, both public and private, are a great way around this, as are iterative product roll-outs. We usually do this when testing new features. We also empower our developers to be involved in the feedback process; we’ll encourage them to take part in calls with customers so they can get direct access to feedback.
This doesn’t only apply to launches. When we receive issues and bugs, we encourage our developers to reach out to customers and get context. Because we’re removing the barriers and filters between developers and customers, our team has a better understanding of whose needs they’re trying to fulfill.
Responding to change over following a plan
Unito’s commandments drive what everyone is working towards. One of these is “favor judgment over rules.” Because we’re growing so quickly in the midst of an ever-changing industry, sometimes a well-thought-out plan has to be corrected mid-course.
That means examining rules and processes regularly and tinkering with them. We evaluate the health of squads and projects regularly — every week or so. Then we can adjust as we go or stick to the plan. Agility isn’t about not making plans; it’s about staying flexible.
We’re also not strict about having deliverables at the end of every sprint. This might seem counter-intuitive, but setting strict requirements for delivery too regularly can actually work against continuous delivery — one of the concepts of the Agile Manifesto. Instead, we deploy software as soon as it works. That’s another advantage of the daily asynchronous scrum; we can see how close projects are to launch. Additionally, we use feature flags to allow other departments to tweak their release timelines without congesting the development pipeline.
Because we’re over-communicating these things asynchronously, our team is free to deliver when they’re ready — with agility — rather than following strict deadlines.
Agile is not that dead
Whether or not you agree that the term “agile” has been overused, the concept of “agility” is more important than ever. These are just some of the ways we apply agility to our workplace. You can try some of these ideas with your team if you want to inject agility into their workflow.
A version of this post appeared in Forbes. You can read it here.