You’ve probably heard a lot about the Agile Methodology and may even be practicing it. In our organization, Cisco CX Engineering and Product Incubation, we are entering year two of a transformation that includes the adoption of Agile processes across a large global team. Agile is being mapped to business processes, engineering processes, and onwards.  We have seen improvements, as Agile helps define in clear terms the definition of timelines and requirement organization. Yet, with any new process adoption, there will be hiccups along the way. In fact, software development and Agile can be at odds.

What?! Why would I say this? Software developers are taught to think through all use cases, including possible problems, inputs, outputs and design for long term use.  Agile instructs developers to deliver what is defined in requirements, not what the developer believes is needed.  The methodologies of “complete solution” vs “what is needed” present a conundrum that developers must resolve.

So, how does a developer resolve these two methodologies?

Let’s walk through a quick example to explain how our seasoned developer, Anne, will handle what looks like a simple requirement.  (Note: I am keeping this example very simple for brevity.)

Requirement: Develop a logging solution for existing services that sends logs to a central server in JSON format.

Background:  Currently, services are written in Java and Python and there is an effort to investigate other languages that could be chosen to replace Java.

Approach 1:  Design Java and Python libraries from scratch that provide a consistent API.

  • Consistent library across both service languages
  • More development required to provide all features and shake out bugs
  • Maintainers of the library can easily debug and add new features
  • Service developers must wait for their respective library to be coded and debugged

Approach 2: Design two libraries that utilize existing libraries in each language.

  • Same as approach 1, provides consistent library
  • Less development than approach 1, but there could be inconsistencies in capabilities of the supporting libraries
  • Maintainers of the library can easily debug the wrapper, but will struggle to debug supporting libraries
  • Service developers must wait for their respective library to be coded and debugged

Approach 3:  Utilize existing libraries for each language and utilize a log scraper.

  • No library to develop or to maintain
  • Service developers can start using the chosen libraries immediately
  • Logging team must learn to use a log scraper
  • Log scraper is independent of service language

From the three possible approaches above we can see that each have their own benefits and drawbacks. In a strict execution of the Agile methodology, you should only develop what is required and nothing more.  With that in mind, Anne should choose either approach 2 or 3.  Approach 1 requires more development and should not be considered.  Some would argue Approach 3 satisfies all the requirements and is future proof.

As noted, the above example is contrived, and I didn’t give you the full story.  What if the requirements included that the logging API must run on a spaceship with limited memory and custom communication mechanism to the central server?  Or if there is strict restriction on open source libraries?  Each of these two requirements would have changed the choice.  This is where management will lean on Anne to understand the requirements and choose a solution that meets both Agile and smart engineering.  For example, if we had learned that Anne was providing the solution for a spacecraft, approach 1 would most likely be the best solution because of tighter requirements imposed on a space platform.

You can see from this example that software developers struggle with their natural instincts to deliver a “complete solution” compared to the “what is needed” Agile methodology.  While Agile is an industry best practice, it can be at odds with the training of developers and their natural instincts.  Agile development works because it sets guardrails to help limit the over-engineering instincts.  Anne is still responsible for advocating that sometimes the minimal is not always enough. Her knowledge and experience should guide her in advocating for the best solution based on time, budget and requirements.

Companies that continue to adopt Agile methodologies in attempts to achieve effective and accelerated software releases should also factor into their process the experience and intuition of their software developers. Agile is not a “one size fits all” approach, human input is valuable to the process, and must be heard and incorporated for the best possible outcome.

Agile Team Workshop        Agile Team Workshop      Agile Team Workshop

Photos above (taken before covid): CX Engineering & Product Incubation leaders participate in team building and workshop on agile development process. 

A topic for another day will be how requirements (or lack thereof) are defined can reduce or intensify confusion. I will cover approaches that companies follow to green light a project, communicate the overall project goals and how this process can help or hinder the requirement definition process.

Do you believe that Agile is at odds with good software development?  Share your thoughts and or learnings below on the challenges and or solutions you have used to blend Agile with software development.


Scott Saltsgaver

Technical Lead & Architect

CX Engineering