Challenges Selling the Agile Development Approach to Managers and Users

Transcription

1 Challenges Selling the Agile Develpment Apprach t Managers and Users Birds f a Feather Discussin Ntes PMI SAC Prfessinal Develpment Cnference Nvember 24, 2009 Prepared by: Shail Thaker, Assciate Partner Ethier Assciates 600, Avenue S.W., Calgary, AB T2P 3T7 Phne: (403) Fax: (403) inf@ethierassciates.ca

2 Birds f a Feather Sessin Tpic Infrmatin Tpic Title: Tpic Descriptin: Facilitatr Name: Challenges Selling the Agile Develpment Apprach t Managers and Users Agile has been prven as an effective technique fr prject delivery. S why is it s challenging fr Agile teams t sell this apprach t business? This sessin will cver tips and techniques frm the sessin hst and will slicit ideas frm the participants. Shail Thaker, MBA, PMP Facilitatr Bi: Shail Thaker is an Assciate Partner with Ethier Assciates. Shail brings ver 22 years experience t the firm, with his last 10 years cnsulting with Ethier. He has previusly wrked in Africa, India and Eurpe, has an MBA and a PMP. Shail has extensive experience in prject management (traditinal, Agile and Scrum), prgram management, business analysis, business prcess innvatin, change management, and facilitatin. Shail has been managing prjects fr many years and has successfully sld prjects, Agile & Waterfall, using his understanding f what the business needs t make decisins. sthaker@ethierassciates.ca Cntact Number: Website: BOF Discussin Ntes Page 2

3 Definitin f Agile Agile sftware develpment refers t a grup f sftware develpment methdlgies based n iterative develpment, where requirements and slutins evlve thrugh cllabratin between self-rganizing crss-functinal teams. The term was cined in the year 2001 when the Agile Manifest was frmulated. Fr the purpses f this discussin, I am including all flavrs f Agile (e.g. Scrum, Extreme Prgramming) under the term, Agile. Cmmn Adptin Challenges that Agile Faces Business Perspective Used t preparing a requirements specificatin, and then frget abut the prject until IT delivers the final prduct Dn t want t cmmit full time resurces t the time required n Agile prjects Dn t want t priritize the requirements they are ALL imprtant r plitical issues setting pririties Management Perspective I want ne cst estimate Dn t like a cst range ( are yu hedging?) Want estimates that are easy t put int current budgeting prcess When will it be dne? What d yu mean it depends? Can read unwillingness t prvide traditinal estimate as a weakness i.e. the team des nt really understand the requirements Why are we using pints what are pints? - business initially finds the Agile estimates difficult t understand It is feeling vague what exactly am I apprving? IT / PMO Traditinal apprach: Plan Driven; Requirements / Design / Build Have created a system that is very prcess and dcument centric Fcus n risk avidance cntractual bias prcesses in place t reslve previus prject issues Very cmmitted t fllwing waterfall and existing prcesses have PMI certificatin and aspire t SEI-CMM Level 5 BOF Discussin Ntes Page 3

4 Agile seen t be cutting crners PMO des nt accept / understand Agile metrics r wants t enfrce all existing prcesses n Agile teams Attitude f Evangelical Agilists Evangelical Agilists are nt helping with the sale f Agile t rganizatins, and they are smetimes cming acrss as fanatical. Sme new Agile PMs d nt pssess the sft-skills required t sell Agile and bridge the gap with waterfall s they end up sunding like evangelists with cmments like: Waterfall desn t wrk Agilists dn t write dcumentatin All the dcumentatin is in the cde Agile teams dn t need a PM, QA r Architects The cst f change is flat Grup Discussin: What challenges have yu faced selling Agile prjects? BOF Discussin Ntes Page 4

5 What des the Business Need t Make a Decisin and Hw is Agile Nt Presenting This? IT/PMO Perspective IT cares abut methdlgies the details f hw we get things dne. They will want t learn mre abut Pair Prgramming, Test Driven Design, etc. The strngest challenge culd cme frm IT/PMO wh have established prcesses and methdlgies fr prject delivery. Need t acknwledge that Agile is nt a silver bullet and that in many situatins the waterfall methdlgies are superir. Where Agile Fits (types f prjects) Phtcpy Prcedural, well defined scpe, well understd, lts f experience E.g. Build & Deply a Duplicate Server Architectural Drawing Well defined scpe, sme element f risk, sme experience E.g. Upgrade Existing Applicatin Abstract Painting Lts f unknwns, fluffy scpe, new technlgy, creative slutin E.g. Custm sftware fr Marketing? Traditinal / Waterfall Agile BOF Discussin Ntes Page 5

