Agile Or Incremental Software Development: Which Is Better?

[ad_1]

Introduction.

First of all, “which is appropriate?” would be a better question. The truth is that each software development method is appropriate in different circumstances. This article discusses my personal experiences with these approaches within Axios, and I welcome any comments or different perspectives. It’s fair to say that we use our own flavours of both of these methodologies so if you’re a purist you might want to look away now.

General considerations.

The first consideration when choosing a project management methodology is to recognize that software development has technical, creative and people management elements to it – each of these must be considered.

Whichever methodology is chosen must facilitate communication. This means recognising that the customer has the clearest vision for their business but will generally lack understanding of what is possible or what each requirement may cost. The software development firm will understand the technologies but need to keep this closely aligned with valuable business outcomes. This balance requires a meeting of the minds and a degree of trust.

Another key consideration to remember is that it is not cost-effective to eliminate all uncertainty and risk.

Instead, we need to plan what can be reasonably planned and have agreed processes for managing any other challenges along the way. A classic example of this is the customer wanting to change scope mid-way through the project. We all know it’s going to happen so it’s important to discuss up-front how this would be handled under each project management methodology. If it’s going to happen a lot, such as when the requirements are not well understood up-front, then this may actually be a primary deciding factor in which project management methodology is appropriate.

Creatively speaking, the more precise requirements are, the closer any developer will be able to reproduce them for a given number of iterations. This can be both a good and a bad thing – if the customer has specific requirements but doesn’t communicate them (or makes assumptions about what the developer understands about their business) then this will likely result in the customer being unhappy with the result because it didn’t accord to what they saw in their minds-eye. At that point remediation work needs to be carried out and there is the potential for a dispute about who pays for that to be done. Conversely, there are instances where getting too bogged down in precise requirements stifles the creativity of the developers or limits the potential for interesting feedback from end-users. Again, this may form an important factor in selecting the project management methodology.

The last major factor comes about through an almost paradoxical customer need for both certainty of cost and development time-frames, and the need to be able to flexibly change requirements on the basis of user feedback. Clearly, these requirements work against each other to a degree and the manner in which scope is controlled and changes are costed is crucial in determining which project management methodology will deliver a satisfactory project outcome. As I discuss in my software asset whitepaper (see link to our other articles below), the key to a successful custom software project is a return on investment. This cannot occur if costs are unbounded.

How we manage projects.

An overview of this approach.

Incremental

• Work is divided up into milestones (1-4 months of work)
• Detailed planning, design and risk elimination up-front
• Project is controlled against the plan, less reliance on ongoing management of opportunities and issues
• Outcomes are only as good as the detail in the design and the customer’s willingness to accept the developers professional judgement on everything else
• Possible to achieve these in a fixed cost/time-frame

Agile

• Work is divided up in to small sprints (2-3 weeks work)
• Focus is on visual prototyping and collaboration, project is controlled through feedback
• Keep iterating until desired outcome is achieved
• Outcomes can be as close to “perfect” as the customer desires if they are willing to keep paying for iterations, risk here is disappearing down an endless trail of redevelopment
• As number of iterations cannot be known up-front, fixed cost and timeframes are not possible

When does it make sense to use this approach?

Incremental

• Clear understanding of requirements up-front
• Customer priorities include fixed cost/timeframe, lower risk, higher quality
• Works under a diverse range of customer/supplier relationship “modes” (purely transactional or a long-term strategic/partnership style engagement)
• Examples include developing custom business systems, post-R&D product development

Agile

• Requirements are vague initially and are expected to evolve throughout the project
• Customer priorities include the ability to rapidly produce prototypes (for R&D or funding purposes), flexibility and responsiveness to market feedback
• Only works where the customer and developers dedicate resources, work closely together and do so as equals
• Examples include initial product R&D and development, highly creative projects or where many ideas must be considered/tried

What are the risks of using this approach?

Incremental

