Agile Software Development

Agile Software Development - A Legal Perspective

Agile Software Development came to the fore as a concept in 2001 with the bringing together of seventeen software developers in Snowbird, Utah. All with a shared vision of how software development could be improved for supplier and customer alike. They distilled their views in The Manifesto for Agile Software Development. Among other values it called for “customer collaboration over contract negotiations”. While a potentially wince inducing statement for the conventional lawyer, Agile Software Development has nonetheless proved popular (it is not to be forgotten, however, that such alternative management styles had been experimented with since the 1950s – most notably in Project Mercury, the first human spaceflight programme).

Software development is often a creative and exciting moment for any business. However someone - usually that's the legal adviser - needs to join the party thinking about risk - how it should be apportioned and how it should be minimised.

Waterfall method

In order to understand the conceptual basis for Agile Software Development, it is useful to know what it opposes. The first formal description of the waterfall model is often cited as the 1970’s article, Managing the Development of Large Software Systems by Winston W. Royce, although the term ‘waterfall’ was not explicitly used. The waterfall model was presented as a flawed, non-working model. It is the waterfall model to which Agile Software Development is opposed.

Here is how the waterfall method usually pans out:

Specification requirements – Design – Coding – Testing and Error Detection – Integration – Deployment – Maintenance.

This is how a product is usually made for a customer i.e. the customer specifies what it would like, the supplier creates the product, the product is tested. Once the product passes the tests it is then integrated in the customer’s system, tested again then goes live. Having gone live the supplier usually then provides support and maintenance services to fix any defects in the software.

Agile Software Development - Flexibility

Potential disadvantages of the waterfall method include the difficulty for customers to define their requirements clearly at the outset and that in many cases it does not easily accommodate changes to these requirements made throughout the project. By contrast to the waterfall method, an Agile Software Development project does not have detailed demands for the end product at the outset, although overall project scope and goals are agreed. Flexibility is the core to agile projects as they acknowledge that a customer’s demands and priorates may change from time to time during the course of the project.

Agile Software Development -Method

Typical features of the agile method include:

  • The goal is to deliver functionality and business value to the customer. This means that the solution to business goals and needs cannot necessarily be defined from the outset. It is only the goals and needs that are themselves initially important.
  • The project is divided into a number of sprints, each has its own set of priorities and goals. At the end of each sprint is an approval process assessed by the customer.
  • Planning and review meetings occur at the start and end of each sprint meaning close communication is maintained between the two parties.
  • The customer will reprioritise its needs from time to time, based on its ongoing assessment, and communicate this to the supplier. This may mean that some of the original requirements may become redundant over time.

Terminology

Although Agile Software Development projects can run on their own terms, there is generally a set of positions and relevant terminology used:

  • Product owner – customer’s representative who acts as the first point of communication with the supplier. Key functions include understanding the business needs and organising the development tasks. They must be present at sprint planning and review meetings.
  • Development team – typically supplier personnel. They are responsible for enacting the development sprints.
  • ScrumMaster – focuses on the development team, its progress, removal of obstacles and quality assurance. Typically a member of the supplier’s personnel.
  • Stakeholders – representatives of the customer’s management.
  • Product vision – an explanation of what needs to be developed, focusing on business goals and targeted benefits, rather than technical solutions.
  • Product backlog – a prioritised list of the customer’s business requirements that are to be developed during the project term. These can be reset at any time with new ones added and old ones deleted.

Importance of the product backlog

Maintenance of the product backlog (described above) is a key part of the agile process. The business requirements contained in it and the priorities accorded to them steer the development of the software and testing/approval procedures. These needs are generally described in the form of user stories. Customers should therefore ensure that any mandatory data protection law principles or cybersecurity obligations are contained within the product backlog.

Agile Software Development Scrum

