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.
Peapod Digital Labs is the e-commerce engine of Ahold Delhaize USA, one of the nation’s largest grocery retail groups.
Does your team leverage the principles of agile in its methodology?
At Peapod Digital Labs, we’ve implemented the agile methodology across our product and technology organization. We’ve implemented Scrum and Kanban as the primary frameworks and have also embraced Extreme Programming and DevOps practices. In my opinion, agile’s strength is in enabling our development teams to build features in products that can be released on-demand to our customers, thus improving our overall return on investment. It also lets our team respond to changes in requirements more quickly based on the feedback we receive from our customers. Agile energizes our product and development teams, as they are the primary decision-makers when it comes to application design. They are also responsible for estimating and planning work needs based on their capacity, ensuring that we’re providing accurate timelines to our customers. Some of the primary reasons why Peapod Digital Labs moved to agile is to improve our speed to market and make our deliverables more predictable.
Technology is changing at a rapid pace, and adopting practices that help us stay relevant is essential. Agile helps us do that.
How do you ensure that agile principles are properly implemented so that they help developers and product managers, rather than hinder them?
I believe our success is linked to a common understanding of the agile framework. We have a standard agile framework with well-defined practices — like Scrum ceremonies, user story estimation and sprint cadence – as well as good engineering practices to help build software that is shippable every sprint. We also use an agile maturity model that describes the measure of success. The maturity model is tied to tangible, measurable goals and metrics that can quantify progress and success using data. In addition, by building a culture focused on collaboration, we have empowered our teams to be the decision-makers in the development process. Our Scrum masters and agile coaches work closely with the product owners and the development teams to understand pain points and remove all impediments that hinder delivery. We have also organized communities of practices for various roles and several celebration events to strengthen the agile practice.
Amount enables growth for financial institutions with a suite of products and services that deliver a seamless digital and mobile customer experience.
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.
Jellyvision creates solutions for enhancing employee communication and program participation.
Does your team leverage the principles of agile in its methodology?
Jellyvision embraces agile and all of its principles and values. Taking requirements today for a product that won't be delivered for six to 12 months no longer works! Not only are our clients continuously iterating on new ways of working — thanks in part to the pandemic — but our competitors are also quickly dreaming up new ways of servicing their clients. Without agile, we would quickly fall behind. For us, the ability to go from ideation to concept validation to development in quick sprints or intervals, while also having the flexibility to pivot or altogether scrap an idea, is invaluable.
Being an agile organization isn’t merely about how we deliver new products and services to the marketplace, but rather about how we empower individuals, collaborate across functional teams, and incrementally strive towards achieving goals. It is important to note that we are not only a Scrum shop, and that we also use some eXtreme Programming (XP) practices, as well as Kanban and bits of Lean.
How do you ensure that agile principles are properly implemented so that they help developers and product managers, rather than hinder them?
Agile is the key to how we do business. We wholeheartedly believe there is a difference between doing agile and being agile. As an organization striving to be agile, we are ensuring that agile not only governs the way that we develop software but is also ingrained in the DNA of how we do business. This makes collaboration and innovation key to every function within the organization.
We are still perfecting our agile implementation; part of what’s important for us is having an organic evolution, a melding of industry best practices with Jellyvision culture. Most of our delivery teams are practicing Scrum with two-week sprints, but we are also experimenting with moving to Kanban for some of our more DevOps focused teams. We are also borrowing some things from LeSS (Large Scale Scrum), and have created shared team Initiative backlogs to make sure we are always working on the highest priorities for the business.
All of this is underpinned with continuous training and retrospection. The product management office team is constantly sharing insights and conducting formal classroom training. We even launched a Community of Practice initiative, to create a culture of learning and growth here at Jellyvision.
Pampered Chef is a one-stop shop for all things cooking. The e-commerce site offers articles on cooking ideas, recipes and a wide-ranging selection of cooking gadgets.
Does your team leverage the principles of agile in its methodology?
Pampered Chef has applied agile across our custom software engineering teams for many years, and we continually measure, test, learn and improve our practices. It enables and guides us to break down requirements into clear business value deliverables, while allowing the teams with each sprint to deliver working software into the hands of our customers. While applying the iron triangle — where time and resources are fixed, and scope is variable — it drives us to focus on being able learn and pivot fast, with minimal effort, rather than spending countless weeks and not driving the expected outcome. For us, agile is very relevant, but it is important that we keep adapting and improving.
How do you ensure that agile principles are properly implemented so that they help developers and product managers, rather than hinder them?
The key for our agile maturity is that we have dedicated Scrum masters and engineering managers, who make the work visible without impacting other teams in the process. This ensures that teams use consistent best practices and agile rituals. We are using product burnups, which are a great way to ensure that teams are aligned on the known and remaining sprints before we ship new software.
For new digital products and larger product increments, we utilize the MoSCoW technique (Must, Should, Could, or Won't). We use t-shirt sizing and the cone of uncertainty so that we can provide rough estimates and a number of sprints needed. Those estimates allow our digital product team to make the right ROI decisions. Every two weeks, we review the latest software engineering data and adjust our agile practices if needed.
