Why Software Size and Effort Estimation Continues to Haunt Software Projects?

The profit margin one is expected to make in a software project is a function of the productivity one expects to operate at and the cost that would be incurred at that level of productivity.

Accurate and precise estimation of software size and effort estimation has remained a key barrier in estimating the productivity of software projects.

In some sense, software size and effort estimation continues to haunt software projects.

Finding the "silver bullet" method for estimating size and effort is akin to finding a drop of water one can drink while one is stranded in the middle of an ocean.

Almost impossible.

Looks like that.

However, that's not true.

Size and effort are simple but powerful concepts.

Size indicates the amount of work or the volume of work that needs to be performed.

Effort indicates the amount of work hours spent to generate a certain size.

And by definition productivity is the size generated for a unit of effort spent.

Very simple.

The key consideration however is that effort should use the size information.

That makes the whole game of estimation interesting and hard.

So how to estimate size?

There are many ways like function points (FP), kilo source lines of code (KSLOC), situation-specific complexity points (CP), number of requirements, number of pages, number of test cases, etc.

It is better to use FP since there is lot of literature available on it in addition to the support system available.

Once size information is available how to estimate effort?

Effort is based upon size as well as additional factors like complexity of work, competency of the person performing the work, effectiveness of project management processes and controls.

All the above factors do somehow get captured in the concept of productivity.

So effort can be estimated from size simply using productivity figures.

Many organizations never get started with the above methods due to several reasons like poor understanding and incorrect notions regarding the industry methods, lack of will, lack of ownership.

In fact, in some of the organizations, there are some "dummy experts" on estimation who think they know more than those who are recognized in the industry as experts on estimation.

The dummy experts end up creating an estimation framework that is neither usable (the method is over-engineered and with too many layers of details after details) nor useful (the estimates that get computed by using the framework are not realistic and hence of no use in real).

On top of it, the experts do not own the future maintenance and enhancement of this framework.

Lack of any effort on sustaining the framework is like slow poison that kills that framework eventually.

The whole thing may happen with lot of fanfare but meets its natural death at some point in time.

So what to do if nothing works out?

If nothing works out, the best bet is to create a very very granular WBS (work breakdown structure) or PBS (product breakdown structure) or a combination of WBS and PBS.

Effort for the WBS elements can then be estimated based on the volume of work at the WBS element level.

That brings the flavor of size being estimated followed by size information being used for deriving effort estimates.

All said and done, estimation is a hard nut to crack.

And while you are at it, trying to crack it, it may make you go nuts!

What has Happenled to the Good, Old Agile? Is it Dead Now?

Agile was supposedly a very good approach and a highly promising one when it came in several years back.

And it appeared as if the software world had finally found the "silver bullet".

But that was not to be.

What has happened to the good, old agile? Is it dead now?

The die-hard agile enthusiasts always used to write it as Agile (with capital A) but now they don't mind using agile (with small a).

This is a seemingly simple yet a very powerful change.

Agile originated with its own peculiar contradictions.

This is clearly reflected in agile manifesto which has undoubtedly been crafted very beautifully but has an adversarial tone.

For example, saying "people over processes" has a fundamental flaw. Both are important and the right approach would be "people using processes".

It is important to always remember that "processes" are created by people and have no intelligence of their own other than what the people defining the process put into them!

So if there is any issue with the process, it should be fixed by the people who are supposed to use it and by those who are responsible for maintaining it.

Also lack of commitment to the process and the needed competency to follow the process should not become excuses for giving a bad name to the process.

Never forget - process by itself is completely dumb!

People, however, should not be dumb. By not following a process they act like one.

A process is simply a path you take to go from one state/place to another state/place.

The key success criteria as you travel on the path as captured in the process are related to certainty and consistency of the outcome.

In the software world the biggest challenge has always been this - most of the practitioners undermine the value of a systematic and structured approach to writing software.

Writing software is seen as a creative activity like painting or sculpture. That is not totally right. Writing software should be seen as an engineering activity like building a bridge.

The initial part of the software writing which has to do with software architecture does involve some creative thinking but this needs to be necessarily within the boundaries set by technical feasibility of the proposed solution and the business context where the software will eventually fit into.

More than a software development approach, agile became a symbol of anti-establishment and its premise was primarily to correct what was wrong with the traditional approaches.

