While the vast majority of engineering software companies are likely familiar with the concept of “agile development,” that doesn’t mean that they are actually doing agile development.

It’s a bit like the advice to eat 6-8 servings of fruits and vegetables every day. Sure, we all know the well-documented benefits of embracing that habit, but how many of us are actually doing it?

It’s a shame, because virtually every software organization can benefit from what agile has to offer – allowing them to not only improve their internal operations but drive better results for their customers by developing more valuable products.

Why Agile Matters

A brief refresher on agile is helpful here to explain why it’s important, what benefits it can unlock, and what pitfalls it can help you avoid.

The Agile Manifesto is based on four core principles, the first of which is to favor individuals and interactions over processes and tools. In other words, beyond the shiny tools and pieces of tech you might use in your development efforts, you need functional teams that are working well together.

Without this emphasis, you can develop silos. This is something that’s likely familiar to any engineering software organization, where the development of a feature is handed off from one expert to another. This siloed approach requires quite a bit of fancy coordination to make sure Expert B is ready for the handoff from Expert A, so that the feature isn’t sitting on the proverbial shelf, gathering dust.

The second principle is to favor working software over comprehensive documentation. Often, substantial effort goes into creating a detailed design for something that’s going to be developed well into the future. If you're not working on the design immediately, the documentation can become obsolete: Six months down the road, the situation may have changed or you may have thought of a different approach, which instantly turns that upfront effort into a waste of time.

The third principle is to favor customer collaboration over contract negotiation, particularly when it comes to new feature development. Any software organization has probably encountered this scenario: You agree in the contract on what to build, you go off for six months to develop the feature, and then you present it to the customer, and they say "What on Earth is that? That's not what I wanted."

By keeping the customer in the loop, you can avoid developing a feature that does not meet the expectations of the user and save yourself a lot of unnecessary work to boot.

The fourth and final principle is to favor responding to change over following a plan, and it’s closely related to the above principle about keeping the customer in the loop rather than rigidly sticking to what a contract dictates. As you start developing, you often realize that there’s a better way to do things than what had originally been planned. It’s folly to zealously stick to the original approach and say “Sorry, we can’t take on that new and admittedly better approach because it’s not planned.”

Adhering to these core agile principles enables software developers to avoid unnecessary work, optimize their development teams, and create a better product for their customers – so, what’s the hold-up in embracing it?

Simply put, agile is not easy. It requires ongoing effort to make it a success. And in many cases, there’s a thicket of internal challenges to navigate.

For instance, software engineers might be predisposed to only want to work on the areas that they like or that they want to work on. Others might be tempted not just to tackle the problem in front of them, but to try to anticipate and solve any future problems that might come up later. This is just a natural (and admirable) tendency among engineers – but the problem is that sometimes “later” never comes, because of changing circumstances.

Then there is the question that can really send things in the wrong direction: “When will it be done?” If you commit to a date, you need to come up with a design, then document that design, and estimate everything in that design – exactly all of the things that agile says that you shouldn't do.

Before anyone starts feeling discouraged, rest assured that these internal challenges are just that – challenges – and can be surmounted.

Getting Started, Getting Results

For companies wondering where to even begin, a good starting point is for them to look at what they are doing in terms of scrum to find things that they can improve on. For example, they can look at being more methodical about their sprint planning and more diligent about their standups.

One way of doing this is to be better at defining sprint goals, asking at the start of each sprint: What is it that we really want to achieve at the end of this sprint? It's not just about doing a bunch of tasks; it's about accomplishing a particular goal. That goal is what's going to build team collaboration, which is an essential piece of scrum.

There are also tweaks to be made around assembling teams. Organizations can build teams around all the necessary competencies, not just in terms of the development skills, but also in terms of QA, making sure that there are scrum masters within the team that are able to coach the team about good scrum practices.

Additionally, organizations can drill down on seemingly minor things like fine-tuning the definition of “ready,” and the definition of “done.” For instance, is the work that’s about to be tackled that's going into the sprint backlog actually ready to be worked on? Does the engineering team understand what they need to accomplish? If it's not ready, don’t even bother tackling that chunk of work, because it's not going to go well.

Likewise, equal care is needed around the definition of done. Once an engineer has started working on a feature or other aspect of the software, at what point can they say that it's done? Is it when they do the code change? Is it when it passes a QA test? Is it when it gets validated by a customer? Defining “done” and making sure everyone is working off the same shared understanding is important.

Last but not least, teams should fully embrace the power of the feedback loop, which is something that is particularly important in agile. You do work, you put it out there, you get feedback, you listen to the feedback, and then you go through the cycle again. This process should be at the heart of development efforts.

So, what kind of results can software organizations hope to see after taking these sorts of steps? While it’s impossible to “guarantee” results, organizations should see a direct correlation between an adoption of agile practices and an improvement in the quality of their product. On top of that, there will be an enhanced level of teamwork, collaboration, and knowledge sharing, and an improved predictability around what the organization can deliver.

In other words, there is a rich payback waiting to be reaped from the investments that any software organization makes in agile transformation.

It’s Hard, But Worth It

To be clear, transformation isn’t easy. It takes a lot of hard work and persistence, and you’ve got to keep at it. But it absolutely can be done. For engineering software developers who are looking to take advantage of agile and all it has to offer within their own organizations, the effort is most definitely a worthwhile endeavor.

About the Author