Agile IT - A value driven approach to IT delivery final
Upcoming SlideShare
Loading in...5
×
 

Agile IT - A value driven approach to IT delivery final

on

  • 961 views

 

Statistics

Views

Total Views
961
Views on SlideShare
961
Embed Views
0

Actions

Likes
0
Downloads
26
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agile IT - A value driven approach to IT delivery final Agile IT - A value driven approach to IT delivery final Document Transcript

  • An HML white paper: Agile ITA value-driven approach to IT delivery
  • CONTENTS ABOUT THIS PAPER2: About this paper The purpose of this paper is to demonstrate how applying lean and agile3. About HML principles can create value in software development. Introduction4. The need for It will be of interest to people who are responsible for IT projects, budgetchange control, organisational change or who have an interest in lean and agile thinking. Lean agile roots5. The journey to The paper describes how HML has put these principles into practice in aAgile IT form of software development called ‘Agile IT’, which addresses key7. Overcoming business concerns like time to market, responsiveness to changingchallenges to change needs, customer satisfaction and cost reduction.8. The EightPrinciples of Agile IT The paper outlines the history of lean and agile approaches and explains13. The benefits of how these have been applied to create Agile IT. It sets out EightAgile IT Principles that underpin HML’s approach, and how these enable the delivery of the right IT capabilities at the right time to maximise value to14. Agile IT at work: customers.Forbearance Project15. About the author “Agile IT has allowed HML to meet the strategic challenges of wasted resource and lengthy change management processes. What might have taken months now takes weeks and our IT department is engaged and able to offer clients tangible results throughout the process. ” Andrew Jones, Chief Executive Officer, HML © HML 2012. All rights reserved. 2
  • ABOUT HML HML is the UK’s largest specialist mortgage servicer, providing outsourced mortgage administration services to over 50 leading financial institutions. HML operates from three UK locations: Skipton, Londonderry and Glasgow. The company was established in 1988 and manages approximately £43bn of mortgage assets and 400,000 customer accounts. INTRODUCTION HML’s iConnect platform provides a sophisticated and comprehensive tool to support a diverse range of client requirements. iConnect is constantly updated, driven by HML’s desire to continually improve its offering, but also by the regulatory environment in which HML and itsHML‟s success in clients operate.applying lean andagile principles has In 2008, HML began to apply lean 6-sigma improvement techniques principally within its operational areas. In 2010 it embarked on anresulted in a ambitious programme to improve iConnect in support of this drive fornomination for the operational excellence.Best AgileNewcomer at this To meet this challenge, the IT teams needed to develop their ways ofyear‟s UK Agile working, so Agile IT was born.Awards.For more Agile IT is achieved by the application of eight principles:information about 1. Make it Visiblethe Awards see 2. Make Collaboration Easyhttp://www.agileaw 3. Assume Change: Experiment, Discover, Learn, Iterateards.co.uk/Awards2 4. Focus on Delivering Useful Value Today012.html 5. Build a Sustainable Flow of Value 6. Build Quality In 7. Continuously Improve 8. Agility is Everyone’s Responsibility HEADLINE RESULTS In just 12 months, Agile IT has enabled HML to increase its rate of delivery of new IT capabilities by a factor 4, while reducing the time to deliver a new feature from months to a matter of weeks; all without impacting cost or quality.© HML 2012. All rights reserved. 3
  • THE NEED FOR CHANGE In common with many financial institutions, HML has in the past relied on a sequential software development lifecycle, often known as ‘waterfall’, where projects progress through a series of discrete stages:At the start of 2011, • RequestHML recognised • Designthat its IT teams • Buildneeded to evolve • Testtheir ways of • Implementworking in order tobecome more Each stage within this sequence was largely undertaken by a separate specialist functional group and work was handed off from one group toresponsive to the next with formal documentation providing the communication betweenchanging needs groups.and reduce the„time to value‟ of This approach worked well for HML’s needs at the time and over fivechanges, whilst years had resulted in a steady improvement in the stability of productionretaining the systems, with progressively fewer defects escaping into production, andimprovements in improved predictability of delivery dates.quality. However, these improvements tended to come at the expense of responsiveness to change and long delivery timescales. At the start of 2011, HML recognised that its IT teams needed to evolve their ways of working in order to become more responsive to changing needs and reduce the ‘time to value’ of changes, whilst retaining the improvements in quality. These changes were to be guided by the adoption of lean and agile software development principles and practices – an approach that complemented HML’s existing use of lean and 6-sigma techniques in its Operational Service Areas. LEAN-AGILE ROOTS The term ‘Agile’ as applied to software development was first coined in 2001 to describe a range of methods that emphasised adaptability to change. The Manifesto for Agile Software Development and its associated 12 Principles sets out what being agile means; while a range of methods, such as Scrum, eXtreme programming and DSDM, provide ways of developing software in an agile way. The idea of lean software development began at a similar time. It takes the core principles of lean thinking, e.g. flow, pull, and continuous improvement, and applies them to software development.© HML 2012. All rights reserved. 4
  • Lean and agile can be seen as complementary approaches: lean tends to address the wider organisational concerns, while agile focuses at the development team level. The combination of lean and agile principles and methods, together with other approaches such as 6-Sigma, Kanban and the Theory ofThe timely and Constraints provide the foundations for Agile IT at HML.sustained delivery See http://agilemanifesto.org/of valuable IT See http://www.scrum.org/ and http://www.scrumalliance.org/capabilities to See http://www.extremeprogramming.org/HML‟s internal See http://www.dsdm.org/customers and See http://www.lean.org/WhatsLean/Principles.cfmexternal clientsremainsparamount, and is THE JOURNEY TO AGILE ITat the core of AgileIT. Lean and agile software development is not just something that you do; it’s equally about how you think. Changing the ways of working in IT had to address both transformation of its culture and the adoption of new practices and techniques. And while lean and agile principles and techniques have been at the heart of the changes, these have always been treated as a means to an end rather than an end in their own right. The timely and sustained delivery of valuable IT capabilities to HML’s internal customers and external clients remains paramount, and is at the core of Agile IT. At the start of the change transition, HML appointed an experienced agile development practitioner to provide expertise, leadership and support through hands-on coaching. Reporting directly to the Head of IT provided the appropriate executive authority and clearly signalled the importance of the changes. Building awareness of lean and agile approaches, principles and techniques has been a cornerstone of the transition. Alongside formal training and hands-on coaching, peer-based informal ‘learning lunches’ and ‘community of practice’ forums have been used to regularly share experiences and learn new techniques. Task boards - big visible displays that show a team’s flow of work - were one of the first items to be introduced and they remain one of the most visible aspect of the changes to visitors. Impediments – things either slowing down or blocking flow – are quickly identified enabling action to be swiftly taken to resolve.© HML 2012. All rights reserved. 5
  • FIGURE 1: IMPEDIMENTS CAN BE ESCALATED TO A DEPARTMENT LEVEL BOARDHML has borrowedfrom many of thewell known agilemethods, such asScrum, eXtremeProgramming (XP)and DSDM, but hasdeliberately chosento avoid mandatinga particular methodin order toencourageadaptation,innovation andownership by Symbols used to indicate type of impediment:teams in how theywork. Stopping progress Slowing progress Significant risk of stop or slow Two other key changes were also introduced early in the transition: co- location of teams and incremental development; where business goals are progressively broken down into a series of features that are developed in short iterations and delivered over a series of releases. Fundamental to the long term success of changing the way of working has been to make continuous improvement and learning a way of life. Fortnightly ‘retrospectives’ enable a team to reflect on what is working well, and what is not; and gives them responsibility for changing their process. Over time, this process has itself been adapted, refined and improved, with both a team and department wide improvement regime. Instead, HML has developed eight principles of Agile IT that can be used by everyone involved, from individual IT practitioners, to teams and stakeholders to guide how they should work. The principles help reinforce the view that Agile IT is primarily cultural, and represents a journey not a destination.© HML 2012. All rights reserved. 6
  • OVERCOMING CHALLENGES TO CHANGE Change is never easy, and HML faced a number of challenges on itsIterative Agile IT journey.development andincremental One of the first challenges HML encountered was the creation of co-delivery creates located, cross-functional teams. Unsurprisingly, some individuals felt unhappy to have to move desks, and breaking up long standing functionalsignificant groups risked losing their sense of community. HML worked hard tochallenges for involve those who needed to move in the planning, and introducedupstream and changes progressively. The existing functional line-reporting structuredownstream and regular functional team meetings were also retained. Only at the startprocesses. of 2012 did formal line management change to reflect the new cross- functional structure of teams. Throughout the transition, HML needed to ensure governance was not compromised. Many of the existing governance controls were organised around or were dependent on waterfall stages and functional teams, so the move to cross-functional teams and iterative development potentially reduce these controls’ effectiveness. Close collaboration with the RiskCreating an IT and Compliance teams ensured appropriate oversight and HML is currently introducing Practice Leaders who will be responsible forcapability to build governing key practice standards.and deliver newfeatures on a just- Finally, iterative development and incremental delivery creates significantin-time basis also challenges for upstream and downstream processes. Creating an ITrequires a business capability to build and deliver new features on a just-in-time basis alsoorganisation that requires a business organisation that can define and prioritise a flow ofcan define and desired features, and one that can absorb and apply them usefully. HML has made some progress in this area, using agile techniques to defineprioritise a flow of business cases for increments rather than whole projects, but thisdesired features, remains an area of development and improvement.and one that canabsorb and applythem usefully.© HML 2012. All rights reserved. 7
  • THE EIGHT PRINCIPLES OF AGILE IT 1. Make it VisibleTeams own their The process of software development is difficult to visualise, and whilevisual management Gantt charts have a place, they rarely map well to the needs of IT.boards, and thisfosters innovation Agile IT makes use of large, physical display boards that show the flow ofin how boards and work being undertaken by the team, an approach known as Visual Management. Task boards and similar visual management tools help athe underlying team visualise the ‘state of play’ of the work they are doing and make itprocess they easy to spot and respond to impediments to a team’s development flow,represent evolve to contributing to shorter delivery times.meet the team‟sneeds. Teams own their boards, and this fosters innovation in how boards and the underlying process they represent evolve to meet the team’s needs. For example, blockages are highlighted with stop signs; avatars of team members are used to indicate who’s doing what; and colour is used to indicate different types of work. FIGURE 2: SHOWING FLOW OF WORK ITEMS, TYPICALLY USER STORIES AND ASSOCIATED TASKS Avatars show assignment Impediments highlighted with Red Flags As well as helping the team, visible task and status boards have proved invaluable for updating stakeholders. They’ve also fostered greater team spirit and visibility of the status of the project with the wider business.© HML 2012. All rights reserved. 8
  • 2. Make Collaboration Easy IT development is a creative process. Customers and IT professionals have to work together to ensure they deliver what is needed in aFace to face background of imperfect knowledge and change. Making collaboration easy is therefore essential for successful projects.communication isencouraged as the With Agile IT, work is undertaken by small co-located, cross-functionalprimary method of teams, known as ‘pods’ who take responsibility for the end-to-endcommunication delivery of new software features. As well as bringing together expertise in different IT disciplines, such as test, engineering and analysis, customer representatives and other key stakeholders work closely with teams throughout the development and delivery lifecycle.IT projects face twokey challenges: Face-to-face communication is encouraged as the primary method ofcustomers do not communication. Documentation remains important, but the emphasis isknow precisely on doing just what is necessary and using alternative forms of documentation, such as wikis and other electronic knowledge bases,what they really rather than paper documents.need; and intoday‟s competitive 3. Assume Change: Experiment, Discover, Learn, Iteratebusinessenvironment those IT projects face two key challenges: customers do not know preciselyneeds are often a what they really need; and in today’s competitive business environmentmoving target. those needs are often a moving target. The traditional approach to addressing these challenges is to undertake extensive up-front analysis before locking down scope and then limiting subsequent amendments through change control regimes. Unfortunately it’s also common to see these IT projects take a very longAgile IT assumes time to deliver what turns out to be the wrong thing.that change isinevitable and Agile IT assumes that change is inevitable and seeks to exploit this ratherseeks to exploit this than resist it. Using an iterative approach to development coupled withrather than resist it. incremental delivery ensures that the most valuable features needed today are delivered first whilst others are deferred for later increments. IT projects at HML typically use fortnightly iterations, and are able to deliver new features into production monthly. Stakeholders are able to review working versions of iConnect at least every iteration, and this feedback is used to adjust what features will be developed next.© HML 2012. All rights reserved. 9
  • 4. Focus on Delivering Useful Value Today Delivering something of value early is generally much more beneficial than delivering a collection of things much later. As well as increasingAgile IT seeks to return on investment, focusing on delivering what’s useful today helps prevent speculative development or ‘gold-plating’.incrementallydeliver value by Research by the Standish Group suggests this is far from uncommon,delivering in small, reporting that 45 per cent of software applications’ features are nevervaluable used. As well as incurring unnecessary cost, building these featuresincrements. Each means that other more useful features are either delayed or not built atincrement is all.focused ondelivering the Agile IT seeks to incrementally deliver value by delivering in small,minimum needed to valuable increments. Each increment is focused on delivering the minimum needed to provide benefit to its customers today.provide benefit toits customers Stakeholders are actively involved in determining the order oftoday. development of features and the team is encouraged to seek out opportunities for delivering increments early. Monthly releases enable new features to be rolled out quickly so it’s possible for a feature to go from idea to delivery in just a few weeks. Delivering incrementally places new pressures on repetitive tasks such as build, deployment and regression testing and HML has steadily focused on automating and refining this process. Similarly, architecture and detailed designs need to support change, and technical practices such as Test Driven Development and Refactoring have been adopted to support this. 5. Build a Sustainable Flow of Value Many organisations seek to maximise the utilisation of staff and the number of projects that are in progress. Unfortunately, this approach tends to result in long delivery times for any one activity and relatively low completion rates. Whilst it can give the appearance of cost efficiency it comes at the expense of time to value and responsiveness to changing needs – qualities that usually far outweigh the savings made by maximising utilisation. Agile IT seeks to take a holistic view of the whole delivery value stream - not just that part in IT - optimising for a fast, steady stream of deliveries of valuable features. Instead of maximising utilisation (and minimising unit cost), Agile IT seeks to minimise cycle time, the elapsed time it takes for valuable increments to be delivered, and so increase throughput, the rate of delivery of benefits.© HML 2012. All rights reserved. 10
  • Reducing cycle time enables returns on investments to be achieved sooner and improves responsiveness to changing needs. Increasing throughput maximises the opportunity to deliver what is needed.Simply put, Agile IT Simply put, Agile IT values finishing over starting; doing less in order to achieve more, and systematically finding and removing anything thatvalues finishing disrupts or impedes flow.over starting; doingless in order to Teams at HML use either iterations - short timeboxes of typically twoachieve more, and weeks - or explicit work in progress limits to manage flow. Projects aresystematically decomposed into small increments which are in turn broken down intofinding and small features that can be completed in days rather than weeks. Andremoving anything teams actively identify and resolve impediments to flow, escalating those they cannot quickly resolve to a department-wide daily impedimentsthat disrupts or meeting attended by management to ensure visibility.impedes flow. 6. Build Quality In Deming famously declared that “You can not inspect quality into the product; it is already there.”* Most traditional approaches to software development focus on the (often late) detection of problems, through inspections and testing, and make extensive use of manual processes that inevitably introduce variation and errors. Agile IT recognises that speed and agility requires attention to quality and technical excellence; it is simply not possible to go fast if the process orAgile IT recognises product is unreliable.that speed andagility requires Teams at HML employ automation for repetitive tasks, such asattention to quality integration, build, check and deploy; enabling them to execute theseand technical tasks frequently – typically multiple times a day. They also useexcellence; it is techniques such as pair programming and test driven development thatsimply not possible help prevent errors or catch them as soon as possible after they are introduced.to go fast if theprocess or product *From Out of the Crisis, by W Edwards Deming (MIT Center foris unreliable. Advanced Engineering Study, 1986)© HML 2012. All rights reserved. 11
  • 7. Continuously Improve The need to respond to change applies just as much to the process of development as to the capabilities of the software. The idea that a singleThe idea that a process will work equally well for all time and across all projects and teams is not reasonable, so Agile IT promotes a culture of continuoussingle process will adaptation and improvement and advocates that those who do the workwork equally well are best placed to improve how the work is done.for all time andacross all projects HML has made knowledge sharing explicit; sponsoring ‘learning lunches’and teams is not and the formation of communities of practice, and has recently introducedreasonable, and so Practice Leaders to guide and support practice improvement.Agile IT promotes aculture of Frequent and regular retrospectives - workshops focusing oncontinuous improvements - are undertaken by teams, typically every two weeks, where teams are encouraged and empowered to make small incrementaladaptation and changes to their processes to drive improvement.improvement andadvocates that 8. Agility is Everyone’s Responsibilitythose who do thework are best ‘Doing agile’ is important, but ‘being agile’ is essential. Fundamentally,placed to improve agility is a mindset that everyone in the organisation needs to express.how the work is Agile IT provides an organisation with the potential for becoming an Agiledone. Business. At HML, agility in general and Agile IT specifically, has become central to its ethos.„Doing agile’ isimportant, but‘being agile’ isessential.Fundamentally,agility is a mindsetthat everyone in theorganisation needsto express.© HML 2012. All rights reserved. 12
  • BENEFITS OF AGILE IT Over the first 18 months of its Agile IT journey, HML has significantly improved its IT capability:An HML consultant Increased throughputfeeds back after a HML has been able to move from quarterly releases to monthly releases.recent project to Delivering more frequently has had two benefits: firstly, it is much easier to release opportunistically – stakeholders, having seen an iterationautomatically and demo, may realise that the software would be beneficial if deployed as is,securely retain and monthly releases allow these opportunities to be exploited. Secondly,customer card more frequent and smaller releases reduce the risks associated withdetails goes live: each deployment.“I have to give you Reduced time to deliver valuethis feedback Before the transition to Agile IT, IT projects at HML, even those that usedbecause it is proof a phased delivery approach, would typically take between three and nine months from approval to their first delivery into production. Agile IT hasof the success of reduced this ‘time to value’ considerably, with projects typically nowcard re-use delivering benefits within three months, and often considerably sooner.functionality. Wehad over 200 calls Greater flexibility and responsiveness to changing needstoday and not Focusing on achieving a business goal frees teams to explore and adaptdropped a single their solution so that it best meets that goal, enabling them to respond toone, on last changing circumstances and new knowledge about what is important.working day! This flexibility has enabled projects to start and begin to deliver useful benefits despite imperfect information; while allowing new needs to beNormally by now much more easily accommodated.we would haveexpected to drop Improved stakeholder and client satisfactioncalls as it is so By working more closely with its stakeholders, building iteratively andbusy. Its obvious acting on their feedback, HML has been able build trusted relationshipsthat there are a lot and a real feeling that they were a part of our product development.of card paymentonly calls and weare flying them.Customer feedbackis positive andconsultantfeedback is verypositive.”© HML 2012. All rights reserved. 13
  • AGILE IT AT WORK: PROJECT FORBEARANCE At the start or 2012, responding to a request from one of its clients, HML began a project to implement improvements to iConnect to support anticipated regulatory requirements proposed by the FSA.INDUSTRY Speed of response was critical to the client’s needs, but uncertaintyREACTION TO around what was really needed was high – HML was seeking to be first toAGILE IT: market – and operational usability was essential to ensure minimal impact to customers and call centre consultants.“I got the impressionthat [lean-agile During the start-up phase of the project, the team, through a series ofprinciples] were truly workshops with stakeholders, created a high level vision, a prioritised listembedded in the day- of high level requirements and an outline roadmap. Work then proceededto-day work of the using fortnightly iterations that planned, built and demonstrated newteams.” functionality. Regular retrospectives generated frequent improvement ‘experiments’ which drove constant adaptation and improvement in how the team worked.“I was surprised at just As the project progressed many items originally in the backlog werehow good the visual considered unnecessary, and many new items were added in responsemanagement was in IT to improved understanding of needs identified through thein terms of its variety demonstrations. Throughout the process, both the client and internaland complexity.” stakeholders were involved, and this has resulted in high levels of engagement and satisfaction.“I was greatly Key metricsimpressed by the IT Mobilisation time: 2 weeksdepartment...to see anIT team working so First demo of useable 2 weeks after mobilisation, andcohesively is something functionality: fortnightly thereafterwe can only dream of.” First delivery of useful features: 6 weeks after mobilisation, and monthly (on demand)Delegate thereafterresponses from a Number of software defects 0meeting of the escaped into production:Lean Service Internal stakeholder Consistently rated highForum, hosted at satisfaction:HML in April 2012.For more Client satisfaction: Consistently rated highinformation on theLean Service What the client said:Forum see: “The projects teams approach throughout has been one of collaboration best demonstrated by their invitation to me, to not only attend, but part-http://www.oeeuk.c facilitate the two day forbearance training event that was delivered to ourom/community- Credit Management colleagues.” (Compliance Manager)leanforum.asp “It has been a pleasure to work with the Forbearance project team. Communication has been excellent throughout the project, they have been responsive to requirements (including late ones) and all signs point to delivery meeting agreed scope and originally agreed timescale.” (Operations Manager)© HML 2012. All rights reserved. 14
  • ABOUT THE AUTHOR: Andy Lawrence, Lean-Agile Practice Lead Andy has over 20 years experience in delivering IT based solutions across a diverse range of industries, and has been leading and coaching software teams in lean and agile software development for the last decade. He has presented at conferences and industry events, and regularly contributes to groups such as Agile Yorkshire and Agile Testing in Finance. Andy joined HML in 2008, initially working with the Business Intelligence team before joining the IT department to lead the lean-agile implementation. Andy has been nominated in the Agile Coach or Mentor of the Year category for UK Agile Awards 2012.© HML 2012. All rights reserved. 15