There were many traditional approaches when agile came in, but waterfall symbolized this so called "evil" affecting the software world and became a favorite punching bag of the agile enthusiasts.

The other issue with agile has been too much focus on rituals. Statements like "if you are not doing daily scrum you are not doing scrum" cause more harm than benefit.

Blind insistence on following rituals and minimal or no willingness to accommodate appropriate tailoring in accordance with varying situations in each project can result in process rigidity.

At the same, allowing too much of flexibility under the garb of "being agile" can lead to lack of a basic operating structure and eventually chaos.

The best approach is to mandate a certain core structure and set of practices that give a solid foundation.

Examples would include the following - having a plan/WBS, insisting on weekly status reviews (details of the how can be left to the judgment of the project team).

The remaining processes and practices should be evolutionary and should be adopted to ensure the objectives of the project are met.

There also there should be extensive guidelines and operating procedures that can be leveraged by customizing them appropriately in line with the project-specific needs.

The good, old agile may be dead.

Or may be not.

Because even before agile came into being there where many approaches with a similar philosophical outlook like incremental, iterative, spiral, etc.

The term agile was surely new but the underlying principles were not.

Since agile was never born, it will never die as well!

The core objectives of any engineering endeavor (quality, scope, time and cost) as well as the fundamental principles and foundational elements of how to do good engineering including writing software has been there since centuries.

And they would not undergo any change. Why should the basics change?

Collecting Accurate Software Development Process Data

Question - how do you improve a process?

Answer - collect data and analyze the collected data!

Unfortunately, the real answer is not as simple as above.

The real answer is - collect accurate data, rest is pretty easy to figure out!

In fact, the answer is far too complex than even the above, especially when it comes to software development processes.

Tooling and automation, artifical intelligence, machine learning, cognitive science, etc. can supposedly turn software development into a machine-driven process.

However, the current reality is that software developement remains a highly human-driven process.

For human-driven processes, availability of highly skilled and highly motivated people is a sine-qua-non.

And that makes collecting accurate software development process data and using it to improve software development processes extremely challenging.

It is useful to collect the following data in a software project to manage it effectively and to improve the processes employed.

• Size - how big is the project? how much work needs to be done?
• Effort - how many man-days are needed to develop the software?
• Schedule - how much calendar time will it take to ship the software?
• Cost - how many dollars will it cost to build the software?
• Defect - what is quality level of the software?

The foresmost observation anyone with a keen eye will make - all the above depend on subjective judjment of the person performing the related activities.

The above statement is a stark reminder of the challenging fact that collecting software development process data is extremely difficult.

It violates the necesary conditions to get accurate data.

Condition 1 - Method and instrument to measure should be such that it can be benchmarked against a standard method and instrument. 

• Temperature is measured in a consistent manner in terms of degrees centigrade using a thermometer.
• Of course, need for calibration cannot be overstated in this context.
• However, software process data like effort is measured in man-days which is very vague thing.
• There is no standard benchmark for how many actual working hours constitute 1 man-day of effort.

Condition 2 - Entity measuring the selected parameter of a process should not be the one performing it

• Entity for measuring can be the instrument or device used for measuring the selected parameter.
• Temperature is measured using a thermometer. In an ideal scenario, the temperature gauge should operate without manual intervention.
• However, software process data like effort for an activity is reported by the very person performing that activity.
• The person performing the activity is also the entity measuring the selected parameter of the process.
• This is quite strange and can never be expected to provide accurate data.
• Why would a person not want to cautiously hide bad things and clamoursly highlight good things?

Despite the above challenges, there is a strong business imperative for measuring software development processes in a commecial context.

Software developement should not be seen as an engineering activity performed by the developer but as a business activity performed for the customer.

The above also implies that, software development processes need to viewed like any other business process.

So until ntil ways to address the above two conditions are not devised, collecting accurate software development process data will remain an elusive goal.

Scaled Agile Framework

Using agile in a scaled up mode is yet another way which can help organizations build and constantly improve upon large and complex products and services.

By definition, large and complex products require cross-functional teams of engineers working for long durations.

Use of agile in a scaled up mode also necessitates the right kind of culture to be instilled and the right kind of roles and reporting to be put in place.

The cultural challenges that ail organizations trying to use agile also ail those trying to use scaled up agile, in fact far more severely.

There are many scaled frameworks that have been proposed and are available for an organization to explore. Some of the scaled agile frameworks are:

• SAFe (scaled agile framework)
• Scrum of scrums
• IXP (Industrial eXtreme Programming)
• Nexus
• Nexus+
• DAD (Disciplined Agile Delivery)
• LeSS (Large Scale Scrum)

Out of the above, SAFe currently appears to the most popular one. The support ecosystem which includes the availability of reference material, consultants, training, certifications, etc. around SAFe has helped greatly in this cause.

SAFe 4.0 for Lean Sotware and Systems Enginering is the most latest version of SAFe that is available to interested organizations.

Versin 4.0 was released in Jan 2016. The previous version, version 3.0, is slated to have its end of life in Dec 2016.

SAFe is purportedly based on and leverages the following frameworks:

• Scrum
• XP
• Lean

SAFe defines the following levels, where each level builds upon the levels below and serves a higher purpose from a business point of view.

• Team (iterations)
• Program (program increments, agile release trains)
• Value Stream (lins of businss, typically)
• Portfolio (capital allocation decisions)

The foundational elements in SAFe include:

• Lean agile leaders
• Communities of practice
• Core values
• Lean agile mindset
• SAFe principles
• Implementing 1-2-3

Software Size and Effort Estimation

Software size and effort estimation has been a keenly debated subject since the last few decades in the IT/software industry.

The concept of size is related to the "amount of work that needs to be done" and not "what it would take to get the work done", which is actually related to the concept of effort.

The "amount of work that needs to be done" is a reflection of the output whereas "what it would take to get the work done" is a reflection of the input.

Many a times this distinction is either misunderstood or forgotten as an estimator goes about estimating.

Estimators, especially the star ones, are certainly experts in a specific domain.

However, this expertise, makes the estimators think of themselves as technical wizards and masters of engineering magic. And therein lies the core problem.

One challenge in estimation is related to the process or the method aspect.

Star estimators would directly estimate the effort using a task or work breakdown structure. Putting effort against the various line items and then adding it all up they come with the effort estimates.

So what's really wrong with this?

There is not one thing that is wrong with it, there are several things that are wrong with it. Here are some of the major points to ponder about:

• How can anyone say how long it would take to go from point A to point B if they don't know the distance (size attribute in this case)?
• Of course, the time taken is not only a function of distance and depends on other factors too like the traffic conditions, mode of travel, driver skills, etc. but they vary unlike distance
• The "amount of work that needs to be done" shouldn't change at a fundamental level but "what it would take to get the work done" can change with changes to the climate variables
• Effort for creating a size depends both on the size as well as the conditions under which the size is getting created which includes factors like complexity, productivity, team competency, dependencies, assumptions, etc.

The other challenge in estimation is related to the people aspect which is worryingly much more influential than the process aspect.

Estimation in any organization is done by the the supposedly "wizards of technology". These are folks who are the blue-eyed boys of the management.

After all, they are the ones who help win business deals. Only they can create estimates and proposals and bedazzle prospective customers with their technical and domain skills to bag the project.

So who would question such estimators? Anyone? Did you say the management? Well you know the answer, you really do know. No one!

So unless the star estimators take lead in using size estimations, it will not happen. And they will not do it because it will force them to adopt a scientific and structured method and expose them to a lot of necessary criticism.

Keeping things fuzzy helps them maintain their star status.

In some organizations, the proposal-time estimates are not tracked throughout the project along with the revisions on the way that are necessitated by change requests.

And the most surprising thing is that in such organizations the star estimators have no compulsion to or interest in asking for the actual data on size and effort at the end of the project to compare and analyze the deviations against the estimates of size and effort.

Only when a project goes horribly wrong does the management say something. Of course, they can't say anything to the star estimators directly. Why? What if they leave?

So the management puts up a committee or task force to  improve estimation practices. None of the star estimators is made the head of this task force.

The head is made from another group so as not to ruffle the feathers of the star estimators. Why? Again, what if they leave?

Unless the people angle to estimation is not addressed the maturity of size and effort estimation practices will continue to remain in the state it is currently.

Agile Development Timeline

1986 - "approach similar to rugby" for commercial new product development Takeuchi, H. and I. Nonaka, "The New Product Development Game", Harvard Business Review, 1986 (January-February).

1991 - use of the term Scrum (term of rugby) for the "approach" DeGrace and Stahl, “Wicked Problems , Righteous Solutions”

