Agile Software Development

Transcription

1 Agile Software Development 7 Steps to Successful Projects 2012 Kynetix Technology Group

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. Without an immovable target date users will not be motivated to meet the project deadlines and will undoubtedly lapse into over-specifying their requirements Kynetix Technology Group Page: 2

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: Must Have Should Have 2012 Kynetix Technology Group Page: 3

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. Change is therefore a vital ingredient in Agile projects. Through a process of collaboration and negotiation, the users and the development team converge on the best solution for the business needs Kynetix Technology Group Page: 4

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. Programming often attracts introspective people who do not enjoy communicating with the outside world. We ve probably all worked with people like this at some point. They are often technically very strong but they lack the social and presentation skills to be able to relate to the users Kynetix Technology Group Page: 5

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 Good at listening Business oriented Delivery focused Technically strong Able to converse in the language of the business not in IT jargon Can elicit requirements from users without overpowering them A can-do person. Understands the business drivers and is motivated to deliver a working solution Adheres to timeboxes 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. The nature of Agile projects means that quite often the project will be run to a fixed or capped budget. This is a very attractive proposition to the business sponsor as they can predict the final cost of the project Kynetix Technology Group Page: 6

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. Kynetix specialise in designing, building and implementing IT solutions for the Financial Services sector. We use Agile development techniques to deliver solutions within aggressive timescales. The author, Paul Smyth, is CEO of Kynetix. He can be contacted on or by at Paul.Smyth@kynetix.com 2012 Kynetix Technology Group Page: 7