In the post, Thomas wrote, “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.”
So Thomas suggests moving away from agile and toward “agility.” He wants developers to ignore the modern concept of agile and simply apply the values highlighted in the original manifesto to our daily work.
If you’re wondering how to embrace agility, we’ve highlighted the manifesto’s four core values and how they inspire our own approach to development at Unito.
Individuals And Interactions Over Processes And Tools
There are a number of ways we favor individuals and interactions within our development workflow. First on that list? We’ve shifted away from the traditional scrum model.
Rather than force people to do rigid morning scrum meetings, our entire company participates in an asynchronous daily scrum in a Slack channel. Every employee posts what they accomplished yesterday, what they’re working on today and their blockers.
As with regular scrum meetings, these Slack summaries provide a big-picture view of what people are up to and can be used to spot potential issues. If you're thinking of implementing a similar tactic, make sure you have your entire company participate. This allows your developers to find new opportunities to collaborate with other teams they would not have encountered in a traditional scrum.
In addition, as a small business, we don’t have the luxury of having our developers specialize in one part of the product -- the standard for large dev teams. Our small team needs to be flexible enough to take any challenge thrown our way. At the same time, we rely on other departments to bring a level of expertise to each new project.
If you're in a similar boat, use multidisciplinary squads to promote these interactions between departments. They unite developers with CSMs, salespeople, writers and designers. Members brainstorm together, work on tasks and generally share ownership in a deliverable. And when that deliverable is completed, you can shuffle the squads for the next project so there’s more cross-pollination of ideas. This will also help you push back against Conway’s law, which essentially infers that your product will end up being shaped like the development team designing it.
Working Software Over Comprehensive Documentation
Innovative development means taking risks that bend your process or, on occasion, ignore it entirely. You need to find ways to empower your team to be courageous and creative without actually putting the product at risk. The key to that is testing.
We have no QAs at our company, so our developers carry a greater responsibility to create something that works. This doesn’t mean there’s no testing; it means that the coder is the one creating their own test plan.
Through test-driven development and automated testing, you can free your developers to work with agility and take risks. Unit tests can constantly run in the background, making sure you catch mistakes in individual components. Integration tests can then look at your system globally, essentially ensuring all the pieces work together. This safety net allows developers to move fast while being confident that they’re not breaking the product or deleting the database.
Finally, we make our coders take ownership of their work by dogfooding our own product. Our company connects different work management tools, including Jira, GitHub and GitLab. Before starting a project, we literally spin a wheel to see which tool we’re going to use to manage it. By forcing our team to use the product, we ensure they have a stake in it working correctly.
Customer Collaboration Over Contract Negotiation
In many businesses, there are at least a few layers between customers and developers. Account managers usually own the direct communication and share their learnings with development teams. But the game of telephone between the user issue and the developer who can fix it introduces delays and information distortion.
In order to rectify this, your company can use both private and public betas and iterative roll-outs of your product. During these phases, developers should be invited to jump on calls with customers to make sure they’re meeting client needs and addressing any bugs.
Outside of launches, if a user reports an issue or bug, your development team should once again be encouraged to reach out to get more context. These conversations put them in the customer’s shoes and to better understand their needs.
Responding To Change Over Following A Plan
One of our company’s commandments is “Favor judgment over rules.” It’s not because you planned something that it makes sense here and now.
If your company has a similar mindset, you should adjust your processes regularly. You should evaluate the health of squad projects on a weekly basis, taking into consideration any new context, and decide to either stay the course or modify your plan.
We also don’t set strict deliverables for the end of every sprint. We’ve found that forcing our teams to deliver something every couple of weeks actually impedes continuous delivery. As soon as you have working software, you want to put it in production. Our daily asynchronous scrums allow us to easily see when things are feature complete or in production. Feature flags also give knobs to other departments to work on their timelines for releasing the product without congesting the development pipeline.
Essentially, by continuously communicating the status of deliverables, you can free your team to launch things with agility.
Ready To Ditch Agile For Agility?
Whether or not these methods are right for your team, keeping the values of the original manifesto at the heart of everything you do is a surefire way to build a strong, flexible development team.