The software development term ‘scrum’ was first used in a 1986 paper titled The New New Product Development Game. The term is borrowed from rugby, where a scrum is a formation of players and is illustrative of teamwork. Scrum is an agile framework used for complex projects (sometimes called extreme programming). Here are its key components:

  • Sprint – a timeboxed effort in which development takes place.
  • Sprint planning – establishes sprint goals.
  • Daily scrum – each day during a sprint, the team holds a daily scrum, preferably at the same place and time, and not longer than fifteen minutes. The scrum is concerned with what each player is contributing to a present/future sprint and has contributed to previous ones.
  • Sprint review and retrospective – demonstrates the work from the current sprint and improve processes respectively.
  • As another sprint begins, the product owner and development team select further items from the product backlog and begin work again.

Legal remedies for a dissatisfied customer

In a waterfall-type agreement the customer can rely upon damages, termination or remedial work in the case of defects or delays. In the case of Agile Software Development it can be difficult to determine whether there is actually any delay or defect because the flexibility of the system means that either can be easily buried behind prioritisation or vague notions of acceptability. Meaning that a delay could be deemed unprioritised by a product backlog and therefore not really a delay or the lack of an accepted definition of acceptance could allow a supplier to argue that no defect exists. The informality of decision-making can also make it difficult to gather the relevant evidence in case of a perceived breach of contract.

Time limits

Time, whilst fluid under an Agile Software Development process, is also bound to sprints and usually given a deadline. In a standard arrangement the customer would estimate the project duration and the number of sprints. It is, however, the discretion of the supplier/customer as to whether or not to formally agree to such estimates. This will need to be negotiated before an agreement is reached. Whilst setting time limits may be tempting, it may also be the undoing of the whole purpose of an agile agreement, in that flexibility will seem undervalued. On the other hand, having some framework in place to ensure contractual remedies is by no means discouraged.

Liability

Here are a some risk areas to be aware of:

  • Not meeting specific requirements within the original timeframe may not necessarily be seen as a breach of the agreement (as they may be re-arranged in the backlog).
  • Acceptance criteria of a sprint – if the agile software development contract is unclear around acceptance criteria the parties can be left arguing over whether an element of the build is completed or not. Acceptance criteria should be described in detail in any agreement so that there is no reliance on less formal descriptions that may be contained in user stories.
  • It is common for agile software development projects to go over budget. Leaving aside delays or quality issues that ramp up costs, if a customer walks into a project not really sure about what they want then it can often happen that their eyes will light up when the developer says “hey, do you want the product to do this cool thing”.
  • Everyone needs to be involved. Developing software using agile methodology is quite an intense process, depending on the project. As it is a collaborative process the parties need each other to be on focused on the project and communicating with each other the whole time. If a key member of the team suddenly goes AWOL then the project may grind to a halt.

Agile Software Development in practice

Agile Software Development as a methodology has the potential to produce creativity and customer/supplier satisfaction  on paper and in practice. It is important, however, to be aware of the potential legal pitfalls from the outset so that each party feels satisfied with the contents of an agreement before moving forward. It is also significant to note that agile methods require both parties to commit to a significant level of time and resources. If either party is remotely located or overburdened with other responsibilities (and so unable to focus on the agile project) the chances of success will be limited.

EM law specialises in technology and contract law. Get in touch if you need advice on Agile Software Development agreements or have any questions on the above.


EMI Share Option Schemes

EMI Share Option Schemes: A Quick Guide

Enterprise Management Incentives (EMI) Share Option Schemes are a type of employee incentive scheme that can enjoy very favourable tax treatment if introduced and operated correctly. They are the most popular HMRC tax favoured scheme used by businesses in the UK. EMI Share Option Schemes are specifically designed for small companies and they are a great way for businesses to attract or retain talented staff who may not be able to afford the high salaries that such staff could command elsewhere. Nowadays, many highly qualified staff, in particular in the tech sector, are expecting to be offered shares as part of their remuneration.

Essentially, EMI Share Option Schemes reward employees (usually key employees) with equity participation in a company. An overview of the qualification criteria for operating a scheme is set out below but please note this is subject to change. In the Spring 2020 Budget (paragraph 2.200), the government announced that it will review the EMI legislation to see how effectively it meets the objective of enabling smaller companies to recruit and retain staff. This may lead to a relaxation of the qualification criteria to enable more companies to benefit.