• Flexibility and responsiveness to changing requirements or ideas can be difficult to accommodate as they require extensive re-planning. It is often preferable to finish a milestone and complete changes afterwards
• Interpretation of vague requirements or designs can cause some friction if systems for dealing with these potential issues are not agreed upon in advance. It is also advisable for the customer to have a small contingency budget available to polish, refine or re-mediate any small areas of the system that don’t meet their expectations due to vague requirements
• There is a risk of disengagement between the customer and the developers during project work because less ongoing communications are required after planning. Processes are needed to ensure communication is frequent and not issue focussed

Agile

• Customers can labour “perfection” too much and end up with too many iterations and not enough functionality for their spend – there is a need for restraint here
• As every hour is billable and exposed to the customer there is a danger that the customer will resent “paying for bugs”, that is any work touching up something that wasn’t delivered exactly as they imagined it the first time every time. It is necessary to understand that iterations are not bugs but an essential part of this style of development. Even where testing and debugging time is required this is no different to this being costed in to an incremental/quoted project

What is the rough process we follow and how is the customer involved?

Incremental

• Possible consulting up-front to ascertain business requirements
• Functional requirements, screen designs and program workflows for a stage of the project are extensively workshopped with the customer, documented, costed and signed off
• Development begins against the plan, progress/issues/opportunities are communicated with the customer
• Test builds are published to a server for the customer to look at and all job progress and feedback is coordinated through a customer portal
• Feature-complete builds are published for user acceptance testing and final changes
• Final builds are deployed to the customer’s environment and any ancillary support activities such as data migration, training and documentation updates are completed

Agile

• The customer will come to Axios with high-level requirements and/or mock-ups of the software required
• Axios may build a rapid-prototype to help everyone get on the same page around visual style, workflows etc – this would be the first sprint
• Frequent customer meetings to demonstrate progress and gather new ideas
• Development is always completed against feedback gathered rather than an overarching plan
• The final build isn’t so much planned as it is simply when the customer has no new changes that warrant paid work to be completed

How are resources allocated? Are there any timing considerations?

Incremental

• Resources required to complete a project are known up-front which allows them to be booked in and a delivery time-frame accurately planned
• Where scope changes would require more or less time (or different resources) than originally planned, this can affect resource allocations for other projects and Axios may be reluctant to do this unless it has under-utilised staff at that time

Agile

• Some customers are happy to lock in a monthly budget of hours in which case resources are assured
• Customers who are not comfortable locking in a monthly budget (and want to work entirely casually) may find that there are months where resources are not available and project timing is affected
• In either case, the key to using available resources effectively is good task prioritisation. Use the weekly/fortnightly meetings to ensure that work that has the greatest impact to the business is completed first, this may be work towards large strategic elements of functionality or simply responding to important user feedback or business opportunities

How is project success measured?

Incremental

• The planned functionality is delivered on time and on budget
• The functionality delivered meets business objectives
• The product quality is high
• Customer satisfaction is high
• Axios achieves these outcomes at a reasonable profit margin, enjoys the project, receives positive referrals etc

Agile

• The customer has benefited from the evolutionary approach and ended up with a product that is superior to what they could have based on forward planning alone
• Costs, timeframes and other commercial imperatives have been managed within acceptable boundaries
• The end product quality is high
• Customer satisfaction is high
• Axios achieves these outcomes at a reasonable profit margin, enjoys the project, receives positive referrals etc

How are these projects billed?

Incremental

• Up-front requirements and design consulting may be quoted or time and materials
• The project quoted cost is divided between a commencement payment and monthly progress payments during development and finalisation
• Variations, if agreed to be completed alongside as opposed to after the milestone, are billed time and materials
• There may or may not be subsequent milestones that were initially planned or agreed upon along the way that would also be quoted and billed in a similar manner
• Typically there would be a support and maintenance agreement commencing once the project is completed

Agile

• Monthly time and materials invoices for all time spent by Axios (note this includes project management, customer communication, testing, debugging etc)

Is the work guaranteed?

Incremental