1993 - Scrum used at Easel Corporation by Jeff Sutherland

1995 - Scrum paper presented by Jeff Sutherland and Ken Schawaber in OOPSLA'1995

1996 - XP used at Chrysler by Kent Beck

2001 - Agile manifesto signed by 17 original signatories

Is Agile Really Better than Waterfall?

The simple and short answer to this question is "No".

There is no single methodology which can claim to be a panacea for the problems faced by software projects.

Evolution of Agile

Agile methods like XP, Scrum, FDD etc. have evolved based on the principles enshrined in the Agile manifesto which supposedly came into being as a result of frustrations experienced with the Waterfall method.

Agile has become quite fashionable since the last few years and as the die-hard Agile fans would love to hear "Agile takes care of all that is wrong with the monster named Waterfall".

However, reality is far removed from this statement.

One thought that often comes up is related to Agile and Fr(agile) and does accept the fact that Agile has its own set of challenges and shortcomings just like Waterfall or any other methodology.

In fact, in many ways Waterfall is much better than Agile and as some might say Waterfall Model, Original and Forever.

The "Waterfall"  Concept

Waterfall is based on the concept of staggering as it advocates starting an activity only when its precedent activities have been completed.

Agile is based on the concept of parallelism as it advocates performing all activities in parallel without bothering about their precedence relationships.

Agile approach is better when the product or technology is a new or innovative one and changes to try out several permuations and combinations is budgeted in its cost.

However, no organization can provide infinite budget for any project and hence projects are forced to do upfront planning to the extent they  have visibility.

On this front waterfall wins hands-down.

Agile says changes are welcome.

Waterfall also says changes are welcome but adds that changes don't come free of cost.

This is a good incentive for customer and developers to think through and ensure the high-level requirements and overall architecture is laid down before coding and testing.

The Agile Concept

In Agile method estimation, planning, requirements and design documentation, test planning, meetings, status reports are viewed as overheads.

And the focus is on delivering the working software to the customer day in and day out (or rather sprint in and sprint out).

It follows from above that Agile is focused on coding, testing and bug-fixing.

Code is continuously spewed out by the project, tested against the requirements and changed either due to design and implementation issues or due to changes in requirements.

Code changes are effected through re-factoring which essentially amounts to re-design and re-coding.

In this process the overall architecture is not focused upon and evolves along with the requirements.

This may lead to weak architecture and impact non-functional requirements like performance, scalability etc.

Waterfall versus Agile

It can be concluded that Agile seems to focus on the short-term at the cost of long-term.

For complex projects done by big, distributed teams Agile requires much higher rigor and discipline that what is advocated by the Agile purists.

In such situations Waterfall is a better choice.

It is also a fact that no one uses pure Waterfall.

Intermediate deliveries have been a common practice in case of Waterfall projects as well.

In the end, Agile seems to be more of a marketing ploy than just a well-grounded method.

It attempts to make a virtue out of lack of discipline by suggesting that trying to get upfront clarity in the requirements and approach in the beginning, to the extent possible but limited by visibility and constraints, is futile as they will change.

Thinking hard and having a good plan while remaining open for changes to the plan is a better stratgey than the above. 

Since, as is commonly accepted, well begun is half done.

In conclusion, it can also be said that "well planned is half execcution done"!

Agile and Fr(agile)

Imagine you are a building contractor and a person wanting to build a house comes to you. He tells you he has a piece of land on which he wants to build a house but he doesn't know what kind of house he wants. What approach would you take?

Approach A (Agile):

• You get your team to start digging the ground from next day 
• You are told by the person who wants that house (your customer) what he really wants on a daily basis (almost) 
• You don't know how many floor and rooms your customer wants until he himself knows and chooses to tell you 
• You are ready to re-do the brickwork as many times as the customer suggests changing the size and location of the rooms 
• You team meets every morning and discusses what they did yesterday and what they need to do that day
• Your team works without any blueprint but talks very often 
• You start building a wall and stop when the customer and team members feel it looks wide enough

Approach B (Traditional or Waterfall): 

• You make sure the requirements are known to a reasonable extent before starting the digging 
• You work with the customer to crystallize the requirements to a finer degree as the construction progresses You agree on the structure and overall design such as the number of floors and rooms 
• You are flexible but in a disciplined way, changes are welcome but done based on techno-commercial feasibility analysis which becomes more and more formal as the number of walls and rooms increases 
• You meet as and when required (and periodically as well if it makes sense) but the discussion is not only on yesterday and today but also what is needed to deliver the house to the customer as committed while ensuring your margins remain intact 
• Your team talks and also refers to critical guiding documents like the blueprint, electrical wiring layout, etc. You know the exact width of a wall before the first brick is laid