Which companies can operate EMI Share Option Schemes?

In summary, for a company to qualify to grant EMI options, the following conditions must be met:

  • The company must be independent (i.e. not a 51% subsidiary of any other company or under the control of another company / another company and a person connected with it and there are no arrangements in place under which these conditions would not be met).
  • If the company has any subsidiaries they are “qualifying” subsidiaries (i.e. the company owns at least 51% of the subsidiary, the subsidiary is not under the control of someone else and there are no arrangements in place under which these conditions would not be met). Additional requirements apply to property managing subsidiaries.
  • The company’s gross assets are no more than £30 million at the time of grant.
  • The company must have fewer than the equivalent of 250 full-time employees.
  • The company must be a trading company, or the parent company of a trading group with a qualifying trade which does not involve an excluded trading activity.
  • The company must have a UK permanent establishment.

Please note that detailed statutory rules determine whether a company is able to satisfy these requirements, and specialist advice on this is recommended before setting up an EMI scheme. Companies can also seek clearance from HMRC that they meet these requirements.

What shares can EMI options be granted over?

EMI options can be satisfied by newly issued shares or by the transfer of existing shares from a shareholder, including an employee benefit trust (EBT). The shares must meet certain requirements, including that the shares must be fully paid up, non-redeemable ordinary shares.

Who can be granted EMI options?

To be eligible to be granted an EMI option, an employee must work for the company for at least 25 hours per week, or if less, 75% of their working time. Employees cannot be granted EMI options if they (or their "associates") have a "material interest" in the company whose shares are used for the scheme, or in certain related companies.

Setting the exercise price and valuing the shares in EMI Share Options Schemes

The exercise price of an EMI option can potentially be set at any level (including nil). Options are usually granted at a price equal to the market value at the time the options are granted in order to prevent any income tax or national insurance contributions charges arising on exercise. HMRC will agree share valuations in advance of the grant of EMI Share Options and will usually agree a valuation window of 90 days during which the option may be granted (although it is currently offering windows of 120 days during the COVID pandemic).

Limits on EMI options

An employee can hold unexercised EMI options over shares worth up to the current EMI individual limit (£250,000). A company cannot have granted outstanding EMI options over more than £3 million worth of shares at any one time.

When can an EMI option be exercised?

The EMI code requires that EMI options must be capable of being exercised within ten years of the date of grant, and options can only be exercised within a period of 12 months after the option holder's death. Otherwise, there are few restrictions on the exercise provisions that can apply to EMI options, and this flexibility means that they can be used for exit-only arrangements (where an option can only be exercised on an exit event, such as a share sale or listing), as well as for options exercisable at the end of a performance or vesting period.

When do EMI options lapse?

Apart from the legislative requirements for the exercise of EMI options referred to above, there are no restrictions on when EMI options can be exercised or will lapse. However, it is best practice for EMI option agreements to specify exactly when options will lapse, particularly at the end of a window period for exercise. Often, the EMI option agreement will provide that options will lapse on leaving employment, although early exercise may be permitted in certain circumstances.

The EMI option agreement will generally also provide that options lapse if the option holder becomes bankrupt, and it must also prohibit an option holder from assigning the options or using them as security.

Tax treatment for the company

A corporation tax deduction may be available when EMI options are exercised (under Part 12 of the Corporation Tax Act 2009). Relief is given in the accounting year in which the options are exercised and should be claimed by the option holder's employer company (not the company whose shares are acquired, if different). The deduction is equal to the gain the employee makes.

Tax treatment for the employee

The EMI option plan must be registered with HMRC who will allocate a unique scheme reference number about a week later. In order for an EMI option to qualify for favourable tax treatment, the grant of each option must also be notified to HMRC within 92 days of the grant date, using the ERS Online Service.

