Agile Software Development

(1)

 2012 Kynetix Technology Group

Agile Software

Development

(2)

 2012 Kynetix Technology Group Page: 2

INTRODUCTION

Many organisations adopt an Agile approach to software development and later wonder why applications are not being delivered any faster.

What they do not realise is that, to succeed at Agile, these organisations will have to change many of their IT practices and to develop a new culture of openness and co-operation with the business.

In addition, the business people must realise that the success of any Agile project heavily relies on their commitment and involvement.

Experience gained over many years managing Agile projects has taught us that there are some key factors that lead to success.

1. NO USER COMMITMENT – NO SUCCESS

Agile is a user-centric approach to development and the active involvement of users throughout the life-cycle is essential for success.

Agile development teams need to keep moving at a rapid pace. Decisions need to be made quickly. It is vital that the development team can get responses from the user community without delay.

This means that one or more key user representatives will have to dedicate substantial time to the project. The backing from management for this level of commitment is absolutely essential.

Lack of user commitment is usually caused by one of three reasons namely:  The need for the system is driven by either IT or management and not the

business

or

 The management do not fully understand the level of commitment needed from them in order for the project to succeed

or

 There is not a business-critical end date for the project

Even if the right level of user commitment is made, this will be difficult to sustain if there is not a business-critical end date for the project.

(3)

2. EMPOWER THE USER REPRESENTATIVE(S)

User commitment alone is not enough to guarantee success if the users appointed to work on the project are not empowered to make decisions. If they have to constantly refer to higher authorities before agreeing anything, then they are not the right people to be involved.

Make sure that you appoint people with sufficient level of authority and business knowledge to ensure that decisions can be taken quickly.

These people also need to be able to make things happen in your organisation. They need to be able to navigate through the organisation hierarchy. They also need to be adept at avoiding getting embroiled in company politics.

Even with empowered users, some decisions need to be made at a higher level. There has to be an ongoing commitment from everybody to arrive at those decisions quickly and not to delay them unnecessarily.

If a key decision maker is not going to be available at critical periods then a stand-in must be appointed to ensure deadlines can be met.

User empowerment also extends to creating a ‘no-blame’ culture i.e. people must be allowed to take calculated risks, based on their knowledge of the business, without recriminations.

3. COMMIT TO MOSCOW PRIORITISATION

One of the primary techniques used to ensure that Agile projects deliver on time is 'timeboxing' i.e. the content of the deliverables is governed by time constraints and not by functionality.

If certain functions cannot be delivered within the allotted time then they are deferred to a future release. Obviously there is a minimum set of functionality that any system must have.

MoSCoW is a technique used to prioritise the content of a deliverable. It can be applied to requirements, tasks, products, use cases, user stories, acceptance criteria, tests etc.

The letters stand for:

(4)

Could Have

Won’t Have this time but WOULD like to have in the future.

For each project there will be definitions of what these priorities mean. Examples include:

MUST HAVE

 Cannot deliver on target date without this

 No point in delivering on target date without this; if it were not delivered, there would be no point deploying the solution on the intended date

 Not legal without it  Unsafe without it

 Not financially viable without it; will not meet the business case.

SHOULD HAVE

 May be painful to leave out, but it is still possible to operate without it  May need some kind of workaround (e.g. management of

expectations, some inefficiency, an existing solution etc.)

COULD HAVE

 Wanted or desirable but not vital  Wanted but workable without

 Less impact on value, staff or customers if missing  Workaround is easier

4. CHANGE IS GOOD BUT TIMESCALES MUST STAY FIXED

A fundamental principle of any Agile project is that the requirements can change during the course of the project.

Requirements emerge and evolve as the project progresses. Quite often users are not clear about what they want or what is possible with the software until they’ve seen something.

(5)

However, what separates Agile development from other approaches is that the timescales must stay fixed. As more valuable features are uncovered and added to the requirement so less valuable features get moved out to a future release.

This is how scope creep is controlled and ensures that Agile projects meet their deadlines and budgets.

5. GOOD TOOLS ARE ESSENTIAL BUT DO NOT GUARANTEE

SUCCESS

Agile is primarily about people and management issues NOT tools. Having said this, it is true that many of the latest visual tools lend themselves more readily to an Agile approach than some of the older 3GL languages.

Before launching into a Agile project with new tools, it is important to ensure that the developers are experienced in the chosen environment, otherwise the project may take as long (if not longer) than with existing tools. If this is not the case then you must lower your expectations of what can be achieved with Agile.

You should also consider bringing in external resources experienced in your chosen tool to act as mentors to your developers. Make sure that development standards have been implemented prior to the start of the project and that all developers are familiar with them.

Ensure that a configuration management system is in place and that all developers know how to use it. Without this it becomes impossible to manage the iterative nature of Agile projects.

6. SELECT THE RIGHT PEOPLE FOR THE PROJECT

Agile is a people-based process with constant contact between the development team and the business, so selecting the right people from both sides is essential for success.

(6)

You need to choose carefully who will be in the Agile team. The best Agile teams will build good relationships with the users and will inspire the right levels of trust and collaboration that are needed to ensure success.

What you do not need in your team are uncommunicative, difficult people who come up with lots of reasons why something cannot be done.

Some of the attributes for the ideal technical personnel include:

Good communication skills Able to converse in the language of the business not in IT jargon

Good at listening Can elicit requirements from users without overpowering them

Business oriented A can-do person. Understands the

business drivers and is motivated to deliver a working solution

Delivery focused Adheres to timeboxes

Technically strong But pragmatic in the application of technology

Experienced in Agile techniques Understands timeboxing. Simplifies, not complicates

The best developers are skilled technically but see programming as a means to the end and are more interested in delivering a workable solution than in writing the ultimate piece of code.

7. ENSURE THERE IS A SUPPORTIVE COMMERCIAL

RELATIONSHIP

An Agile project is a two-way contract between the business sponsor and the development team, regardless of whether the development team is an internal team or an external supplier.

(7)

However, for this to work successfully, the business sponsors MUST support the principles of Agile i.e. they must agree to prioritise functionality and they must be prepared to make trade-offs in order to meet the deadlines and budgets.

The development team cannot be expected to commit to a fixed budget if the business stakeholders are likely to continually push for additional functionality without agreeing to corresponding trade-offs.