Approach A versus Approach B - Is Agile Really Better than Waterfall? Or is Waterfall Model, Original and Forever?

If you are a contractor you will most likely prefer approach B. The first approach is what would be an agile approach. It may work perfectly well but the change dynamics will make every day a challenge. This approach has an inherent fragility where it is difficult to predict what kind of house will emerge finally. It is possible the customer gets his dream house but that will depend on nothing going fundamentally wrong until the very end. At the same time the contractor may not be able to protect the profit margins because of too many change cycles. The second approach is what would be a traditional approach. Here the customer needs to know a great deal about what his dream house is going to be like and in case he was not right in his assessment of what a dream house means for him may end up not getting it. In this case the contractor may be very well able to protect the target profit margins.

Now consider what would you prefer if you are the customer? But obviously approach A. Isn't it interesting? As a customer you'd want maximum bang for your bucks and you'd love to get every change in your mind implemented till the last day at no additional charge. Besides, no one can blame you for not thinking hard through your requirements in the beginning because in this kind of agile approach you not supposed to do that.

Using Waterfall and Agile Together or Using Whichever Seems More Appropriate

Agreed there are situations where the final solution emerges through experimentation with alternative approaches (especially in emerging technologies where the behaviors are still not fully understood). In such cases being agile during the solution building process has its merit. However, even in such scenarios at some point in time the solution needs to be pinned down and taken to its conclusion. The fragility in such situations is a natural outcome of not understanding how a particular approach will work but needs to be frozen nonetheless to deliver the final solution.

Agile though fragile has its own advantages. The closeness between the two words agile and fragile is an interesting co-incidence. For any new technology though the initial work may happen using approach A there has to be a constant attempt to migrate to the approach B so that predictability and profitability is assured. This is crucial in a business context. For research, academic, first of its type, prototyping kind of work approach A (agile method) is probably a right choice however the inherent fragility in this approach has commercial implications and needs to be frozen to move towards the approach B (traditional method).

P.S.:

The adoption of agile methods in software development is considered to be a kind of revolt against the heavy, plan-driven, waterfall-like methods and models. It is clear however that these two approaches complement each other. If you are sure go traditional, if not go agile but try to be sure rather than not.

Waterfall Model, Original and Forever

The not so positive perceptions which have been created around the waterfall model have probably to do more with the lack of understanding among the software professionals than anything else. It is interesting to note that every model and methodology which has been proposed has always been defined against the backdrop of waterfall model - either as its derivative (like V-model, incremental, iterative, etc.) or as an alternative (like agile, etc.).

It is also interesting to note that the description of these 'new' and supposedly better models and methodologies has been around how they have managed to address the shortcomings of the waterfall model. The above discussion seems to have reached a new height with the advent of the agile methodology in the last decade (the agile manifesto came into being in 2001).

Agile has been proposed as an alternative to the supposedly 'heavy' waterfall model. Lot of discussion has been about how agile will eventually replace waterfall. In all this discussion the key message seems to have got lost somewhere.

• The first and the most fundamental question is "why is software required in the business context"? Is it for the creative satisfaction of the software developer or serving a business need of the software user? It can be safely assumed that is is always the latter that any CEO will agree to and for very obvious reasons. This basic understanding clearly implies that a software project is meant to deliver business value to its customers.
• The second question is "can we ever develop perfect software"? Ideally one would want that to happen but based on pragmatic considerations this is like being able to count till infinity. It follows from here that some bugs will remain and more importantly the customers will be willing to tolerate it subject to considerations of applicable laws and regulations, safety, reliability, availability, functionality and value for dollar spent to procure and use it.

Combining the above two aspects one would arrive at the conclusion that software is for a customer and its value should be as defined by the customer. The software must operate as it should and in case it doesn't and fails it must fail safely. And this is a fair expectation from not only software but any product or service which is there in the market.

Would one be happy if the meal offered on the flight is cold and stale? or worse the pilot informs that the fuel tank has been leaking and the plane is going to crash? The answer to both is no, however the second no is much more serious case.