In practice, it is not possible to notify the grant until HMRC has allocated a scheme reference number, so it is important to do this well before the 92 day period expires. If the option remains a qualifying EMI option (no disqualifying event has taken place before exercise), the tax treatment for an employee holding an EMI option is as follows:

  • On grant - there is no income tax liability on the grant of the option.
  • On exercise - there is no income tax liability on exercise if the exercise price was at least equal to the market value of the shares at grant. If the exercise price was less than the market value of the shares at grant, then income tax is due on the difference between the exercise price and the market value at grant.
  • On disposal - on a sale of the option shares, capital gains tax(CGT) may be payable on any gain over the market value at grant (that is, the difference between the sales proceeds and the market value of the shares at grant). Importantly, provided that at least 2 years have passed since the option was granted and all other statutory requirements are met, CGT business asset disposal relief (previously referred to as entrepreneurs’ relief) will be available.

Disqualifying Events Under EMI Share Option Schemes

The EMI rules refer to certain “disqualifying events” which, if they occur, can impact on the tax treatment of the EMI option affected.

Disqualifying events include:

  • the company ceasing to satisfy the independence test;
  • the company ceasing to meet the trading activities test;
  • the employee ceasing to be an eligible employee because:
    • they cease to work for the relevant company or within the group; or
    • they cease to satisfy the working time commitment;
  • certain alterations to the option:
  • certain alterations to the share capital of the company; and
  • the grant of options under a CSOP which would (when added to unexercised EMI options) take the aggregate market value of the shares subject to such options (measured at the date of grant) to over £250,000.

EMI Share Option Schemes - National Insurance Contributions

Broadly, the NICs treatment of EMI options follows the income tax treatment:

  • There will be no NICs if no income tax is due.
  • There will be NICs if income tax is payable and the shares are readily convertible assets.

The employer and the employee may enter into arrangements under which the employer NICs liability is transferred to the employee

EMI Share Option Schemes – traps for the unwary

Although EMI Share Option Schemes can be set up fairly quickly and for some companies it will simply be a question of following a set process, we see many examples of schemes gone wrong.

In particular, the EMI option agreement must be drafted with care in order to comply with all current HMRC requirements, including the detailed information that must be given to the option holder and the declarations that must be provided by them.

In circumstances where the scheme was not set up properly (for example because documents are not compliant or notifications weren’t made on time or full disclosure was not made to HMRC when agreeing share valuations) this will lead to unexpected income tax charges arising on exercise of the grant and other reliefs being lost. This can leave the employer with very disgruntled employees who will want to be compensated for the additional tax they are having to pay. It can also be a problem if the owners of the business intend to sell it and the errors are spotted by the lawyers acting for the buyer. Those lawyers will be advising the buyer that they should be reducing the purchase price for the business to cover the fallout.

Here to help

If you have any questions on EMI Share Option Schemes or need help putting such a scheme in place please contact Suzy Giele our expert EMI lawyer.


UK GDPR

UK GDPR - Data Protection After The Transition Period

UK GDPR, EU GDPR, DPA 2018, DP Regulations. Confused? Hopefully this blog will help you understand what is happening with data protection laws in the UK now that the Brexit transition period has ended.

The UK data protection authority, the Information Commissioner’s Office (ICO), is telling us that at the end of the Brexit transition period, data protection compliance should continue as usual. The key principles, rights and obligations remain the same. What then is the consequence of the Brexit transition period ending on data protection in the UK?

Most importantly, following the end of the transition period, the EU and the UK will be operating under different, albeit very similar, data protection regimes. This means that any transfer of data between the two regimes will be considered as such – i.e. between two independent data protection legal systems.

The Legislation – UK GDPR and the DP Brexit Regulations

A confusing aspect of the UK’s new data protection regime is its reference to legislation. There is mention of the ‘UK GDPR’ and ‘DP Brexit Regulations’. In order to clear up any misunderstanding it is useful to consider how data protection legislation operated before Brexit

Before Brexit data protection was mainly governed by two pieces of legislation: the General Data Protection Regulation ((EU) 2016/679) and the Data Protection Act 2018. The first being EU law and the second being the mechanism by which it was implemented into UK law.