• Where milestones are quoted and completed without variation, Axios warrants that it will fix defects without additional cost for 3 months after deployment
• Warranties do not cover enhancements, i.e. where the implementation of a vague requirement works but does not meet the customer’s expectations
• Support and maintenance plans can be used to extend these warranties

Agile

• All work on agile projects is on a “best endeavours” basis, that is we will change or fix anything requested but the time is billable

Who assumes what risks?

Incremental

• Risk-share model
• The customer assumes the risk that the specifications and designs agreed upon will meet their end requirements and are detailed enough so that the end product matches their expectations
• Axios assumes the risk that the implementation of those requirements into a technical solution can be achieved for the price specified – if we run over time delivering against the design we cover these costs

Agile

• The customer assumes all risks

How are variations managed?

Incremental

• Ideally variations are not entertained until after the current quoted milestone is completed and has passed user acceptance
• In urgent circumstances re-planning, design and quoting can be completed however this time is billable on a time and materials basis. Also, given the difficulty in tracing the root cause of bugs back to either being from quoted or variation work, we would typically insist the customer waived their warranty before entertaining this option

Agile

• Agile projects are ideally suited to dealing with variations as we are effectively working at all times under the customer’s direction and feedback
• Typically the customer would observe something they wanted changed, either as a result of a new idea, focus group feedback or a clarification of a design element, notify Axios, Axios then mocks up the changes, the customer approves them and they become part of the current or next development sprint

How are vague or unclear requirements managed?

Incremental

• We work under the assumption that where the customer has very specific requirements they will describe these and ensure they are represented in the design before signoff
• Where the customer is looking for our professional judgement and experience, the requirements may be less detailed and the customer should accept our implementation of these requirements as fulfilling our obligations under the quote
• If, during the warranty period, it becomes clear that our implementation of a requirement is inconsistent with the design, we will fix it without additional charge. Where our implementation works and is consistent, but does not accord with the customer’s unstated expectations, we consider this a variation
• As this is a creative process, and nobody can read minds, this will happen to a small degree in every project. We allow around ~5% of the quoted project budget to deal with very minor remediation work. We encourage customers to also allocate a small contingency budget to complete any additional polishing or refinement after the milestone is completed
• Remediation budgets can be minimised by making initial planning more detailed. This in itself is an overhead so striking the right balance is essential to avoid a false-economy

Agile

• Vague requirements are essentially variations in the agile context and are handled the same way

How are project issues worked through?

Incremental

• The most common issues with incremental projects are variations and how vague requirements are handled, these are described above
• All other issues are handled by discussing the matter and considering a win-win, or at least a proportionate outcome based on initially stated expectations
• Issue management is initially handled by the team leader but can be escalated to the production or account manager (depending on who is most suitable to assist) and finally the managing director
• Failing these approaches (which has never happened to date in Axios’ history) there are contracted mediation and arbitration processes

Agile

• All issues are handled by discussing the matter and considering a win-win, or at least a proportionate outcome based on initially stated expectations
• Issue management is initially handled by the team leader but can be escalated to the production or account manager (depending on who is most suitable to assist) and finally the managing director
• Failing these approaches (which has never happened to date in Axios’ history) there are contracted mediation and arbitration processes

How is collaboration and communication managed?

Incremental

• Collaboration and communication is intense in the early planning stages of each milestone/build
• Subsequent communication tends to be status reports, milestone demonstrations and raising any issues
• There can be an intense burst of Axios/customer contact at the end when the customer is performing user-acceptance
• Need to make sure the project team communicate successes and not just issues along the way or this can create the wrong customer perception – it is OK to report that there is nothing to report!

Agile

• Collaboration and communication is constant and typically done in regular demonstration/feedback meetings

Key take-away points.

There are trade-offs in choosing either the agile or incremental project management methodology. It is helpful when a software development company is capable in both, discusses them up-front with customers and works with the customer to select the best approach for their project. Without this discussion up-front it can be difficult to manage expectations and it is unlikely that the project would be seen as successful by all stakeholders.

[ad_2]

Source by Jason Goodridge