Drawing analogy to the software domain would one be happy if while working on a document the software freezes and one has to reboot the machine and looses few lines of data? or worse while making an online payment one's credit card details are stolen? Again the answer is no with the second no being more serious than the first one.

Waterfall should be looked at as a concept that promotes efficiency. The essence of waterfall is zero rework. Once a phase is complete it never gets revisited and that means no rework, which means higher efficiency. Waterfall concept assumes that the most efficient way to do software is to do it right first time.

Living up to pure waterfall approach is extremely difficult as human mind hasn't evolved to the level where the intended system behavior can be understood perfectly at the start (as this involves two subjective factors - humans talking/writing/reading in a language like English which is not based on scientific principles) or the exact on-field behavior of a system at the architecture and design stage predicted with absolute certainty. And then there are natural reasons like new technology, new regulations, new concepts, new thoughts etc. which might trigger changes to the original system requirements and design.

Use of a pure waterfall approach was never the case even in the past. Even in the so called waterfall projects design changes to take care of issues and defects observed in end-stage testing is not an unheard phenomenon. The preparation of a list of "known issues" that usually gets bundled as part of the software package for release is a very common practice. The firefighting projects pass through at release time is also a common occurrence.

These examples demonstrate that a pure waterfall was never and can never be followed. No one would, however, disagree with improving the way software gets developed and the constant attempts to reduce the cycles of rework and minimize the list of "known issues".

Taking this one step ahead, use of iterative, incremental, spiral and agile can be seen as essentially doing waterfall in short and repetitive cycles with overlapping and parallel phases and activities, as the case may be. Especially in respect of agile one must consider the answers to some key questions:

• Is agile an original concept? not really. It is not fundamentally different from the decades old concepts of incremental, iterative, spiral development
• Is agile valid from a scientific or conceptual standpoint? not really. The agile manifesto tends to view software development work as an art and not science. Even conceptually it seems to encourage rework over solid understanding of the customer's need and the proposed solution right at the start (evolution in understanding can't be considered as an excuse for not applying scientific methods at the start to gain as much understanding as possible in a cost-effective and pragmatic manner)
• Is agile the proverbial silver bullet? not really. Every model and methodology has its pros and cons. However, the ultimate acid test for any model is the business value it helps to create for the end customers. One may use use different model at different stages of the project as is the most appropriate.
• Is agile 'the model' the software industry was waiting for? not really. It is one of the many models that have come up in the last and newer ones that will emerge in the future

Agile is essentially about recognizing the importance of convenience and flexibility while developing software. The whole idea in agile revolves around doing what is really needed and accepting that many factors are not in control or need to be evolved (due to the limitation of human mind, time and money constraints, etc.).

These assumptions are no doubt very real but may end up becoming an excuse for complacency or not pushing the envelop. At the same time, the need to work better and better every time would mean certain discipline is exercised to ensure revisits and consequent reworks are minimized in line with the waterfall concept. What is probably the need of the hour is to have a hybrid approach that combines the best of various models varying the flavors as the customers want it.

The concept behind waterfall is going to remain relevant and important forever. The waterfall model is the original one and must be adapted in whichever way it might be, with a new name if that helps improve software development (agile or whatever).

Agile

Agile methodology emerged as an alternative to CMMI and other "heavy" frameworks. The perception of "heavy" evolved due to the excessive (or supposedly excessive) volume of processes and documents that are needed to demonstrate compliance to the "heavy" frameworks. The evolution of Agile can be traced back to Lean or Lean Manufacturing methodology that is commonly used in manufacturing companies.

Though Agile came from the software industry, it can be applied equally effectively to non-software product development also. Generically speaking, process agility is important for companies in all sectors of the economy.

Agile relies on continuous development, integration and testing to ensure software development is done according to an adaptive approach. Interaction between the developers, testers and customers is encouraged to ensure fast-paced development.

Agile is effective in the development of products which use emerging technologies or provide "novel" features as they involve lot of research and analysis to finalize the product features and low-level implementation details. On the other hand, the typical commercialproduct development prefers predictable and speedy execution and hence relies on` proven methodologies and technologies. In such cases CMMI-driven approach may be a better choice.

In the recent years, attempts have been made to evolve a combined and integrated approach to apply both agile and CMMI together. Supplanting Agile concepts on a CMMI implementation is an effective way to reduce the burden associated withproduct development.