Are agile practices still relevant?
It’s been 21 years since the Manifesto for Agile Development revolutionized the software industry with its flexibility-focused set of values and principles, which have since underpinned frameworks as varied as Scrum, DevOps and Kanban.
Emphasizing customer collaboration over contract negotiation, individuals and interactions over tools and processes, and quality software instead of exhaustive documentation, agile principles are aptly named. To teams guided by this methodology, nothing is more crucial than staying agile.
But with this in mind, technology has evolved dramatically since agile principles were first introduced, and the industry of today differs from that turn-of-the-century period in more ways than one. Automation and collaboration go hand-in-hand, and the advent of cloud computing has transformed software development while making it possible for both small and large teams to communicate effectively from all around the world. Has the industry progressed past agile practices, or do the principles outlined back still work well within the modern tech workplace?
To assess the current state of this once-ubiquitous methodology, Built In sat down with engineers and product management leaders at four different tech companies, asking them whether they’re still staying agile or moving along to other philosophies. Here's what Amount CTO Fred Lee had to say.
Does your team leverage the principles of agile in its methodology?
The principles of the agile methodology are still important and still valid — but, over time, agile has evolved to mean too many things. There is no longer a clear and precise meaning. Every company I have been at has done agile, but they all did it differently. The weakness of agile is not its principles; these are clearly articulated. They are also sufficiently ambiguous to broadly gain acceptance. When the principles were developed, it may have been controversial to say, “Working software is the primary measure of progress.” But now that is widely accepted, probably due to agile. So, for me, agile principles are still good. Maybe a little dated. But still good.
The bigger issue is that it is not really a methodology. It does not tell you how to implement the principles, leaving it wide open for lots of methodologies to make a stake. None are perfect. All are good. My primary goal is not to find the perfect method but to create clarity. Choose a good process. Clearly communicate it to my team and company. Teach it. Get alignment on it. And then adhere to it. These changes in process and behavior are what makes it difficult, where agile can fail, and where I have failed many times.
What methodology do you use to guide how your teams ship new products and features?
We have a product development process called Shape Up, created by Basecamp. Amount will be the third company where I have attempted to implement Shape Up, and I have learned some great lessons. This is not just a product and engineering change. This affects the entire company. Making the change takes more time than you think it will. You have to teach it and re-teach it over and over again. You must give everyone enough time to absorb and react to the changes; people need to adopt the change because they see value, not because they are being told.
I had over 70 one-on-one meetings before we officially started using the Shape Up process, which fundamentally says three things. One should spend meaningful time planning and designing to produce valuable and high quality output. One should manage one’s constraints by scoping all work to the same duration and team size. And one should prioritize work in such a way that the team is clear-minded about what to work on.
These are not new or controversial perspectives. In fact, most people want these things. Everyone just wants the proper time to do great and meaningful work. I am happy to say that we are on our way to doing that at Amount. And Shape Up has been a big part of that.
