Our approach to software development (1 of 2)

Background of software development processes
These days, there is a lot of hype about Agile and the processes that are Agile-like.  To many people out there, Agile means “get it done quick”.   This belief is warranted because what Agile means to developers is to receive a requirement and create that requirement.  In other words, do the best that you can with the limited knowledge you have, and put it out there.  This is different from the traditional method of software development where Project Managers, Business Analysts and Subject Matter Experts would spend endless amounts of time in a room to drum up an extensive requirements document for developers to follow.  These developers, in turn, would spend an exorbitant amount of time combing the document for problems and sending the document back for corrections.  This processes would repeat itself throughout the development lifecycle, over and over again.
The traditional method fails because software development took too long to get results, and when there results were finally achieved, the cost of being wrong was large and scary.  The Agile methodology allows development and business partners to attain results quicker, which can then be refined at a much cheaper cost.  This has been a welcome change for both development teams and business partners.  So what is the problem?
The Agile process is designed such that the Agile lead, or Scrum Master, assigns each developer to a two-week feature, also known as a Sprint.  Every day the developer is asked about the progress they made and the Scrum Master tracks to make sure the feature will be done at the end of two weeks.  The additional job of the Scrum Master is to ensure that each feature is broken down small enough such that it can be achieved in two weeks, and if not, the feature is divided into smaller units that do fit within two weeks. The weakness of following a true Agile methodology is that success is measured on the delivery of individual features rather than taking a look at the solution as a whole.  Therefore, what you get is a bunch of custom features that work individually, but ultimately the system misses the cohesiveness of a system that was built a single focus in mind.  In the automobile world, this would be akin to taking parts of different cars – say the doors of a Ferrari with the grille of the Audi, the engine of a Honda and the transmission of BMW.  These are all decent parts in themselves, but they would make of an awkward car.
However, the bigger problem with Agile is in the objective.  Firms which simply focus on Agile are following incentives to produce features.   Yet, technology provides no value on features alone.  Technology provides value when it solves problems.   The Agile model does not consider whether the business problem that the technology is designed to solve the problem.  Rather, there is an implicit assumption that the features added will solve the problem. There is inherently no focus on the problem.  As well, Agile projects can also begin without even an understanding of the problem being solved.
Software Logic has recognized this weakness.  We have responded by perfecting – what we call – a hybrid process of traditional and Agile methodologies that extracts the best of all worlds.  In our next post, we will go in further to define how we go about doing this.

Neville March 31, 2015 AT 03 pm -

I do exactly the same. I helped form Agile Scrum back in 95, and it was never meant to be “quick development with whatever analysis you have on hand”. Glad to see someone else figured it out.