We have all seen how the Software development process has underwent an evolution in the last few years. The evolution came up with the introduction of agile methodology which aims to add swiftness to the process of overall development and at the same time challenge the well established traditional engineering practices.
The waterfall model was treated as inadequate by various categories of developers during the 1990s, resulting in the evolution of the new change based approach contrasting in nature with respect to established development principles.
Software development is based on coding, testing and fixing without a definitive underway plan based on rapidly changing decisions. But as developers we know that the problem arises when we are required to deal with enhanced system size, growing code defects, and overall complexity. When we are required to test such complex systems we require longer time which eventually disturbs the schedule of activities. To deal with this problem, disciplined methodologies were introduced so as to make the software development process more synchronized and efficient with respect to timing, development, testing and delivery. The methodology laid great emphasis on planning – just like other engineering practices. The methodical treatment of software development was a successful attempt in streamlining and productivity enhancement. The issues associated with them relate to bureaucratic operation and highly structured operation which slows down the pace of development.
Agile developed as an answer to the bureaucratic engineering practices of the traditional approach. Based on continuous change of the requirements process, Agile involves all the stakeholders with the development team, throughout the software life cycle. Agile realizes that it is difficult to predict requirements at the beginning of the development process and new requirements emerge due to missing features, better understanding of actual needs which differ from the originally scoped need, changing business models and changing markets, or major defect rendering the earlier scoped requirement as obsolete.
The Agile Manifesto
Signed in 2001, agile manifesto involved a number of methodologies under its umbrella such as Scrum, XP, FDD, DSDM. Original signatories of the manifesto included Kent beck, Mike Bedle, James Grenning, Jim Highsmith, Jeff Sutherland among others. The agile manifesto laid out that a better form of software development process is being uncovered which values:
- Individuals and interactions over tolls and processes
- Working system over heavy documentation
- High degree of cooperation between customers over contract
- Embracing change over a disciplined plan
Dynamic Forces Prevents Predictability of Software
Earlier followed engineering practices of software development relied on planning of the software process in great detail for a long time duration, so any changes which came midway was resisted. The plan laid a predictable scheduled with respect to time and budget. Software development involves major effort in the design phase, hence requiring creative people. Creativity cannot be planned making predictability impossible in software development. The agile nature is adaptive, as it welcomes changing requirements. To limit extreme changes, it is essential to do a thorough requirements engineering and completely understand the complete picture before beginning the development process
Having talked about agile evolution I would also like to touch on software estimation which is an equally important subject in the process of software development. Software Estimation is as difficult as any design activity due to a high degree of uncertainty surrounding the scope, plan and cost. I have always stressed that software estimation cannot be an exact science. Any development firm should always understand that software estimation is more about approximation and doing the closest approximates in shortest time. Estimation is not certain and can change with different phases of the software development lifecycle, due to the changing nature of design and different measures of creativity involved which is difficult to quantify and foresee in the very beginning. Valuing the software features is difficult as the true value is defined only after release of an early version. Business and changing markets keep modifying the value of an introduced feature. All these factors establish that predictability in software estimation is not possible in the dynamic business scenario.
Answer to Unpredictability
Agile or iterative development is the answer to unpredictable scenarios in which software demand and development operates. This involves producing working systems within a defined time period which are a subset of the final systems that should be completely integrated and tested just like the final software. By producing the working models, a real test of the project with respect to actual requirements can be done against simple documentation which can conceal errors in code which remain untested. Actual working with software puts all bugs into direct perspective. Adaptive process which involves change in required features requires an iterative development process where short term plans are stable leading to iteration and changeable long term plans which depend on the success and feedback of short term plan. The iteration should be of short duration (varying depending on different agile methodology) and provide a basis for future planning depending upon feedback after the iteration.
Software Estimation in Agile Model
I have already talked about Agile and its evolution. I have discussed why the software development process cannot be predictive as the basic starting point of software development –software estimation is surrounded by unknown variables, uncertainty, hidden risk factors and review/change of requirements (as per business/client feedback).
Fixed price contracts cannot be applied in the agile development process as stable requirements produce a software which might not have a business sense for the customer, and if they don’t pay they lose that way too! Same goes for the development firm too. Hence an ideal approach should not limit the time, scope and budget of an agile development model. In practicality time and price is kept fixed while scope is kept variable in a guarded manner. Since an agile project involves variability in all phases of development, software estimation has to be in a phased manner and not outright in the very beginning. Again since customer involvement is quite high in agile development model, as the customer is empowered to provide user stories, set priority for delivery of features, and provide feedback to uncover real requirements, requirements can be thoroughly broken into story points for producing most accurate estimates. Software estimation in Agile set-up is collaborative in nature.
Process of Estimation in Iteration
I recently came across an article in HBR which said that the primary step before estimating an agile project is to define the objectives surrounding the software project. As developers, we should be clear about whether we need to start or leave the project; what should be an ideal productivity matrix of the team and the need to hire or outsource people, the priority level of different functionalities to decide coding priority, etc. Deciding upon the objectives should be prior to beginning estimation process. You need to make a thorough description about what the first iteration needs to achieve and so on for every iteration and then estimate for it.
Every functionality/user story needs to be broken into the most granular format – every user action which creates a trigger into the system should be listed. If for example an online retail clothing store is being designed, the functionalities should include:
- Search categories
- Quick View of products
- Manage product List
The functionality should be further broken into more detail, so categories would have various types of products listed by gender, age, types (clothes, footwear, accessories, etc). Every minute detail should be estimated for on time and cost, so in the end we get a detailed description of the functionality being estimated for the time and cost of its coding providing a sum total of the overall cost. The last step would be a feasibility check up of whether the overall estimated cost of the project is acceptable to the client to kick off or is there a scope of re-estimation. Doing away with certain functionalities which are preferable but not essential might lower the budget.
The overall estimation and re-estimation process requires time and effort. Using estimation software comes handy in this situation. It enables estimation in a standardized manner and quickens the estimation process. Manual estimation eats a lot of valuable time and different analysts may come up with different estimates. Besides, clients expect the developers to provide quick estimates with good accuracy. To synchronize software estimation in agile set up too, using an estimation tool is the best answer.
At Intelekit we have developed our unique estimation software –Quick FPA– which provides the quickest estimates and allows you to bid more and win more!! Register and get and invite for its demo!
“Manifesto for Agile Software Development.” 2001. 17 March 2015
Comnez Website 17 March 2015
“The New Methodology.” 13 December 2005.
Martin Fowler Website.17 March 2015.
“Your Agile Project Needs a Budget, Not an Estimate.” 29 December 2014.
HBR.org. 25 November 2015