6 Business Perspective In lts f cases, the business des nt really care hw IT delivers a prject delivery methdlgy is under the hd they just want results. The business wants new appraches explained in terms f Mney: cst savings and/r speed t market that drives mre revenue. The d nt really care abut sftware efficiency, elegance, supprtability, etc. Business acknwledges fr sme previus prjects when requirements were unclear created cst and schedule ver-runs and their needs were cmprmised versus met. The business wants t understand hw the new apprach will impact the delivery f their prjects in terms f cst, delivery time, and meeting their needs and bjectives. Shw the business (quantifiable benefits) hw Agile can help: Manage schedule / drive revenue by priritizing the features that are delivered Manage csts by cntrlling the features that are delivered and by cancelling early if the prject fails t deliver Manage delivery by seeing delivered features and by tracking team perfrmance using metrics Meet their needs and allw them t change these as they understand mre BOF Discussin Ntes Page 6

7 Cmparisns f Traditinal Schedule t Agile Schedule Abut 10% f the effrt in estimating gets 50% f the ptential accuracy - and eventually the accuracy f the estimate declines When starting t plan, decide where n the curve we wish t be? Custm Sftware Develpment Example Traditinal Apprach Make Changes Requirem ts Design Develp Test UAT Deply Agile Iteratins Unknwn duratin depends n level f custmer satisfactin / dissatisfactin with delivered slutin Deply fully tested, apprved, cre feature set t Prductin Decide if all needs met? As team delivers, accuracy f estimates keeps increasing, making frecasts mre valid Optinal Feature Set If Desired BOF Discussin Ntes Page 7

8 Cst f Changes This diagram shws hw cst ges up significantly in a waterfall/traditinal style prject significant if the business is nt very clear abut its requirements r the prject is taking n technlgy challenges that are new t the rganizatin. T the business this translates t:- Higher csts when taking the waterfall apprach fr any missed requirements r changes Metrics Agile can prvide a series f metrics that help the business predict prject csts, schedules, etc. As the Agile team perfrms, the metrics becme mre and mre valid. The waterfall apprach can shw prgress against stages (e.g. 85% cmplete) but that des nt help the business easily determine the frecasted cst and schedules. The business understands phased funding and this fits an Agile apprach very well. Funding culd be set up n fr the first set f features and the business decides if it wants t cntinue. BOF Discussin Ntes Page 8

9 Meeting Business (Feature) Needs One f the challenges with the traditinal apprach is the need fr a very detailed requirements specificatin at the start f the prject. The business is challenged by this apprach, as they tend t be thinking in terms f features and big picture and have nt really thught thrugh all the details. The Agile apprach takes an apprach that allws the business t fcus n a small set f features t see them wrking, and then t repriritize based n the delivered sftware essentially a very shrt feedback cycle, as depicted in the feedback curve diagram belw. T the business this translates t:- Much higher fit t their needs, and easily allws fr changes as they learn mre abut the slutin Cmparisn f Cst / Feedback Cycle fr Agile & Traditinal Grup Discussin: What appraches have yu seen, r are necessary, t successfully sell r apprve an Agile prject? Are there any pitfalls that we shuld avid when selling Agile prjects? BOF Discussin Ntes Page 9

10 Recmmendatins 1. Understand where yur rganizatin sits n the technlgy adptin curve (e.g. early adpters, laggards) this will affect yur selling strategy 2. Fcus n shwing quantifiable benefits t business 3. Find the right Business spnsr a. Cntrls budget b. Open minded t new appraches, willing t risk c. In a hurry, time cnstrained d. Des nt like current IT prcesses 4. Find the right prject a. Small scpe nly needs a few develpers b. New technlgy t rganizatin, but nt bleeding edge c. Has significant financial rewards tangible d. Can be built and deplyed using existing hardware etc. 5. Listen t the business s needs and make sure yu address them 6. Get IT t give their estimate using traditinal apprach (use this as a baseline) 7. Budget in phases 8. Use metrics t shw prgress and success a. Standard Burn-dwn charts, etc. 9. Be willing t cmprmise with IT/PMO a. Take an incremental Agile apprach vs. purist apprach b. Be willing t cmprmise n dcumentatin etc. maybe mve t end f prject c. Dn t call it Agile try ther terms like Iterative Develpment 10. Nthing sells like success get yur Business spnsr t be yur salespersn Grup Discussin: Any ther recmmendatins fr selling Agile prjects? BOF Discussin Ntes Page 10

11 References: Sftware-Develpment.aspx mates_the_new_spec BOF Discussin Ntes Page 11