With the coming of Brexit came a concern with what the UK government should do with all its EU law. The European Union (Withdrawal) Act 2018 sought to retain EU law already implemented in the UK, including GDPR. Simply put, retained EU Law is copied and amended before becoming UK law. The EU data protection law GDPR, in its retained form, is now known as the UK GDPR. This is in contrast to data protection law in the EU now known (in the UK) as the EU GDPR.

The Data Protection Act 2018 (DPA), although already being UK law, was also defined as retained EU law for the purposes of the European Union (Withdrawal) Act 2018 and therefore at the end of the transition period it will continue to be a main source of data protection law in the UK.

In order for the retained EU data protection law to work in the UK after the transition period it needs to be amended. The Data Protection, Privacy and Electronic Communications (Amendments etc) (EU Exit) Regulations 2019 (referred to here as the DP Brexit Regulations) is the legislation by which this will be achieved. The amendments made to the UK GDPR and the DPA by the DP Brexit Regulations will therefore merge to form the core of the UK’s data protection law. Organisations will need to consider two legal texts after the transition period: the UK GDPR and the DPA.

Changes made by the DP Brexit Regulations

The purpose of the DP Brexit Regulations is first and foremost to integrate EU data protection law, as it stands, into UK law after the transition period. Therefore most of the changes are relatively predictable. Here are a few:

  • The Information Commissioner (UK data protection authority) is no longer a party to EU GDPR co-operation, consistency mechanisms and will not have a seat on the European Data Protection Board (EDPB).
  • Amendments are made throughout the UK GDPR to change references to EU institutions, member states and decisions.
  • European Commission powers are transferred to the Information Commissioner or the Secretary of State. For example the Information Commissioner has the power to issue Standard Contractual Clauses (a mechanism by which data is transferred internationally).
  • Section 4 of the DPA is amended to make clear that it applies to personal data to which the UK GDPR applies and that it supplements and must be read with the UK GDPR.
  • A new section 17A in the DPA covers transfers based on adequacy regulations (a mechanism by which data is transferred internationally). The Secretary of State has the power to make “adequacy regulations” to specify that a third country, territory, sector or international organisation ensures an adequate level of data protection.

International transfers

At the end of the transition period, the UK would have been a third country under the EU GDPR, meaning that EU controllers and processors would need to ensure that an adequacy mechanism was in place to protect transfers i.e. Standard Contractual Clauses or Binding Corporate Rules.

However, on 24 December 2020, the UK and EU reached a trade and co-operation agreement addressing the arrangements following the end of the Brexit transition period on 31 December 2020 (as implemented by the European Union (Future Relationship) Act 2020).

Most significantly the agreement has introduced at least a four month period (extended another two months unless one of the parties objects) in which data can flow between the regimes without additional safeguards. The aim of the agreement is to give organisations breathing space while the Commission continues its assessment of adequacy for the UK. If the UK is granted an adequacy decision then data will continue to flow freely between the regimes after this period.

Data processed or obtained before the end of the transition period

From the end of the transition period the UK is required to continue applying “EU law on the protection of personal data” to the processing of EU personal data where the personal data was processed before the end of the transition period. It will therefore be helpful for organisations to know what data has been processed in the EU before the end of the transition period so that, should the regimes diverge, that data continues to have EU law applied to it. By contrast, personal data about UK data subjects processed in the UK before the end of the transition period will fall under the UK GDPR and DPA.

More to come - UK GDPR and EU GDPR to diverge?

The big next development in data protection and Brexit will be whether or not the commission grants the UK an adequacy decision. Organisations should have a clear idea of how they are going to confront the possibility that no adequacy decision is reached. This will mean reviewing data flows and the contracts that enable them.

The ICO is right to say that the data protection principles before Brexit will largely remain the same in the UK. The UK GDPR and DPA as a new legislative framework are more than anything else a replica of what has come before. But with an adequacy decision pending and the EU’s draft E-Privacy Regulation still being finalised and therefore without a hope of being applied in the UK, the two data protection regimes could split in significant ways in a relatively short amount of time.

If you have any questions on Brexit and data protection, data protection law more generally or on any of the issues raised in this article please get in touch with one of our data protection lawyers.