An Agile Paradox?
Jeremy Streeter
Senior Technology Leader | MS in Software Engineering | Empathetic | Heuristic | People Focused
One of our scrum masters and I sometimes debate intensely around the idea that Agile can include heavier requirements and more advanced planning.
My opinion is that pure Agile works very well under less exact requirements and specifications, but under certain conditions it needs changes, or at least some adjustments in the way we execute it to handle certain circumstances.
The scrum master in dispute believes that developing the documentation and requirements for specifications is not Agile in any way and completely conflicts with the ideals of an Agile Software Development Life Cycle (SDLC). Additionally, the idea is held that Agile and documentation, or developing specifications around our product (based on an existing product) does not make sense because we do not know what we are working on next.
This conversation all started because I think we need a business analyst to help develop the documentation and specifications, and he does not.
The main looming issue that complicates the standard Agile practices are that we are developing a web application as a port of an existing native application with very complex and established business rules dating back to the mid 1990's. Our port has business requirements, pending an upgrade of the native application, to communicate and function with a 32-bit, superceded, divergent code base written in a different language. So we have some technology challenges to overcome.
There are staunch communication challenges: We are working with a remote development team who has a delay, (because of a location in another distant timezone), getting answers on questions around requirements and business rules, as well as does not have an onsite source for business rules domain knowledge like we do locally when we need to ask questions and clarify functionality. Doing this right, from my experience in seeing very successful onshore-offshore software development relationships, requires a full time person locally on site to mitigate these challenges.
My argument lies in the idea that Agile can be applied to all parts of an organization, not only the development process. For instance, heavier requirements and specifications can be outlined earlier when you are replicating or at least interacting with existing business functionality. This means that ahead of development of a product, developers can become stakeholders of the requirements and specification while the business analyst and product ownership teams outline the existing functionality into understandable logic. They all work together to produce usable documentation that can catalyze and insulate related work later, should it occur. The documentation around existing business rules establishes a reference everyone can use within the organization, not just the software engineering teams.
Since we have an existing in-market-product, which we are replicating first and foremost, before improving it, we rely heavily on our product owners for understanding the business requirements on the fly. This prolongs sprint grooming and planning meetings when we need to take an aside and a product owner needs to verify how an existing functionality works, (sometimes they know the answers immediately, sometimes they do not).
I do not think there is any golden bullet to resolve our dispute, but the right solution is probably somewhere in the middle. You need good business rules outlined for an existing product in order to correctly meet the functionality, but you want to stay flexible to handle dramatic changes in business rules and functionality.
To stay Agile, there is a need in an organization to do analysis to identify the best places to produce internal documents to consume the existing established product, without introducing a degradation to the development life cycle.
My experience tells me that more design, testing, and understanding of requirements earlier is better and cheaper, while waiting for any of these can cost more.
My instincts tell me that perhaps the paradox of the situation: developing an application ported from an existing marketplace product may not be a perfect fit for pure Agile development approaches (or at least those in the opinions of this scrum master), without an adjustment to the way an organization executes that Agile, applying it to more than the development of the delivered product from within the SDLC.
Maybe I am way off, what do you think?
President at World Building Academy
9 年Speaking as a former business analyst, among other things, I think you're spot on. As to Agile's adaptability to other uses, it is intended to be that flexible; its creator wrote in a book about it that he uses it in many other functions and his wife even uses it to manage their "honey do" list at home! It's a flexible methodology, not a single-use tool. If you have the leverage to make it happen, I'd say get an analyst. One with Agile experience should have the right perspective to grok what you're grappling with.