The Enterprise and Scrum [1 ed.] 0735623376, 9780735623378

Citation preview

The Ent e r pr ise a n d Scr um by Ken Schwaber Publisher: M icr osoft Pr e ss Pub Dat e: June 1 3 , 2 0 0 7 Print I SBN- 10: 0 - 7 3 5 6 - 2 3 3 7 - 6 Print I SBN- 13: 9 7 8 - 0 - 7 3 5 6 - 2 3 3 7 - 8 Pages: 1 7 6

Ove r vie w From a leader in t he agile process m ovem ent , learn best pract ices for m oving agile developm ent wit h Scrum from t he skunk works ( sm all t eam ) t o t he shop floor ( t he ent erprise) . Managers get case st udies and pract ical guidance for m anaging t he change processes for applying Scrum in t he ent erprise.

Introduction This book is for t hose who want t o use Scrum t hroughout t heir ent erprise for product developm ent . Right now, you m ight have pocket s w it hin your ent erprise t hat use Scrum , and t hey are m ore effect ive t han elsewhere. You are at least part ially convinced t hat using Scrum t hroughout t he ent erprise m ight be a way t o m ake t he whole ent erprise m ore effect ive, but you could use som e help in figuring out how t o do so. This book is for you. There are m any reasons why your ent erprise can't develop and deploy product s and syst em s as rapidly, inexpensively, and wit h t he qualit y t hat you would like. You and your st aff probably can already list m any of t hem . Scrum won't solve t hem . Scrum is sim ply a t ool t hat will relent lessly and rut hlessly expose t hem . As you t ry t o build product wit hin t he Scrum fram ework, every t im e one of t hese im pedim ent s is reached, it will be exposed in a som ew hat painful way. You can t hen priorit ize it and syst em at ically elim inat e it . When t he im pedim ent s are m ost ly gone, Scrum is a fram ework t hat will enable t he product developm ent you desire. And it will cont inue t o be your w at chdog against any new im pedim ent or old im pedim ent s ret urning hom e for a visit . I 've gat hered quit e a few experiences and st ories as I 've worked wit h ent erprises adopt ing Scrum . I n t his book, I 've organized t hem int o guidance in t he areas t hat are m ost problem at ic. Som et im es t his is descript ive; ot her t im es I relat e t he guidance t hrough st ories. I t is OK t hat t here is no guidance in t he ot her areas. The ent erprise should figure out what is likely t o work best for it self and t ry t o use it . To t he ext ent t hat an approach doesn't work, change it and change it again so t hat it works bet t er and cont inues t o work bet t er. Scrum does not prescribe. Scrum includes general guidelines about how t o do developm ent and principles t o be applied when t hese recom m endat ion are insufficient . What does t his m ean? This m eans t hat people have t o learn t o t hink different ly. We want rules t o follow, but life and product developm ent are t oo com plex for a single set of rules t o suffice in all circum st ances. You have t o rely on decent ralized decision- m aking, because t here probably isn't one answer for every t eam any m ore t han t here is for every ent erprise. The first t hree chapt ers lay out t he plan for adopt ing Scrum . The next t wo chapt ers provide insight s int o som e habit s t hat im pede adopt ion and how som e ent erprises have coped wit h t hem . The rem aining

chapt ers provide t echniques for solving som e of t he knot t ier issues. These will help you, but your ent erprise's adopt ion will be different from anyone else's adopt ion. The only com m on ingredient is people, for bet t er and worse. When people rise t o t he occasion and work heroically in t eam s, not hing is bet t er. When t hey prefer t o lay back, play polit ics, and undercut each ot her, not hing is worse. You'll get t o see bot h, because Scrum will relent lessly expose everyt hing as you proceed. Not every ent erprise t hat t ries t o adopt Scrum will succeed. At t im es, you and your people will hat e Scrum . However, don't shoot it . I t is only t he m essenger. To t he ext ent t hat you and your ent erprise succeed, t hough, you will always know where you st and. You will know what you can do and can't do. Som et im es such t ransparency let 's us see t hings t hat aren't what we wish t o see. However, I find knowledge preferable t o uncert aint y and ignorance. The goal is for you and everyone in your ent erprise t o wake up looking forward t o com ing t o work, and for your com pet it ors t o wish t hey had never woken up.

Part I: Adopting Scrum This first sect ion describes how an ent erprise can adopt Scrum . Learning t o use Scrum would be pret t y sim ple and st raight forward if we didn't have habit s t o do t hings different ly. Fit t ing it int o our ent erprises, also, w ould be pret t y st raight forward if we already weren't organized and accult urat ed t o do t hings different ly. Changing ent erprise habit s and cult ure is required t o get t he benefit s of Scrum . I n t his sect ion, we assess whet her t hose benefit s are of enough value for you t o go t hrough t he effort . Then we look at how t o init iat e an ent erprise t ransit ion proj ect . This proj ect uses Scrum t o opt im ize your ent erprise's abilit y t o build and deploy product s. We t hen look at som e of t he changes t hat an ent erprise encount ers t o get t he benefit s. The chapt ers in t his sect ion are briefly described in t he following list : • • • • •

Chapt er 1, " What Do We Have t o Do t o Adopt Scrum ?" describes how t o assess whet her Scrum has enough value t o your ent erprise for you t o proceed. Chapt er 2, " Scrum qua Scrum ," describes st eps t o init iat e Scrum wit hin your ent erprise. Chapt er 3, " The First Year," describes t he first year of adopt ing Scrum . Chapt er 4, " Against Muscle Mem ory—The Frict ion of Change," describes som e of t he m ost ent renched habit s t hat im pede product ivit y. Chapt er 5, " Ent erprises in Transit ion," describes som e adopt ion proj ect s at several ent erprises. Read t hese in ant icipat ion of and preparat ion for your ent erprise's t ransit ion, for which guidance is provided in Sect ion 2.

Chapter 1. What Do We Have to Do to Adopt Scrum? I n t his chapt er: Scrum Requires a New Ent erprise Cult ure

4

Prove t o Yourself That I t I s Wort h t he Effort

5

Assess t he Type of Change That Will Occur

5

Caveat s

7

Consider Scrum as part of t he gam e of product and soft ware developm ent . Scrum lays out t he playing field and rules for t he gam e. Your ent erprise has t he players for t he gam e. They go on t he field and st art playing against t he com pet it ion. I f t hey are skilled, it shows. I f t hey don't yet work as a t eam , don't underst and t he rules, or have any ot her flaw in t heir capabilit ies, it is painfully obvious. Everyone on t he t eam knows what im provem ent s are needed—m ore coaching, m ore t raining, bet t er t eam work. When Scrum is used t hroughout an ent erprise, we have an ent erprisewide gam e of product developm ent . Coordinat ion is m ore im port ant t han it would be if j ust a single t eam was playing, and it 's harder t o achieve. ( Keep in m ind t hat a single depart m ent could have 100 t eam s.) Again, t hough, Scrum helps everyone underst and what needs t o be im proved. Every t im e product developm ent occurs, Scrum rewards excellence and exposes inadequacies. Scrum adopt ion has t wo aspect s. First , Scrum is rolled out . You t each everyone how t o play t he gam e of product developm ent using Scrum . You t each t hem how t o work t oget her in sm all t eam s. This st age t akes six t o t welve m ont hs. The second aspect is everyone in t he ent erprise im proving t heir gam e so t hat t hey are t he best possible ent erprise of t eam s working t oget her. During t his t im e, we im prove skills, t eam work, and everyt hing needed for excellence. Every t im e we play Scrum , we can clearly see how good we've becom e and what we need t o do t o get bet t er. To get really, really good requires t hree t o five years of cont inued im provem ent t hrough using Scrum in an ent erprise. St aying really good and perfect ing skills is an ongoing endeavor. Your use of Scrum will expose every reason why your ent erprise has t rouble building product s. Scrum will keep exposing t he problem s unt il t hey are fixed. Scrum does t his wit hin t he sim ple fram ework of building increm ent s of soft w are, it erat ion by it erat ion, or Sprint by

Sprint . The rules, roles, and t im e- boxes of Scrum are few and sim ple. Whenever t hey cause a conflict wit h exist ing pract ices, an im pedim ent has been encount ered and m ade visible. The ent erprise has t o choose whet her t o change t o rem ove t he im pedim ent or t o give up on som e of t he benefit s.

Scrum Requires a New Enterprise Culture The Scrum paradigm em braces change, unpredict abilit y, and com plexit y as inescapable const ant s in all product developm ent . This com plexit y and unpredict abilit y renders det ailed long- t erm predict ive plans m eaningless and a wast e of m oney. Wit h Scrum , a vision of a proj ect 's value is proj ect ed in a baseline plan. The proj ect m oves forward, Sprint by Sprint , t oward t he vision. I ncrem ent s are inspect ed every Sprint . Adapt at ions are t hen m ade t o t he proj ect t o opt im ize t he likelihood of realizing t he value. Advent ure Works, a gam e producer in San Diego, was t he first in it s indust ry t o benefit from Scrum . Joris Kalz, Advent ure Works' CTO, at t ended one of t he very first Scrum cert ificat ion sessions in 2003. Ent husiast ically, he went back t o Advent ure Works and adopt ed t he Scrum paradigm . His st ory is one of insight , persist ence, and hard work. The Advent ure Works st ory is one of cult ure shock and t hen redem pt ion. The product t hat was developed using Scrum was Vosod. I t began t o em erge in high- qualit y, regular increm ent s. Joris adopt ed a sust ainable pace of work, one of Scrum 's pract ices. Everyone worked eight - hour days. Som e people m ight look at t hat pract ice and t hink, " Oh, t hat m eans developers get out of working hard for t he com pany! " Quit e t he cont rary—a sust ainable pace yields higher product ivit y and qualit y product s. Advent ure Works was owned by a Japanese com pany. The Scrum pract ice of eight - hour workdays was unaccept able t o t he senior m em bers of t he Japanese m anagem ent . They dem anded longer hours, and t he 12- hour work days t hat were norm al prior t o Scrum were rest ored. Defect s rose 60 percent over t he next several Sprint s, m ore t han offset t ing t he delivery of increased funct ionalit y. Joris rest ored Scrum 's eight - hour workdays. When t he Japanese m anagers in San Diego drove by t he offices night aft er night , t hey again saw em pt y parking lot s and darkened offices. This was int olerable t o t hem . They report ed t o headquart ers t hat em ployees at Advent ure Works were indifferent and lazy. They recom m ended selling t he com pany. The

delivery of increm ent s of high- qualit y soft ware was good, but t hat was insignificant com pared t o t he perceived slot h and cult ural conflict . The Japanese parent com pany sold Advent ure Works t o it s Am erican m anagem ent in a m anagem ent buyout . The parent com pany was glad t o get rid of it . Two m ont hs lat er, Vosod was com plet ed and ready t o ship. Advent ure Works sold Vosod t o a gam e publisher for t wice t he price of t he buyout . Did it m ake sense for t he Japanese owners t o sell t he com pany when t hey did? Of course not , but t he t wist ing pat hs of change oft en don't m ake sense. People and cult ure are involved— people who have feelings, beliefs, percept ions, and vest ed int erest s t hat cloud t heir percept ions.

Prove to Yourself That It Is Worth the Effort The effort required t o adopt Scrum is huge, and only ent erprises wit h com pelling reasons will m ake t he effort . Your reason for adopt ing it m ight be unaccept able cost s, m issing funct ionalit y, inabilit y t o deliver soft ware, cust om ers going t o ot her providers, developers leaving, lengt hening release cycles, or your ent erprise's increasing inabilit y t o com pet e. Anot her com pelling reason is Scrum offers a significant ly bet t er way of building product s. Before you at t em pt an ent erprise- wide adopt ion, you m ust believe t hat your ent erprise has serious problem s t o fix and t hat Scrum is t he t ool t o help you. The first st ep in gaining t his belief is t o use Scrum on several proj ect s. Scrum is sim ple enough t o underst and from books ( som e of which are list ed in Appendix B) , but som e init ial Scrum Mast er and Scrum t raining m ight be helpful. ( Scrum t erm inology is fully defined in Appendix B.) Such t raining is available t hrough www.scrum alliance.org. Select som e high- value, high- risk init ial work. Conduct a com bined it erat ion planning m eet ing ( called a Sprint Planning Meet ing) and t raining session. Then st art Sprint ing. Conduct at least t hree Sprint s. You will see value. You will clearly know t he progress of a proj ect and be able t o easily accom m odat e changes. I n addit ion, you will see increased product ivit y. You have now seen Scrum 's value on som e sim ple proj ect s. Now go for t he j ugular. Select anot her proj ect —one t hat is difficult or one t hat t he ent erprise is having problem s wit h. Prove t o yourself t hat Scrum solves som e of your m ost knot t y problem s. I dent ify several pieces of im port ant funct ionalit y, which is enough t o get going. This is t he basis of t he Product Backlog. Form a Scrum t eam and have t hem Sprint several t im es. When t hey've done t hat , t he funct ionalit y should have

t he desired securit y charact erist ics, perform ance capabilit ies, and user experience as t he finished product . Ext rapolat e t he cost of t he funct ionalit y in t he t hird Sprint t o get an est im at e for t he ent ire proj ect . You have t o wait unt il t he t hird Sprint for people on t he t eam t o know each ot her and t he syst em t hey are developing well enough t o get a m eaningful ext rapolat ion. I f you are concerned whet her a com m ercially available package works as claim ed, subj ect it t o t he sam e process. Have Scrum t eam s build several pieces of high- value, t ricky funct ionalit y in t he package. Get early inform at ion on whet her t he package works as you need it t o work. Form ally t rain people in Scrum for t hese proj ect s. Courses are offered by t he Scrum Alliance ( www.scrum alliance.org) t hat will help t hem gain t he needed skills. Just like in baseball, a lit t le coaching helps a novice rapidly gain skills and t echnique.

Assess the Type of Change That Will Occur You should now be convinced t hat Scrum can help your ent erprise reach it s goals. Before you proceed wit h adopt ing Scrum , however, you should consider t he t ypes of changes t hat ot her ent erprises have gone t hrough. These changes have repeat edly been m ore ext ensive t han ot her ent erprises ant icipat ed because everyday pract ices are exposed as im pedim ent s. You can expect t he following changes and challenges: St aff t urnover will occur. Tw ent y- percent t urnover is com m on. Som e people say, " I don't like t his. I j ust want t o com e t o work, be t old what t o do, and go hom e at t he end of t he day not worrying about it ." We've changed t he ground rules wit h Scrum . People are asked t o com m it t o solving problem s in t eam s. Som e people m ight not want t his t ype of work. The t hird t hrough nint h m ont hs of t he change will be part icularly difficult . Problem s and dysfunct ions t hat have always exist ed in your ent erprise will be highlight ed at t his st age. They haven't been fixed yet because t hey are part icularly ent renched or difficult . Solut ions have been hard t o devise or achieve. When Scrum again highlight s t hem , ot hers on t he proj ect m ight wonder why t hey ever em barked on t he Scrum process. At t his point , look back and observe t he progress t hat has been m ade. Proj ect s are m oving forward, soft ware is being delivered, risks are being ident ified and rem oved, and people are

working t oget her. You will have t he courage t o cont inue m oving forward only by looking back at t he progress m ade. Conflict will occur. Expect conflict . Conflict is a sign of change. People have different opinions about how t hings should be done. A new way of operat ing m ust be conceived. Because m any ent erprises discourage conflict , people m ight not be skilled at resolving conflict . People need t o be t rained t o resolve conflict s. Product m anagem ent 's j ob will change and will be harder. Product m anagers and cust om ers are now Product Owners. They are responsible for m anaging t he proj ect s, Sprint by Sprint , t o m axim ize value and cont rol risk. They are account able t o senior m anagem ent for t he success or failure of t he proj ect . They are t he single, wringable neck. I f m em bers of senior m anagem ent want t o find out how a proj ect is doing, t hey will call t he Product Owner. They will no longer call engineering or a proj ect m anager. Engineering is account able for qualit y. The engineering organizat ion is responsible for figuring out how t o build and deploy a qualit y increm ent every Sprint . The qualit y will be t he sam e as t hat needed in t he final product . The Scrum Mast er will not allow t hem t o lower qualit y t o increase product ivit y. Com pensat ion policies need t o change. Scrum is about t eam heroics, not individual heroics. The m aj orit y of t he ent erprise's bonus and incent ive funds need t o be allocat ed based on t he t eam 's perform ance rat her t han t he individual's perform ance. I f a t eam does really well, reward everyone on t he t eam . Jobs will change. Som e exist ing j obs will disappear, and people will fulfill new roles. For inst ance, a proj ect m anager m ight becom e a Scrum Mast er. A funct ional m anager will no longer have a funct ion t o m anage and m ight becom e a Scrum Mast er or Product Owner. Career pat hs becom e far less im port ant t han cont ribut ion t o t he t eam and t he ent erprise. Managem ent 's prim ary responsibilit y will shift from com m and t o servant leadership. [ 1] Managers are responsible for t he perform ance of t heir area of t he ent erprise. Their usual t act ics are t o direct and com m and. They figure out what needs t o be done and t ell people who work for t hem t o do it . This hierarchically decom poses unt il t he bot t om person is act ually doing t he work. Wit h Scrum , m anagem ent 's responsibilit ies rem ain t he sam e, but t he philosophy and t echniques

change. Managers will lead and serve t heir st affs t o achieve t heir goals. They will rem ove im pedim ent s. They will guide, t rain, coach, m ent or, and get t heir people t o do t he best t hey can. Their role is very m uch like a parent : t o grow t heir people so t hat t hey are m at ure and self- m anaging These at t ribut es are best learned t hrough st udy and experience, not by being t old what t o do. [1]

Jam es Aut ry, The Servant Leader ( Three Rivers Press, 2004)

[1]

Jam es Aut ry, The Servant Leader ( Three Rivers Press, 2004)

Managem ent t urnover will occur. Managem ent is going t o be asked t o go t hrough significant changes. ( See t he change det ails in t he preceding paragraph.) They will do ext rem ely difficult work over t he next several years. Som e m anagers won't want t o. Up t o 20 percent of t hem m ight leave as t hey find t hat t hey don't like t he new way of working and m anaging. More people m ight not be t he answer. When we want m ore work done, we oft en hire m ore people. This is well docum ent ed as an ineffect ive approach. [ 2] Adding people t o product ive t eam s or dilut ing t he ranks of exist ing skilled people by spreading t hem am ong new t eam s reduces bot h m easured product ivit y and qualit y. I n m y experience, Scrum 's self- m anaging t eam s generat e at least 50- percent product ivit y im provem ent in t he first year of use, and m ore t hereaft er. Focus on im plem ent ing Scrum , not adding m ore people. [2]

Frederick Brooks, The Myt hical Man Mont h ( Addison Wesley, 1995)

Caveats You probably have t ried t o im plem ent new processes before. Please rem em ber t hat Scrum is less a process t han a t ool for you t o build processes appropriat e t o your ent erprise. Like any t ool, t here are right ways and wrong ways t o use it . Two caveat s t hat you should keep in m ind when using Scrum are as follows: Do not change Scrum . Scrum isn't a process t hat you m odify t o fit your ent erprise. I nst ead, it exposes every dysfunct ion in your ent erprise while you build product s. I t is your canary in a coal m ine. [ 3] Whenever people change Scrum , it 's because t hey have run int o a problem , dysfunct ion, or conflict t hat t hey do not want t o face and fix. I nst ead, t hey change Scrum so t hat t he problem rem ains invisible and

rem ains deadly t o your ent erprise. I f you allow t his t o happen, you will have j ust lost Scrum 's prim ary benefit . [3]

Coal m iners placed canaries in t he m ines t hey worked in because canaries are m ore sensit ive t o carbon m onoxide t han people. When a canary died, it was t im e t o get out of t he m ine.

Do not w ait . This book cont ains recom m endat ions, such as st art ing Scrum proj ect s or having m eet ings. Do not w ait t o get t hings in place before st art ing. St art im m ediat ely. Once you've st art ed, t he m ost im port ant im pedim ent s t o rem ove are ident ified in t he heat of t he m om ent —t he im pedim ent s t hat you want ed t o " get in place" prior t o st art ing. There is a t endency in ent erprises t o wait , t o plan, t o overt hink. Scrum forces you t o act , t o build t hings of value, and t o look in t he m irror and see your dysfunct ions. Act a non verba. I f you have t hought about t hese changes, considered t heir im pact on your ent erprise, and st ill want t o proceed, t he next chapt ers are for you.

Chapter 2. Scrum qua Scrum I n t his chapt er: Scrum Kickoff Meet ing

11

You decided t o proceed. Excellent ! First , I 'll describe t he adopt ion process. Then I 'll describe t he kickoff m eet ing for init iat ing it . You use t hree t ypes of Scrum t eam s t o adopt Scrum . The first t ype is a single Scrum t eam responsible for m anaging t he adopt ion. This t eam is called t he Ent erprise Transit ion t eam , or ETC. The second t ype of Scrum t eam is responsible for doing t he adopt ion work and causing t he ent erprise t o change. These t eam s are called Scrum rollout t eam s. The t hird t ype of Scrum t eam builds product s for t he ent erprise using Scrum . They are called Scrum developm ent t eam s. These t eam s are fully described in t he Scrum lit erat ure. All of t hese t eam s use t he Scrum process t o achieve t heir goals. We'll cover t he first t wo in som e det ail in t his chapt er. An ent erprise's senior m anagem ent is t he ETC Scrum t eam . The m ost senior execut ive in t he ent erprise is t he Product Owner. A Scrum Product Owner is responsible for direct ing t he work of a Scrum t eam . He or she does so from a list of work, t he Product Backlog, t hat always direct s t eam s t o do t he highest value work next . This is t he person who can cut t hrough organizat ional, depart m ent al, and personal conflict s for t he good of t he whole ent erprise. The Product Owner's st akeholders are everyone in t he ent erprise. The ETC t eam Scrum Mast er holds ETC t oget her and keeps it going using Scrum . He or she is t he person responsible for t he Scrum process being used correct ly. He or she m ust be a full- t im e, respect ed, and capable person wit hin t he ent erprise who has a deep knowledge of t he ent erprise. He or she m ust have det erm inat ion t o m ake Scrum adopt ion happen and an abilit y t o work wit h people. The rest of t he ETC t eam consist s of t he heads of developm ent , hum an resources, adm inist rat ion, and finance. I f t his is an ent erprise t hat develops product s and sells t hem ext ernally, t he heads of product m anagem ent , m arket ing, and sales are included in t he t eam . I f t his is an ent erprise t hat uses t he product s int ernally, t he head of t he business unit s t hat use t he product s and cause t hem t o be built are included in t he t eam . The ETC Scrum t eam com m it s t o a goal every it erat ion, or Sprint . The t eam m em bers t hen work wit h each ot her and do what ever is

necessary t o reach t hat goal. The goal of t he t eam t ranscends t he goals of any individual t eam m em ber. I ndividual success of t op execut ives t ranscending t eam success can result in t he failure t o change t he ent erprise. The ETC Scrum t eam can succeed in t ransform ing t he ent erprise t hrough t he use of Scrum only if it s m em bers work t oget her t o reach t he proj ect goals. Change can't happen wit hout t his t ype of t eam work, from t he t op m anagem ent levels of t he ent erprise t hrough every Scrum t eam . Team m em bers need t o t rust each ot her t o effect change, and t hey need t o be ready t o openly have conflict t o reach t he best solut ions possible. An excellent prim er for t his t ype of t eam w ork is The Five Dysfunct ions of a Team by Pat rick Lencioni ( Josey- Bass, 2002) . This book is an easy read t hat I recom m end for t he m em bers of any Scrum t eam , but especially t he ETC Scrum t eam . A priorit ized list of work t hat needs t o be done drives t he adopt ion. This list is called t he Transit ion Product Backlog ( TPB) . TPB is a t ype of Product Backlog, but it s product is a changed ent erprise. TPB it em s are defined by t he ETC t eam and also arise from Scrum developm ent t eam s, as t hey encount er im pedim ent s. The highest priorit y it em in t he TPB is t o kick off som e product developm ent proj ect s using Scrum . Do t his im m ediat ely, wit hout any delay. The rest of t he TPB is t he work required t o adopt Scrum . Som e of it rolls Scrum out t o all proj ect s and program s. Som e of it is organizat ional, engineering, and product m anagem ent changes. Som e of it is t he work needed t o rem ove im pedim ent s, resolve conflict s, and m ake changes. The ETC Scrum t eam creat es Scrum rollout t eam s t o perform t he t asks relat ed t o t he ent erprise change called for by t he highest priorit y TPB work. Rollout t eam m em bers m ight com e from m anagem ent or ot her sources. Team m em bers don't have t o work full t im e on t he rollout t eam . However, t heir availabilit y and com pet ence will dict at e t he pace of t he Scrum adopt ion and ent erprise change. Each t eam appoint s it s own Scrum Mast er. One m em ber of t he ETC t eam will be t he Product Owner for each t eam during each Sprint . Figure 2- 1 shows t he organizat ion of ETC.

Figur e 2 - 1 . En t e r pr ise t r a n sit ion pr oj e ct or ga n iza t ion

The ETC Sprint s are t wo weeks long. At t he st art of a Sprint , a rollout t eam select s high- value TPB it em s. The goal of t he Sprint is for t he rollout t eam t o rem ove t hese im pedim ent s and t o creat e ent erprise change t hat opt im izes product ivit y and effect iveness. These Sprint s are short er t han Sprint s for Scrum developm ent t eam s, whose Sprint s are norm ally one- m ont h long. The short er lengt h allows t he ETC t eam t o m ore closely m onit or ent erprise changes and t heir im pact . Each Scrum rollout t eam has a daily Scrum . The ETC Scrum t eam also has a daily Scrum in which it provides guidance and help t o t he rollout t eam s. Scrum Mast ers on developm ent proj ect s m ight also com e t o t he ETC daily Scrum t o ask for help in rem oving im port ant im pedim ent s t o t heir t eam 's progress. Scrum rollout t eam s can eit her be ongoing or form ed by t he ETC Scrum t eam prior t o a Sprint Planning Meet ing. These rollout t eam s m eet wit h t he ETC t eam at t he Sprint Planning Meet ing. An upcom ing rollout TPB is described, and t he Sprint is st art ed. High- priorit y TPB it em s m ight have t o be divided int o segm ent s so t hat t hey can be done wit hin a single Sprint . All rollout Sprint s st art and end on t he sam e day t o synchronize t he work involved. A Sprint Review is held at t he end of every Sprint . Tangible changes are dem onst rat ed. Som et im es a rollout t eam m ight have not hing t o dem onst rat e. This m ight m ean t hat t he wrong people were on t he Sprint or t hey weren't spending enough t im e on t he problem . Possibly, t he problem was t oo difficult t o solve as st at ed or in t he current condit ions. I f t his is t he case, t he ETC t eam should rest ruct ure t he TPB, t he rollout t eam , or bot h and t hen t ry again. The Scrum adopt ion process is form ally init iat ed wit h a Scrum kickoff m eet ing.

Scrum Kickoff Meeting A kickoff m eet ing init iat es t he Scrum adopt ion and t he ETC proj ect t hat is responsible for it s success. This m eet ing last s t hree hours and is at t ended by t he probable ETC t eam m em bers, as defined earlier. An agenda for t his m eet ing has t he following it em s: • • • • •

•

•

• •

Review Scrum Ensure t hat everyone present underst ands Scrum . Describe adopt ion process Managem ent learns how ETC will work and how it will cause t he Scrum adopt ion t o occur. Make decision Managem ent at t he m eet ing decides t o proceed wit h Scrum . Est ablish ETC Scrum t eam Form ally define t he ETC Scrum t eam com posit ion, m eet ing t im es, and m eet ing places. Kick off t he first Scrum proj ect s I dent ify t he first Scrum proj ect s for t he rollout . They should be num erous, be across t he ent erprise, require rollout and int egrat ion, and place st ress on t he ent erprise. They will st art building product im m ediat ely while ident ifying im pedim ent s t o product developm ent . Est ablish init ial Transit ion Product Backlog it em s I dent ify t he highest - priorit y work. These it em s usually include developing an ent erprise Product Backlog, developing and im plem ent ing int egrat ion facilit ies, and select ing and t raining Scrum Mast ers. I dent ify Scrum rollout t eam s I dent ify probable t eam m em bers t o be on t he first Scrum rollout t eam s, and assign som eone on t he ETC t eam t o not ify t hem of t heir part icipat ion and t he m eet ing schedules. Schedule t he first Sprint Planning Meet ing Set a dat e t o kick off t he first Sprint wit h a Sprint Planning Meet ing. Sooner is bet t er t han lat er. Close t he m eet ing

A m ore det ailed agenda for a kickoff m eet ing is shown in Appendix C, " Exam ple Scrum Kickoff Meet ing Agenda."

Chapter 3. The First Year I n t his chapt er: The First Mont h

13

The Second Mont h

15

What I f?

17

The Third Mont h and Beyond

18

We've looked at why and how t o adopt Scrum for your ent erprise. This chapt er lays out a probable t im eline for t he first year of t he Scrum adopt ion. The first m ont h will be t he m ost hect ic, and you'll feel a desire t o wait unt il t his is planned m ore t horoughly. Don't . The problem s t hat erode product ivit y and effect iveness in your ent erprise won't wait —t hey will cont inue t o hurt . The adopt ion m ay not be perfect , but it is self- correct ing. And, while it perfect s it self, t he problem s are being addressed.

The First Month The t im e has com e t o conduct t he first ETC Sprint Planning Meet ing. The t im e and dat e for t his m eet ing were est ablished at t he Scrum kickoff m eet ing, described in Chapt er 2, " Scrum qua Scrum ." Since t he kickoff m eet ing was held, m em bers of t he ETC t eam have form ed Scrum rollout t eam s for t he first Sprint . These t eam s and t he full ETC t eam part icipat e in t he Sprint Planning Meet ing. The Transit ion Product Backlog ( TPB) present ed at t he first Sprint Planning Meet ing, which list s t he first work t o be done, will m ost likely consist of at least t he following it em s: •

• •

Com m unicat e t o everyone in t he ent erprise why Scrum is going t o be used and how it will be rolled out . Com m unicat e t his oft en and in every way possible ( handout s, com pany m eet ings, depart m ent al m eet ings, and video conferences) . Com m unicat e how Scrum will affect t he ent erprise and t he people wit hin it . Provide Scrum t raining t o everyone in t he ent erprise, and inform t hem t he reason for t he adopt ion, what is planned, and what is expect ed of t hem . Em phasize t hat Scrum is not a new m et hodology, but inst ead is a workout process t o im prove t he ent erprise.

• •

• • • • • • • •

Provide a way for people t o ask quest ions and resolve issues about Scrum and it s im pact on t hem . Est ablish precondit ions t hat m ust be m et before a proj ect can use Scrum . These precondit ions can be separat ed int o m inim um , m edian, and opt im um phases so t hat proj ect s can st art prior t o everyt hing being in place. Creat e TPB it em s t o fulfill t hese precondit ions. I dent ify t he first proj ect s t o use Scrum . I dent ify t he Product Owner, Scrum Mast er, and t eam s for t hese proj ect s. ( All proj ect s st art wit h one t eam .) Define Scrum m et rics and t he m echanism s for gat hering and m anaging wit h t hem . Begin creat ing an ent erprise Product Backlog. I dent ify likely Scrum Mast ers. Assess com pensat ion policies t o encourage t eam work. Define Scrum proj ect report ing requirem ent s. Est ablish a Scrum Cent er.

Som e of t hese it em s are described in m ore det ail in Appendix D, " I nit ial Ent erprise Transit ion Product Backlog." The Sprint Planning Meet ing last s less t han one day. I t will be over when, according t o Scrum rules, t he Scrum rollout t eam s have m et wit h t he ETC Product Owner, select ed and com m it t ed t o a backlog for t he first Sprint , and figured out a plan ( Sprint Backlog) for fulfilling t heir com m it m ent s. Figure 3- 1 illust rat es t he Scrum im plem ent at ion process.

Figur e 3 - 1 . Scr um a dopt ion pr oce ss dia gr a m

The process shown in t his figure will be used, Sprint aft er Sprint , t o adopt Scrum t hroughout t he ent erprise. The TPB will grow as t he work required t o adopt Scrum becom es bet t er known and as t he im pedim ent s and changes are ident ified. Depending on t he det erm inat ion of t he ent erprise and t he leadership from t he ETC t eam , t he adopt ion will occur m ore or less quickly, and m ore or less painfully. Scrum adopt ion is a proj ect t o change t he ent erprise's processes, t he people who use t he processes, and t he cult ure t hat surrounds t he processes. An exam ple of t his is Ford Mot or Com pany, which is at t em pt ing t o change it s process for scheduling car m anufact uring. Leading t he proj ect is Mark Fields, who underst ands t he difficult y of im plem ent ing change. Mark had a sign creat ed and placed in Ford's Way Forward war room on which is writ t en: " Cult ure eat s st rat egy for breakfast ." [ 1] [1]

Wall St reet Journal, January 23, 2006

The adopt ion has st art ed. The first rollout Sprint s are underway.

The Second Month By t he st art of t he second m ont h, m any new Scrum developm ent proj ect s have been st art ed. A deadly sin is t o put off st art ing proj ect s unt il t hey are perfect ly st affed, form ed, and planned and have a Product Backlog in place. I m m ediat ely st art t he first Sprint for t he proj ect s m ost im port ant t o t he ent erprise. Suddenly, product increm ent s are being built by Scrum t eam s. At t he sam e t im e, every reason t hat you had for not im m ediat ely st art ing t he proj ect s can be ident ified as an im pedim ent . Put t hese im pedim ent s in t he ETC Transit ion Product Backlog, and fix t hem . Meanwhile, t he Scrum developm ent t eam s are building soft ware. Never wait for perfect ion; you can be adequat e and st ill use Scrum . You won't necessarily have everyt hing perfect ly in place, but t hat 's OK because you don't know what t his j ourney consist s of and where it will t ake you. But you'll be well arm ed because you are using Scrum t o guide your j ourney. The Scrum Mast er is responsible for rem oving or fixing anyt hing t hat m akes his or her t eam less product ive t han it could be. Som e of t hese t hings can be fixed by t he Scrum Mast er. But t he Scrum Mast er m ight not have t he aut horit y, knowledge, or scope t o fix ot hers. The Scrum Mast er t akes such problem s t o t he ETC t eam 's daily Scrum .

There, t he im pedim ent s are eit her quickly resolved or are put in t he TPB for priorit izat ion and lat er resolut ion. The unresolved im pedim ent s not ed by t he Scrum Mast er are placed on t he TPB along wit h t hose uncovered by t he ETC t eam , as shown in Figure 3- 2. While t eam s are using Scrum t o build product s, ETC is direct ing t he work t hat will m ake t hem m ore product ive.

Figur e 3 - 2 . Scr um r ollout

As t he ent erprise uses Scrum t o build product s, conflict s arise bet ween current pract ices and t he way Scrum works. Scrum is a highly opt im ized process for developing product s, wit h a side benefit of m aking visible anyt hing t hat get s in t he way of doing so. Scrum exposes every dysfunct ion in t he ent erprise. Most of t hese are known and old culprit s t hat have been t olerat ed. Now t hey are glaringly obvious and m ust be rem oved. These conflict s are put in t he TPB. The TPB frequent ly changes as new challenges and unexpect ed work are encount ered. The ETC t eam cont inually reviews and repriorit izes t he TPB t o reflect t hese changes. I t form s and reform s Scrum rollout t eam s every Sprint t o do t he next priorit y in t he TPB—t his is t he process of adopt ion.

Sources of Transition Backlog Impediments Many ent erprises use t he wat erfall process t o build product s. I n t his process, requirem ent s are t horoughly gat hered at t he st art of t he proj ect . These requirem ent s are progressively decom posed int o archit ect ures, designs, code, t est ed code, and docum ent at ion. Each

part of t he decom posit ion is done by expert s in t hat funct ion. The work of one funct ion is com m unicat ed t o anot her t hrough docum ent at ion and art ifact s. One would t hink t hat wat erfall habit s would be only in t he developm ent organizat ion. However, wat erfall habit s form everywhere in an ent erprise. Cust om ers are accust om ed t o t he wat erfall approach of developm ent . The hum an resources depart m ent is accust om ed t o set t ing up career pat hs and j ob descript ions t hat m at ch wat erfall processes. Finance is used t o funding and m onit oring wat erfall proj ect s. As you use Scrum , t he differences bet ween Scrum philosophies, pract ices, and habit s and t hose of t he wat erfall approach will creat e conflict . The way people t hink about and do t heir work will have t o change. These im pedim ent s never st op arising. As t op- priorit y im pedim ent s are fixed, new im pedim ent s becom e visible. As people com e and go in t he ent erprise, new im pedim ent s arise. As m arket needs change or any ot her st ress hit s t he ent erprise, new im pedim ent s becom e visible and hurt product ivit y. The following list describes som e ways t o ident ify im pedim ent s on an ongoing basis: •

•

•

Brainst orm ing Get any group of people in a room . They can readily ident ify current problem s. This is t rue for senior m anagers, m iddle m anagers, proj ect m anagers, and developers. The t hings t hat are wrong prior t o using Scrum will also be wrong when Scrum is used. The difference is t hat t he wrong t hings will be m ore painful, difficult , and frequent because t hey run count er t o Scrum pract ices. For inst ance, if t here are m ore act ive proj ect s t han developers, it will be very difficult t o form full- t im e Scrum t eam s. To solve t his part icular problem , st art only Scrum proj ect s t o which people can be assigned full t im e. Scrum Developm ent Proj ect s When a Scrum developm ent proj ect is underway, t he t eam and Product Owner will run int o im pedim ent s. These im pedim ent s are report ed t o t he Scrum Mast er at least as oft en as t he daily Scrum planning session, t he Daily Scrum . I f t he Scrum Mast er or t eam can't resolve t hese problem s on t heir own, t hey will be put in t he TPB t o be solved. Conflict When Scrum proj ect s get going, conflict occurs as people and organizat ions disagree on t he best way t o do t heir work. I f not rapidly resolved, conflict s becom e conflagrat ions t hat dest roy product ivit y. For inst ance, if an analyst is accust om ed t o always writ ing a specificat ion and giving it t o t he

program m er t o code, t his m ight no longer be needed or product ive when t hey are m em bers of t he sam e t eam .

What If? The Scrum adopt ion proj ect , led by t he ETC t eam , m ight encount er im pedim ent s in it s operat ion and it s Scrum rollout t eam s m ight fail t o deliver com m it t ed changes. Som et im es t his is because t he rollout t eam s don't consist of t he right people. I n t hese cases, you should inspect t eam com posit ion. I s t here adequat e aut horit y and dom ain knowledge on t he t eam ? Do people know how t o go about t he work? Som et im es people on t he Scrum rollout t eam s are delegat ing t he work t o subordinat es or aren't part icipat ing at all. They feel t hat t he change is t hen som eone else's problem . However, t he people on t he Scrum rollout t eam s com m it t o m aking change. They are t he ones who do t he work t o bring about t he change, and t hey cannot delegat e t hat work t o anyone else or blam e anyone else for t he com m it m ent not being m et . I f t hey aren't willing t o do t he work, t hey aren't t he right people t o have on t he t eam . Rem ove t hem , and reform ulat e t he t eam wit h t he right people. Maybe t he change t arget ed by t he Sprint is t oo big. I f t his is t rue, ask t he rollout t eam t o deconst ruct t he change int o act ionable pieces. Then have t he t eam select a TPB it em and init iat e anot her Sprint . Som et im es, t here are t oo m any im port ant changes t o be m ade. This is t he sam e problem t hat m any Product Owners have: t oo m uch work and t oo lit t le capacit y. Focus first on priorit izat ion. Are t he m ost im port ant t hings being done first ? Then focus on t eam com posit ion. I s t here a way t o add product ive people t o t hese t eam s? Then focus on progress. Even t hough t here are st ill m any t hings t o im prove, look back and savor t he changes already m ade. Then exercise pat ience and rest raint . I t t ook years t o build t hese im pedim ent s, bad habit s, and dysfunct ions. I t will cert ainly t ake years t o rem ove t hem . Regardless of which im pedim ent s you encount er, keep pressure on t he rollout t eam s t o deliver. Post ing t he TPB where it is visible t o t he ent ire ent erprise helps. Under m ount ing pressure, t eam s will reorganize t o becom e m ore product ive.

The Third Month and Beyond Take a st ep back and look at all t he t hings t hat aren't going well; look at all t he problem s t hat you and your ent erprise are st ruggling wit h.

Separat e t hese problem s int o t wo colum ns: problem s t hat Scrum has brought in, and problem s t hat always have been t here and Scrum is highlight ing. I n m ost adopt ions, t he second colum n cont ains alm ost all t he problem s you are st ruggling wit h. Scrum affords com plet e t ransparency. Everyt hing is visible. You are m ade fully aware when t he product ivit y, t he progress t oward goals, t he com pet ence of people t o do t heir j obs, t he willingness of people t o work t oget her t oward ent erprise or proj ect goals, and t he abilit y of engineering t o build com plet ed product s on t im e is less t han you desired or expect ed. Before you st art ed adopt ing Scrum , you m ight have suspect ed what t he problem s were t hat undercut t hese int angible ent erprise asset s, but now it 's obvious t hat t hese suspect ed problem s are reducing your ent erprise's abilit y t o build and deploy com pet it ive product s. At t his point in t he adopt ion cycle, m any people in your ent erprise are probably advising you t o change Scrum because it needs som e t weaking t o be com pat ible wit h your ent erprise. My advice is t his: Don't Do I t . The rules, roles, and t im e- boxes of Scrum are few and sim ple. The pract ices and st ruct ure of Scrum uncover problem s t hat are som et im es ugly and difficult t o solve. The norm al t endency is t o change t he aspect of Scrum t hat m ade t he problem s visible. Everyone will t hen feel bet t er and can proceed wit h t heir work j ust as t hey always have. Unfort unat ely, if you change Scrum , t he very reason w hy t heir work is less product ive t han it could be will again be obscured. Whenever I visit an ent erprise t hat is adopt ing Scrum , I look for t hese deviat ions from st andard Scrum pract ices. I n every inst ance, I have found an ent erprise problem t hat everyone want ed t o cont inue t o ignore. As changes are m ade by t he ETC t eam , accom m odat ions bet ween old ways of doing business and t he new m ight be sought . For inst ance, som e part s of a proj ect m ight st ill be using t he wat erfall process w hile ot her part s are using Scrum . However, care should be exercised t o ensure t hese accom m odat ions are t em porary and don't becom e a perm anent way of doing business. Som e ent erprises have t hought of m odifying Scrum t erm inology t o be m ore com pat ible wit h t he ent erprise's current pract ices. The hope is t hat t he im pact of t he change can be soft ened. Unfort unat ely, what usually happens is t hat everyone in t he ent erprise sees t his as a signal t hat t he inclinat ion t o change isn't a serious one. For inst ance, if Scrum Mast ers are st ill referred t o as a Proj ect Managers, t hey will

usually cont inue t o believe t hat t hey are responsible for t he success of t he proj ect and have aut horit y t o t ell people what t o do. The t erm inology of Scrum is abrasive t o st andard t erm inology and unusual so t hat everyone knows t hat a change is underway and t hat t hings are going t o be different . Som e problem s m ight require changing t he way t he ent erprise does business. For inst ance, sales people m ight be accust om ed t o asking engineering people t o whip up a quick prot ot ype t o help close a sale. This always seem ed t o work and not bot her anyone. Wit h Scrum , however, you can clearly see t he im pact of t his approach on a proj ect 's progress at t he Sprint Review. Because of t he ext ra t im e and effort needed t o fulfill off- t he- cuff request s, t he t eam probably won't finish everyt hing t hat it com m it t ed t o. You m ight have t o com e up wit h anot her m echanism for accom m odat ing t hese sales request s. Now t hat you can quant ify t he cost t o t he ent erprise of t he int errupt ion, you m ight even want t he sales people t o cost - j ust ify prot ot ypes in t erm s of cost s, ant icipat ed benefit s, and probabilit ies. Solving som e of t hese problem s requires m ore t han one at t em pt . Scrum m akes it obvious when a solut ion t o a problem isn't perfect or when a problem changes and a solut ion needs t o be ret hought . Don't t ry for perfect ion in a solut ion; " good enough" is t ruly good enough t o set t he ent erprise in t he direct ion of perfect ion. You and your m anagem ent t eam will have t o plot and schem e t o com e up wit h t he best t act ics. Exercises t hat help people underst and t he reasons for or benefit s of a change t o t heir daily work oft en help. Visit ing ot her people or ent erprises t hat have successfully adopt ed Scrum is oft en enlight ening. You m ight need t o devise and adopt m et rics t o encourage and t rack change. Be careful for unant icipat ed consequences t hese m et rics m ight have on ot her areas, t hough. Your t act ics will not always work. Expect t hat you will need t o m ake m any at t em pt s. Expect t hat t he solut ion m ight t ake som e t im e t o em erge. The rem ainder of t he book will provide you wit h som e insight s, t act ics, and furt her inform at ion for adopt ing Scrum . As you have already realized, t his adopt ion is really about opt im izing your ent erprise, and it will go on forever.

Chapter 4. Against Muscle Memory—The Friction of Change I n t his chapt er: Wat erfall Thinking

21

Com m and and Cont rol

23

Com m it m ent t o Defying t he Laws of Nat ure

24

Hiding Realit y

26

Sum m ary

27

I f you find yourself saying t hat your group's developers have sat isfied over 29 percent of t heir cust om ers wit h successful proj ect s, [ 1] t hey are probably relying on best pract ices, out st anding skills, cut t ing- edge qualit y, and a legacy of habit s t hat form int ellect ual m uscle m em ory. Muscle m em ory is a deep habit our m uscles develop by working t oget her. When t he ent erprise uses Scrum , t he developer's m uscle m em ory is inappropriat e and dam aging. [1]

Jim Johnson, My Life I s Failure , The St andish Group I nt ernat ional, I nc., 2006, p. 2

Expect m uscle m em ory t o exert it self. When a proj ect is going well, everyone is happy wit h Scrum . However, when st ress, a problem , or an unexpect ed failure occurs, everyone t ends t o t hrow away Scrum and revert t o t heir m uscle m em ory. Team s don't want t o self- m anage. They want t o be t old what t o do. Managers don't want t o let t eam s self- m anage. They want t o com m and t he t eam s in all m at t ers, down t o t he m inut est det ail. Team work is dum ped for individual heroics. Qualit y is abandoned. Everyone draws on what t hey t hink has worked best in t he past . Four m aj or m uscle m em ories hinder Scrum 's pot ent ial t o effect change. They undercut t he effort t o build product s bet t er. Let 's look at t hem .

Waterfall Thinking The wat erfall process em erged from proj ect m anagers' wishes t o overcom e com plexit y wit h predict abilit y. I t has been t he predom inant developm ent process used over t he last 25 years. Wat erfall is t aught

in universit ies, it 's described in m ost process books and ot her lit erat ure as t he correct approach, and t he Proj ect Managem ent I nst it ut e has form alized it . Every proj ect m anager knows wat erfall deep in his or her bones and feels it is correct . Habit s accrued from wat erfall developm ent are em bedded in ent erprises. I call t his " t he t yranny of wat erfall" ; it is inescapable. Even people who don't know it as t he wat erfall process t hink of it as t he " right " way or " t he way we've always done t hings." When som e people are asked t o use Scrum , t hey are profoundly uncom fort able. I t goes against t he grain and feels risky. They reply, " Yes, but ..." because t heir t rained response is t o prefer t he wat erfall pract ices. For inst ance, requirem ent s are handled very different ly w it h Scrum . About 50 percent of a t ypical proj ect is spent developing requirem ent s, archit ect ure, and design. During t he sam e proj ect , 35 percent of t he requirem ent s change and over 65 percent of t he funct ionalit y described by t he requirem ent s is never or rarely used. Regardless, in wat erfall, all requirem ent s, archit ect ure, and infrast ruct ure are fully det ailed before t he t eam builds funct ionalit y. Scrum views requirem ent s and archit ect ures as invent ory. I nvent ory is a liabilit y because if som e requirem ent s change or aren't used, t he t im e spent t o underst and t hem or design for t hem is a wast e. The Product Backlog, which list s t he requirem ent s of Scrum , only has t o be defined in t im e for a Sprint Planning Meet ing; t he work t o fully underst and it is perform ed only as t he Sprint t hat t ransform s it int o product occurs. Requirem ent s are developed and archit ect ure em erges in t he Sprint for which t he Product Owner request s t hem . To som eone st eeped in wat erfall t hinking, t his pract ice is im prudent , risky, and reckless. To develop code from incom plet e requirem ent s, t hey know, is j ust asking for t rouble. A wat erfall archit ect t old a Scrum archit ect t hat t he only way t o build a solid archit ect ure was t o t hink it t hrough up front , before any code was built . The second archit ect said he t hought t hat building it as requirem ent s em erged m ight creat e a m ore st able archit ect ure because it would be proven, piece by piece. Let 's look at t he im plicat ions of anot her wat erfall habit , funct ional specializat ion. The Product Owner discusses t he Product Backlog wit h t he Scrum t eam . Toget her, t he t eam m em bers discuss t he requirem ent s and creat e designs, code, t est s, and docum ent at ion. A wat erfall t radit ionalist believes, however, t hat only a designer can design, only a program m er can code, only a qualit y assurance ( QA) person can t est , and only a t echnical writ er can writ e docum ent at ion!

I was at t ending a Sprint Review Meet ing. The Scrum Team had select ed five it em s from t he Product Backlog for t he Sprint . Only one it em was finished. The t eam m em bers said t hat t he QA ( t est ing) people on t he t eam hadn't com plet ed t heir t est ing. However, a Scrum t eam is cross- funct ional. The ent ire t eam is responsible for building com plet ed pieces of funct ionalit y every Sprint . I t wasn't t he QA people who didn't finish t he t est ing—t he Scrum t eam didn't finish t he t est ing. Scrum count s on everyone chipping in t heir best effort t o do t he work. When funct ional expert ise is necessary, t he people wit h t hose skills t ake t he lead, but anyone can do t he work. Trey Research ( TR) , our first hypot het ical com pany, develops acoust ic product s. TR was ready t o int roduce a new radio. Thousands were in t he warehouse ready for shipm ent . Dr. Trey is t he founder and CEO. As Dr. Trey read t he user m anual in his office, his frown got deeper and deeper. Finally, he called t he t echnical writ ing m anager, Mat t hias Berndt . Dr. Trey said he was very disappoint ed in t he docum ent at ion; it was unusable. Berndt agreed, but said t hat it accurat ely reflect ed t he way t he radio worked. Dr. Trey kept his calm as he asked Berndt t o go t o t he warehouse, open a radio box, and see if it w orked t he way t he user docum ent at ion indicat ed. Two hours lat er, Berndt appeared in Dr. Trey's office wit h an open box and t he user m anual. Berndt said, " Much as I hat e t o say t his, Dr. Trey, t he m anual accurat ely reflect s t he radio's operat ion." Dr. Trey lost his t em per. He asked Berndt how he could have let such a t errible radio be built . Didn't Berndt know t hat t he radio was unaccept able? Berndt agreed, but he said t hat he had not hing t o do wit h t he radio unt il aft er it w as built . Dr. Trey grew even m ore t roubled and asked, " You m ean, even t hough you've worked here 23 years and know our radios inside out , you don't have anyt hing t o do wit h t heir design? You only docum ent t hem aft er t hey are built ?" Berndt confirm ed t his. This dysfunct ional approach was t he im pet us for TR t o adopt Scrum . Now everyone on a cross- funct ional t eam at TR designs t he radios. Dr. Trey knows t hat if t he radio's design doesn't m eet t he approval of t he engineers, t echnical writ ers, and t est ers, it shouldn't be built .

Command and Control Workers are best able t o figure out how t o do t heir work, not t heir m anagers. The work is com plex and has unexpect ed nuances. I f workers are bound by som eone else's inst ruct ions, t hey aren't free t o do t he work t he best way possible.

At t endees at t he Cert ified Scrum Mast er class exam ine t he product ivit y of self- m anagem ent t hrough an exercise. First , a cont ained space of approxim at ely 400 square feet is est ablished. Chairs, t ables, and ot her obst acles are liberally sprinkled t hroughout t he space Everyone is placed in a pair, each pair consist ing of a boss and a worker. The exercise is for t he bosses t o get t heir workers t o t ake 60 full st eps in t wo m inut es using t he com m ands of st art , st op, left , right , fast er, and slower. At t he end of t wo m inut es, about 50 percent have gone 60 paces. The rest have gone fewer paces. I n t he second part of t he exercise, pairs are broken up. Everyone is a worker who m anages his or her own act ivit ies. Each is free t o use t he previous com m ands or com e up wit h m ore appropriat e com m ands. Everyone is asked t o t ake 60 full st eps and t hen st op. Everyone is done wit hin one m inut e. The self- m anagem ent of t he second exercise has doubled product ivit y. And because m anagers are now also workers, product ivit y has quadrupled. Cert ified Scrum Mast ers know t hat self- m anaging Scrum t eam s are m ore product ive. The front 10 percent of t heir m ind is sold on selfm anagem ent . But t he back 90 percent knows t hat t hey are st ill in charge. I f anyt hing goes wrong, t hey will st ep in and t ell t he t eam what t o do. We have been t rained t hat t his is t he best way t o absolut ely m ake sure t hings go right . The com m and and cont rol habit is very difficult t o discard. I t t akes t im e for Scrum t eam s t o gel and st art perform ing. Som e t eam s require m ore support t han ot hers. The Scrum Mast er is responsible for t eaching self- m anaging t eam work t o t he t eam . For inst ance, if t he t eam com es t o t he Scrum Mast er saying, " This Product Backlog it em is t oo large for one Sprint ! What do we do?" , it isn't t old t he answer. I nst ead, t he Scrum Mast er leads t he t eam t hrough t he process of figuring out how t o deconst ruct t he backlog. The Scrum Mast er t eaches; t he t eam learns and finishes t he exercise. The next t im e a sim ilar sit uat ion arises, t he t eam will know how t o act independent ly. The m om ent t he Scrum Mast er t ells t he t eam what t o do and how t o do it , he or she exert s com m and and cont rol. I n com m and and cont rol, t he Scrum Mast er believes he or she is responsible for product ivit y and problem solving. I n self- m anagem ent , t he m anager t hinks t hat he or she is responsible for t eaching t he t eam self- m anagem ent and problem solving. One proj ect t hat I init iat ed included m ore t han 50 developers. New developm ent had t o be done in conj unct ion wit h m aint enance of t he exist ing syst em . A reasonably good Product Backlog was in place. I spent several days reviewing em ployee files and resum es, as well as

t alking wit h t he m anagers, t rying t o decide t he best t eam com posit ion. Aft er t hose several days, I had a headache. So I called all t he developers int o t he room . The Product Owner reviewed wit h t he developers t he upcom ing proj ect and t he Product Backlog. I described t he rules for com posing Scrum t eam s and det erm ining t heir size. We t hen asked t he developers t o organize t hem selves int o t eam s. We t old t hem t he t eam s didn't have t o be perm anent but t hey should give it t heir best shot . Wit hin four hours, t hey had form ed t heir own t eam s. The t eam s creat ed agreem ent s am ong t hem selves about how t he t eam s would cooperat e. During t he next Sprint , several t eam m em bers shift ed t o ot her t eam s. At t he end of t hat Sprint , t he developers t old us t hey were pret t y happy wit h t he t eam com posit ion. They asked if t hey could cont inue t o change as needed, however. We, of course, gave perm ission—we didn't have any bet t er ideas!

Commitment to Defying the Laws of Nature I live in Bost on and frequent ly work in New York Cit y. I n j ust 45 m inut es, t he Delt a Airlines shut t le can t ake m e from Bost on's Logan Airport t o New York's LaGuardia Airport . I som et im es pack m ore t han one m eet ing int o a day because of t his convenience. One day, I was up first t hing in t he m orning and down t o New York for a m eet ing. I got back t o LaGuardia by 2: 00 P.M. t o cat ch t he 2: 30 shut t le t o Bost on. I had an end–of- day m eet ing in downt own Bost on at 4: 30 P.M. This schedule would have worked, except LaGuardia was fogged in and all t he aft ernoon flight s were delayed or canceled. I went over t o t he Hert z count er. I t old t he Hert z clerk t hat I needed t o be in Bost on in 90 m inut es and want ed a car. She looked at m e st rangely. Apparent ly, m y need couldn't be m et . The laws of t he road, t he t op speed of t he cars available, and t he dist ance bet ween Bost on and New York Cit y m ade m y requirem ent pit iable and im possible t o sat isfy. The laws of physics t hwart ed m y wishes. Now consider a Product Owner at TailSpin ( our next hypot het ical com pany) who has m et wit h her Scrum t eam prior t o t he first Sprint . She handed out a present at ion wit h 12 bullet it em s. She t old t he t eam t he 12 it em s had t o be done and t he release needed t o ship wit hin six m ont hs. The t eam looked blankly at t he Product Owner and t old her t hat , even wit hout knowing m ore det ails about t he proj ect , it was im possible t o do. The Product Owner answered, " I f we don't deliver t hese feat ures by t hen, we cannot sell t he product , so it has t o be done." Just like m e in New York, t his Product Owner needed som et hing t hat wasn't possible.

Business runs on com m it m ent s. When you m ake a com m it m ent t o som eone else, you have given your word. The ot her person arranges his business accordingly, count ing on you t o do what you say. This underst anding is based on t rust and is a t rem endous source of efficiency. Let 's give ourselves a short t est on com m it m ent . Read t he following exercises and see if you can com m it t o fulfilling t he ot her person's needs. •

•

Som eone asks you t o com m it t o having som e it em built for t hem . She asks you for t he dat e on which it will be finished and for t he price t hat it will cost . You spend som e t im e wit h her t rying t o underst and exact ly what she want s, but t he det ails are elusive. Also, you are going t o have t o handcraft t his t hing. You aren't sure of t he exact skills of your w orkers or t heir availabilit y. Also, t he flu has been sweeping t he t own, and it could hit your t eam . The t echnology for building t his it em has worked so far, but a new release is com ing out wit h m ixed reviews. The person asking for t he com m it m ent also t ells you t hat she m ight need t o change som e t hings along t he way. Do you com m it ? Som eone t ells you t hat he want s a product by a specific dat e. You m ust do t his t hing because he has already com m it t ed t he product by t his dat e t o som ebody else. He want s you now t o back up his com m it m ent wit h your com m it m ent . You aren't sure exact ly w hat t he whole com m it m ent is, but t he ot her person has power over your career and salary. Do you com m it ?

Of course, it is im possible t o openly com m it in eit her circum st ance. You j ust don't know. You m ight feel t hat you have no choice but t o com m it in t he second inst ance, but you had bet t er have som e t ricks up your sleeve in case you get in t rouble. Pressuring som eone t o com m it t o an out com e regardless of what he or she believes is possible is a bad habit . I f t he person under pressure is honest , she won't prom ise anyt hing. I f she is cornered, she m ight m ake an undeliverable com m it m ent . Neit her alt ernat ive—a lack of com m it m ent or a false com m it m ent —is helpful if you need som et hing t o happen. Our m uscle m em ory t ells us t hat we can ask our engineering t eam for a com m it m ent . The engineering t eam 's m uscle m em ory is t o provide one, regardless of t he circum st ances. Where t he wat erfall process is in vogue, we have no choice but t o do so. But we have ot her opt ions when Scrum and it erat ive, increm ent al processes are used. These Scrum alt ernat ives are present ed in dept h in Chapt er

9, " The Relat ionship Bet ween Product Managem ent / Cust om er and t he Developm ent Team ."

Hiding Reality Our next hypot het ical com pany is Coho, one of t he largest resellers of cars in Europe. Senior m anagem ent was rolling out Scrum t o im prove it s abilit y t o int roduce new capabilit ies t o cust om ers. I n t he first Sprint of t he first proj ect , t he Scrum t eam s delivered m ore funct ionalit y t han t hey had com m it t ed t o. Everyone, from senior m anagem ent t o t he cust om ers, was excit ed and pleased. For t he second Sprint , t he Scrum t eam s com m it t ed t o a large am ount of Product Backlog. Two weeks int o t he Sprint , t he t eam s realized t hey were in t rouble. When t he t eam s got t oget her, t hey all had t he sam e st ory: t he funct ionalit y was significant ly m ore com plex and difficult t han t he first Sprint . Of t he 24 pieces of funct ionalit y t he t eam s had com m it t ed t o, t hey figured t hat t hey m ight com plet e 7 or 8. Aft er t he way everyone had cheered t hem on at t he first Sprint Review, t hey feared what would happen if only 33 percent of t heir second Sprint were done. The t eam s decided t he only way t hey could deliver everyt hing was t o drop t est ing and refact oring; t hey would j ust slap t he new funct ionalit y on t op of t he old. They figured t hat by com m it t ing t o far less for t he t hird Sprint t hey would have t im e t o go back and fix it all. One of t heir Scrum Mast ers asked t hem what t hey were doing. The Scrum Mast er realized t hat Scrum is about em pirical progress and t ransparency, so t he Product Owner always knows what is going on and can m ake t he best decisions. Wasn't t he approach t he t eam decided t o t ake hiding t hings from t he Product Owner? Weren't t hey pret ending t hat t hings were done when t hey weren't ? The t eam s, aft er expressing t heir fears t hat t he Product Owner m ight fire all of t hem , went t o t he Product Owner and showed him where t hey were and what problem s t hey were running int o. The Product Owner looked at t hem and said, " I knew you overcom m it t ed. I was going t o ask you what was going on. I hoped m aybe you knew som et hing t hat I didn't . Well, I 'm really glad you cam e t o m e." The Product Owner and t eam s reduced t he com m it m ent s t o m at ch t heir new findings and proceeded, Sprint by Sprint , t o build a great new syst em . When I discuss t his kind of fear at courses I t each, t he at t endees' own fear is palpable. The soon- t o- be Scrum users don't t hink t hat t ransparency, or t rut h, is accept able where t hey work. They t ell m e

t hat t hey will be fired if t hey t ell t he t rut h. Trut h isn't what t heir cust om ers want t o hear. They t ell m e t heir cust om ers will find som eone else who will lie t o t hem if t hey don't . I have seen t his in class aft er class for five years. People in product developm ent t hink t hat t heir cust om ers want t o hear news only if it is good news and would rat her hear a lie t han t he t rut h. " Lying" is a harsh word. But what else do you call saying t hat som et hing is t rue when you know it not t o be t rue? What else do you call m isleading som eone wit h inform at ion or holding back inform at ion t hat would have led t hem t o bet t er decisions? The Product Owners want t o believe in m agic, and t he developers support t he belief by lying. " Can you do t his proj ect by t his dat e?" " Sure, no problem ." The developers are aware of t he com plexit ies t hat cause changes t o t heir original est im at es. They are aware t hat t he cust om er is unhappy. I f a proj ect m anager is approached by a cust om er 60 percent of t he way t hrough a proj ect and asked how t he proj ect is going, t he proj ect m anager doesn't really know. She knows t hat som e t hings are going well. She also know s t hat som e t hings are not going so well. She also knows t hat she hasn't checked up on som e t hings t hat could prove crit ical. However, saying " I don't know" is unaccept able, so proj ect m anagers have learned t o say, " Right on," " Right on t arget ," " Piece of cake," or anyt hing equivalent t hat will get t he cust om er t o go away and leave t hem t o t ry t o get everyt hing on t im e, on cost . Basically, t hey lie. I t is sim pler t han exposing all t he nuances and com plexit ies t hat add up t o " I don't know." Proj ect m anagers m ight also believe t hat lying saves t im e. But because Scrum relies on t ransparency, m isrepresent at ion undercut s t he ent ire applicat ion of Scrum . I f t he Product Owners do not know exact ly w here t hings st and at any point in t im e, t hey will be unable t o m ake t he best decisions possible about how t o achieve t heir goals. They need t he best inform at ion possible, whet her t hey view it as good or bad.

Summary The it erat ive, increm ent al nat ure of Scrum causes change wit hin t he ent erprise. The ent erprise m ust adapt t o m ont hly proj ect changes, not j ust change at t he very end. A proj ect produces pot ent ially usable increm ent s of t he whole syst em every m ont h. Team s produce com plet e pieces of t hat increm ent daily. This frequency of com plet ed work causes change.

Dysfunct ional behavior t hat was hidden becom es visible. Problem s caused by t he dysfunct ional behavior are m agnified. As you solve t he dysfunct ional behavior, don't t hink t hat t he solut ion is com plet e. For 25 years, every habit described in t his chapt er has provided bet t er solut ions t o people in your ent erprise t han anyt hing else has. Now t hese people are going t o t ry som et hing bet t er, som et hing t hat even feels right . But when t he problem s of product developm ent and m anagem ent arise, your people are going t o feel naked. They haven't accrued m uscle m em ory in t hese new ways yet . So, because it feels safe—j ust for now—t hey ret urn t o t hese habit s, t he old- reliable habit s. Your ent erprise and it s people will t ake four st eps forward, t hree st eps back, t wo st eps forward, one st ep back. They w ill cont inually progress, but t hey will bem oan t heir inabilit y t o ignore and t ranscend old habit s. Scrum , however, won't t hem let ignore t he consequences of t hese habit s.

Chapter 5. Enterprises in Transition I n t his chapt er: Cont oso

29

Hum ongous

32

Woodgrove Bank

35

Lit ware

37

Ent erprises t hat see value in Scrum decide t o m ove forward. This chapt er present s cases of com panies t hat have m oved forward wit h Scrum . ( I have changed t he real nam es of t he com panies and people involved t o fict it ious nam es.) These were courageous ent erprises, m ot ivat ed by insight and need. No ent erprise in it s right m ind would wholeheart edly st art using Scrum ot herwise. Adopt ing Scrum in an ent erprise is like looking int o t he abyss, girding oneself for an epic j ourney, and t hen m aking t he plunge. What will be discovered and have t o be conquered is different in each ent erprise; what is com m on is t he courage t o st art and t hen persist . Most ent erprises t hat have a com pelling need t o change t ake t he easy way out —t hey hire m anagem ent consult ant s, buy anot her business t o dist ract t hem selves, or reorganize. Scrum is soul- searching by exam ining failures and dysfunct ions, not based on philosophical whim . I t is a perilous j ourney, but probably t he only one wort h m aking, because it is t he serious business of self- im provem ent . I t is t aking a hard look in t he m irror every day, every m ont h, and doing som et hing about what one sees. Every ent erprise t hat uses Scrum plot s a different course. The people are different . The problem s are different . The urgency of t he problem s is different . The only com m onalit y is Scrum as a t ool for change. We'll look at ent erprises I 've had experience wit h t o illust rat e som e lessons t hat can help your ent erprise effect ively im plem ent Scrum . I n all of t hese exam ples, t he com panies saw value first and t hen plunged int o Scrum adopt ion.

Contoso Cont oso builds value- added card product s, such as gift cards issued in various dollar am ount s. Cust om ers include ret ailers, banks, insurance com panies, and m alls. I t has a sophist icat ed core syst em , feat uring a value- added card t em plat e t hat let s cust om ers define t he specific

feat ures of t heir value- added card. The developers at Cont oso cust om ize t he t em plat e t o uniquely brand and sell t he cards t o consum ers. Cont oso's abilit y in t he past t o rapidly creat e sophist icat ed product s had m ade it a m arket place leader. For inst ance, if your com pany want ed t o sell som eone a value- added card t hat let t hem buy only cert ain product s m ade by specific m anufact urers during a cert ain dat e range, Cont oso could easily handle t his. The value- added product would be specified, and a fixed- price, fixed- dat e cont ract would be signed bet ween your com pany and Cont oso. The proj ect t o develop it would t ypically last four or so m ont hs. Cont oso's business m odel is t o at least break even on t hese proj ect s. The profit is generat ed by t he t ransact ion fees collect ed when consum ers st art using t he value- added cards.

Situation Cont oso cust om ers were angry. A significant num ber of proj ect s t o build cust om ized value- added cards were lat e or didn't deliver exact ly what t he cust om er want ed. The proj ect t eam would look at t he specificat ions in t he cont ract , work wit h t he account m anager for t hat cust om er, and develop what it t hought was correct . The newer cont ract s had som e sophist icat ed feat ures requiring changes in t he core product , which oft en t ook longer t han t he cont ract allowed. Everyone worked a lot of overt im e, over and over, t o m inim ize t he dam age. However, t he dam age was accum ulat ing. An increasing num ber of cust om ers were unhappy. St aff t urnover at Cont oso was nearing 50 percent per year. An em ployee survey of t he developm ent organizat ion indicat ed t hat only 15 percent of em ployees were pleased t o be working t here. New challenges arose. Exist ing cust om ers envisioned m ore product s for t he upcom ing holiday season; t hey insist ed on put t ing severe penalt ies for lat e delivery int o t he cont ract s because t hese product s were useless if delivered aft er t he holidays. A furt her challenge was t hat success wit h one value card in one m arket place caused everyone else t o want t o provide a card wit h even m ore sophist icat ed funct ionalit y. Cont oso was overwhelm ed. The num ber of new cont ract s far exceeded it s capacit y t o deliver. Cont oso's developm ent organizat ion couldn't keep up. Cont oso's success was in danger of unraveling. Com pet it ion arose as Cont oso st ruggled t o m eet it s com m it m ent s. Experienced developers were burnt out and leaving. Cont oso couldn't hire and t rain new developers fast enough t o m eet t he dem and.

Cont oso invest igat ed t he possibilit y of using offshore developm ent organizat ions t o add j ust - in- t im e capacit y. The vision was t o t rain key people in an offshore com pany, and t hey would t hen t rain t he rest of t heir organizat ion. As volum e rose, t he offshore organizat ion would supply m ore and m ore people unt il dem and was m et . I t was a perfect solut ion—ext ensible resources on dem and. Except , it didn't work. The offshore com panies t ook t oo long t o com e t oget her, and it was difficult t o synchronize changes t o core funct ionalit y. Even m ore chaos and dissat isfact ion ensued.

Application of Scrum Senior m anagem ent at Cont oso had read several papers about Scrum and were hopeful t hat it would help. Their back was against t he wall, and t hey were ready t o t ry anyt hing. As t hey said, it couldn't get any worse. Cont oso had a m at ure process im provem ent organizat ion. I t had previously perform ed a value- chain st udy, which is a Lean Thinking [ 1] pract ice t hat ident ifies wast eful pract ices, on t he cust om er change request process. Over 30 st eps for handling any change request were ident ified. They sim plified t he process t o five st eps. [1]

Jam es P. Wom ack and Daniel T. Jones, Lean Thinking ( Free Press, 2003)

I n an appalling m ove cont rary t o everyt hing t hat I 've ever said, Cont oso adopt ed Scrum whole hog. Wit hin t wo weeks, t he process im provem ent organizat ion had convert ed all exist ing work t o Scrum . I t form ed new Scrum t eam s, appoint ed Scrum Mast ers, and found Product Owners. I t gave overview courses. There were 29 new Scrum t eam s, 29 new Scrum Mast ers, and 29 new Product Owners. The process im provem ent organizat ion was a t op- down, com m and and cont rol, m et rics- driven group. I t im plem ent ed m et rics t o m onit or t he progress of Scrum proj ect s. The VP of t he process organizat ion m et daily wit h all senior m anagem ent t o review im pedim ent s, progress on cont ract s, and t rends in t he m et rics. Problem s were really, really t ransparent . Fixes were rapidly devised and deployed. Plus, product ivit y m ore t han doubled wit hin t he first t hree m ont hs of adopt ing Scrum .

Outcome An em ployee survey aft er j ust t wo m ont hs of using Scrum showed over 85 percent of t he em ployees pleased t o be working at Cont oso. Em ployees were even recruit ing t heir friends. More product s were being com plet ed on t im e wit h t he funct ionalit y t he cust om er needed. Many cust om ers were shift ing from punishing fixed- price, fixed- dat e cont ract s t o short , t wo- page t im e and m at erial cont ract s. The cust om ers felt so in cont rol of t he product developm ent and t he risks involved t hat t hey t rust ed t heir abilit y t o st ay in charge of t he developm ent . The cust om ers would " hire" a t eam for six m ont hs t o build t he product t hey envisioned. I f t he t eam got done earlier, t he cust om er would have t he t eam ret urn for t he next product . One cust om er had a fixed- price, fixed- dat e cont ract t hat called for delivery wit hin six m ont hs. When Cont oso delivered in six m ont hs, t he cust om er wasn't ready for t he product . The cust om er had hedged it s bet s, assum ing t hat Cont oso would probably be lat e.

Additional Comments Cont oso becam e t he m arket place leader for value- added cards, out perform ing all it s com pet it ors. I t s accom plishm ent s at t ract ed t he at t ent ion of a m uch larger financial product s com pany, TailSpin. TailSpin saw t wo opport unit ies. Cont oso would fit nicely int o it s port folio. Also, TailSpin was having increasing t rouble building it s own product s. I t s m anagem ent hoped t o learn from Cont oso expert ise. Cont oso was a piece of coal t hat becam e a gem , and it was t hen was acquired by TailSpin and t urned int o coal dust . TailSpin t hought of people as resources t o solve problem s rat her t han people t o be enabled. Because TailSpin viewed it s em ployees as plug- and- play com ponent s, t he com pany t ried m ixing in cheaper offshore " resources" on proj ect s. Product ivit y was cut in half, qualit y dropped, and com m unicat ions wit h t he offshore vendors went bad. Cust om ers went from j oyously m anaging t im e and m at erial cont ract s t o again dem anding fixed- price, fixed- dat e cont ract s. I n one t elling episode, TailSpin m isint erpret ed t he idea of collocat ed t eam space. TailSpin t hought collocat ion was t o save m oney, so it collocat ed t he ent ire developm ent organizat ion in one room . Desks were pushed next t o each ot her in rows unt il over 200 developers were cram m ed int o one room . The developers called t his a Scrum et eria, since it rem inded t hem of a high- school cafet eria.

People m ake Scrum work. They are present ed wit h problem s, t hey m ake com m it m ent s, and t hey creat ively excel in solving t he problem s. Scrum happens bot t om - up. But if t op m anagem ent doesn't underst and and lead, t he ent erprise will not be able t o sust ain t he product ivit y and creat ivit y provided by it s em ployees.

Humongous Hum ongous is one of t he nat ion's largest bank- based financial services com panies, wit h asset s of approxim at ely $96 billion. I t provides ret ail and com m ercial banking, consum er finance, and invest m ent banking product s and services t o individuals and com panies.

Situation Hum ongous' I nform at ion Technology ( I T) organizat ion consist s of over 1,000 people wit h a new developm ent budget of over $100 m illion. The developm ent organizat ion had t rouble reliably delivering syst em s t hat sat isfied it s int ernal cust om ers. As a rem edy, t he Senior VP of developm ent acquired and rolled out a m aj or, m odern m et hodology, Really I m proved Process ( RI P) . I t s rollout was planned and execut ed by t he Soft ware Developm ent Support Cent er wit hin t wo years. Unfort unat ely, not hing im proved and t he int ernal cust om ers rem ained unhappy. As a next st ep, t he Senior VP m et weekly wit h each proj ect m anager in his conference room t o review key proj ect m et rics. Proj ect m anagers realized t hat any slips could result in career dam age. The Senior VP was replaced by Mark Bebbingt on, a seasoned professional who had successfully used Scrum on m any crit ical proj ect s. He sum m ed up t he sit uat ion by not ing t hat t he users hat ed I T. Users had t urned t o buying packages. Mark decided t hat Scrum was appropriat e at Hum ongous. Scrum 's philosophy of personal account abilit y and em powerm ent wit h creat ivit y were needed.

Application of Scrum, Phase 1 Mark didn't " roll out " or " im plem ent " Scrum . He underst ood t hat it isn't a m et hodology. People have t o want t o use it for t heir proj ect s t o be successful. Mark decided t hat he would use t he " osm osis" approach. He focused only on proj ect s where bot h t he user and t he proj ect t eam want ed t o use Scrum . Their successes would becom e visible and ot hers would follow. Mark provided Scrum t raining t o his m anagem ent and t o proj ect m anagers and users who expressed int erest . He also

t rained t he Soft ware Developm ent Support Cent er so t hat it could support any proj ect t hat decided t o use Scrum . At t he sam e t im e, Mark decided t o m ake Hum ongous a m ore hospit able place for soft ware developm ent . He st art ed rem oving any out st anding problem s or im pedim ent s. He init iat ed a t ransit ion Scrum . His m anagem ent list ed and priorit ized t he m aj or problem s wit h soft ware developm ent at Hum ongous. This list becam e t he t ransit ion Product Backlog, wit h Mark as t he Product Owner. He t hen st art ed Sprint s, st affed by his ent ire m anagem ent t eam , t o rem ove t hese im pedim ent s. As im pedim ent s were ident ified in Scrum proj ect s, t hey were added t o t he Product Backlog. Creat ing t hese t ransit ion Scrum t eam s becam e on ongoing process. Mark also set precondit ions for any proj ect t hat want ed t o use Scrum . For inst ance, a proj ect had t o have a full- t im e st aff, a com m it t ed Product Owner, and a willingness t o use collocat ed space. When a proj ect m et t hese crit eria, t he Soft ware Developm ent Support Cent er t rained and support ed it .

Outcome, Phase 1 Aft er 18 m ont hs, several crit ical proj ect s were vividly successful using Scrum . A new syst em for all Hum ongous t ellers had even been present ed t o t he Board of Direct ors. I t was an im pressive m odel of developm ent and user collaborat ion. However, Scrum 's root s weren't very deep at Hum ongous. The skill level of m ost developers was low wit h regard t o Scrum . Alt hough t he developers were using t he vocabulary, m any t hought t hat at t ending a Daily Scrum was what Scrum was all about . Then t hey would t ell ot hers t hat t hey were " Scrum m ing." Many cust om ers hadn't bought int o Scrum . They st ill liked giving t heir requirem ent s t o developm ent and not having any m ore responsibilit y for t he proj ect . I T m anagem ent also largely hadn't bought int o Scrum . They m out hed t he words and said t he right t hings. But t hey cont inued t o behave as t hey always had. To paraphrase t heir at t it ude, " I really know how t o m anage, and I 'm going t o st ick wit h what has worked before." Despit e t op execut ive support wit hin t he I T organizat ion and a fert ile environm ent , Scrum had not becom e t he norm al way for soft ware t o be developed wit hin t he com pany. Most em ployees were st ill com fort able wit h t heir j obs and t he way t hings had always been done. They saw Scrum as som et hing t hat would pass, j ust like all t he ot her

novel approaches seen over t he years. However, whenever a cust om er had a crit ical proj ect , t he cust om er was dem anding t hat t he Hum ongous developm ent t eam s use Scrum . These proj ect s set a benchm ark wit hin t he user com m unit y for anyone who had an urgenct request and cared t o devot e t im e t o it .

Situation, Phase 2 I n t his phase, Mark now has som e capit al t o work wit h. Som e users are ext rem ely pleased wit h I T. The at t it ude of t he Board of Direct ors has becom e posit ive. Som e developers are very product ive and work t o m ake t heir users happy wit h t he best solut ions possible. Everyone knows Scrum , and t he vocabulary is widely used. The quest ion Mark now faced is how t o use t his capit al of goodwill t o expand t he beachhead.

Application of Scrum, Phase 2 Mark decided t o shift from osm osis absorpt ion of Scrum t o som et hing m ore dram at ic and visible. Mark's organizat ion support s five m aj or groups wit hin t he bank. Henrik Jensen is t he head of one of t hese groups, consum er banking. He decided t hat he had enough evidence t o require all his people t o use Scrum . Mark t alked wit h t he head of Henrik's I T group. He agreed t o go from cosm et ic change t o real change using Scrum t o do all of Henrik's proj ect s. To m ake t his change happen, Mark and Henrik got everyone t oget her and set t he ground rules. Everyone was expect ed t o use Scrum fully, and overall result s were expect ed t o im prove. The Soft ware Developm ent Support Cent er would now focus all of it s support , t raining, consult ing, and coaching t o proj ect s in t his one group. All proj ect s would be subj ect ed t o " Scrum audit s" by t he Soft ware Developm ent Support Cent er t o det erm ine correct Scrum usage. The Soft ware Developm ent Support Cent er pulled t oget her m et rics t o include " sm ells" t hat are int angible, but t elling. For inst ance, if a t eam isn't collaborat ing during t he Daily Scrum and t he proj ect can't be clearly underst ood by an out sider, self- m anagem ent isn't occurring. I f t he t eam and t he Product Owner aren't collaborat ing during t he Sprint Review, t he Scrum st eps of inspect ion and adapt at ion aren't occurring. I f t he Product Owner is surprised during t he Sprint Review, he or she isn't working closely enough wit h t he t eam . I f an up- t o- dat e Product Backlog burn- down chart and Product Backlog isn't post ed at t he Sprint Review, t he Product Owner isn't m anaging t he proj ect . The

Soft ware Developm ent Support Cent er decided t hat t he prim ary m et ric it would m easure would be surprises. Any surprises would be indicat ors of incorrect use.

Outcome, Phase 2 Mark and Henrik have changed t heir organizat ions, and progress is being m ade. Aft er t he consum er banking division begins it s adopt ion of Scrum , t he ent erprise will have anot her group st art ing down t he right pat h.

Additional Comments Scrum helped Hum ongous achieve som e crit ical successes and avoid som e pot ent ially devast at ing failures. The ent ire ent erprise becam e m ore com pet it ive and profit able as a result of using Scrum . However, it isn't nearly as com pet it ive and profit able as it could be. Proj ect s st ill wast e t im e writ ing requirem ent s docum ent s. They are far less product ive t han possible. They are producing lower qualit y funct ionalit y t han desirable. However, t he beachhead is in place, and a bet t er way t o build soft ware is evident t o bot h developers and users. The leaders now m ust cont inue t o lead.

Woodgrove Bank Woodgrove Bank is a very large, innovat ive financial services com pany. By parsing credit profiles and closely assessing risks, Woodgrove Bank has ext ended credit t o m arket segm ent s largely ignored by it s com pet it ion. By offering flexible credit product s wit h rewards, Woodgrove Bank has built one of t he largest card- holder bases and card asset s in t he world. By dynam ically t racking t he profile of each of it s cust om ers, t he bank provides services t hat m axim ize revenues. For inst ance, if you call support for any reason and your last paym ent has been no m ore t han t hree days lat e and your overdue am ount is less t han 10 percent of t he t ot al due, a 30- day high- int erest deferral plan is offered t o you. Over t he last seven years, Woodgrove Bank's abilit y t o creat e innovat ive funct ionalit y in it s credit product s has slowed. At first , it seem ed t o j ust t ake longer t han usual t o add som e new feat ures. Event ually, new feat ures st art ed breaking ot her part s of t he credit card syst em t hat had previously worked. The relat ionship bet ween I T and t he business degraded as I T was unable t o deliver what was needed

on t im e. Maint enance grew t o consum e over 40 percent of all developm ent cost s. Woodgrove Bank's credit card processing was it s best m oney- m aker. The profit s were incredible. Unfort unat ely, ot her financial inst it ut ions not iced t his. They st art ed em ulat ing t he credit card product s t hat previously had been Woodgrove Bank's undisput ed dom ain. Worse, t he ot her financial inst it ut ions were now able t o add m ore feat ures t o t heir credit cards fast er t han Woodgrove Bank could. Three years ago, Woodgrove Bank decided t hat it had t o rewrit e it s core credit card processing applicat ion t o be m ore st able and am enable t o new funct ionalit y. The Mobius Proj ect , a 30- m ont h proj ect t o rebuild core credit card processing capabilit y, was init iat ed under a wat erfall process. This was a very com plex effort , and t he com pressed proj ect schedule didn't help t he process. During t his proj ect , t he com pet it ion kept eat ing away at Woodgrove Bank's m arket share. The developers were pressured t o get t he proj ect done. The new syst em was t rem endously im port ant . Woodgrove Bank successfully t ransit ioned t o t he new credit card processing syst em in 2006, having successfully survived Mobius's t ight proj ect schedule and a high- risk im plem ent at ion st rat egy.

Application of Scrum I n 2004, t he CI O set a goal of cut t ing t im e- t o- m arket in half by t he end of 2005. As part of t hat effort , t he CTO and a sm all group of int ernal consult ant s looked int o Scrum as a w ay t o help solve t his problem . Several proj ect s w ere st art ed using Scrum , and t he value was obvious t o t he ent ire ent erprise. I n 2005, m ore difficult proj ect s were pilot ed using Scrum . They were st ill screened, t hough, and select ed only if t hey looked like good fit s. They were st acked wit h t op- not ch em ployees t o see whet her Scrum proj ect s would work under ideal condit ions. As t hese proj ect s succeeded, larger and m ore com plex proj ect s were pilot ed wit h cont inued success. An Agile Cent er of Excellence was form ed. Program offices run by Scrum cham pions began t he process of organizat ional change. One group st art ed seven t eam s concurrent ly on t he sam e plat form s and had great success. Throughout t he year, t raining st aff in Scrum and selling t he idea t o t he rest of Woodgrove Bank cont inued. To ram p up m ore quickly, out side consult ant s were relied on t o help Woodgrove Bank avoid pit falls.

I n 2006, t he CI O set a goal t o have m ore t han 50 percent of t he ent ire I T port folio delivered using Scrum . This goal was successfully m et by t he t hird quart er. An underlying goal was t o cem ent Scrum as a w ay of t hinking and conduct ing business. To m ake Scrum part of t he cult ure, t he CI O conduct ed frequent open space m eet ings and regular inform at ional m eet ings. Top- not ch t rainers were cont ract ed t o get proj ect s going and t o m ent or t he t eam m em bers t hroughout . Scrum was used on all t ypes of proj ect s from very large, com plex, and int errelat ed work t o ent ire pipelines of enhancem ent s and defect fixes. Best of all, t he relat ionship bet ween int ernal cust om ers and I T was significant ly repaired. The m ot ivat ion for using Scrum shift ed from st opping t he bleeding t o leveraging it t o creat e com pet it ive advant age for Woodgrove Bank. Scrum was coupled wit h Lean Thinking t echniques t o creat e a weapon used when com pet ing wit h t he very large com pet it ors in Woodgrove Bank's space. One of t he biggest areas of growt h for Scrum was in work out side of I T. Operat ions, m arket ing, com pliance, and m any ot her t eam s began leveraging what I T learned by adopt ing Scrum for all com plex proj ect s. Even advert ising cam paigns used Scrum . Woodgrove Bank also m ade t he t ransit ion away from relying on ext ernal consult ant s and expert s. The bank began using int ernal consult ant s and Scrum Mast ers t o support new t eam s. Woodgrove Bank now em ploys a form al m ent oring program , where experienced coaches work wit h new Scrum Mast ers. Cert ified coaches are also plugged int o t he com m unit y t o encourage cont inued learning and growt h. The m ent oring program and focus on com m unit y has enabled Woodgrove Bank t o rapidly scale it s use of Scrum while m aint aining t he level of qualit y in t he t eam s. Regular com m unit y event s are used t o share experiences and keep everyone on t he sam e page. Lean Thinking and Scrum are being part nered as Woodgrove Bank goes forward. Lean Thinking value st ream m apping is used proact ively t o ident ify areas of wast e t hat can be rem oved. Scrum is used t o m anage t he proj ect s as well as em pirically ident ify furt her areas of wast e and ot her im pedim ent s.

Litware Lit ware is a t ypical independent soft ware vendor ( I SV) . I t has been selling product s t o soft ware developers for over 20 years. I t s revenues are around $100 m illion per year. Lit ware releases new versions of it s product s annually. Product m arket ing prepares a m arket ing

requirem ent s docum ent t hat carefully it em izes all new funct ionalit y and requirem ent s. These are priorit ized as " m ust have," " should have," and " nice t o have." The program m anagem ent office prepares a det ailed plan t hat , when followed, result s in an appropriat e new release. The creat ion and validat ion of t his plan requires t wo t o t hree m ont hs t o com plet e. Then work st art s.

Situation Release 3.51 was t ypical. The 120 developers began analyzing t he requirem ent s docum ent and designing t he new release. At t he sam e t im e, t hough, new requirem ent s began t o appear. The plan was updat ed. By t he fift h m ont h, everyone was get t ing a fam iliar sinking feeling. There was t oo m uch work left t o m eet t he scheduled release dat e. The developers st art ed sim plifying t he design. By t he sevent h m ont h, as m ore changes kept arriving, t he developers st art ed t o work long hours and weekends. Everyone was feeling pressured and worried. To increase product ivit y, t he developers also st opped redesigning t he code t o handle new funct ionalit y. They inst ead " plast ered" new code on t op of exist ing code. Unit t est ing disappeared along wit h code and design reviews. " Alpha release" was short ened t o one week t o fit in som e last - m inut e funct ionalit y. The developers didn't have t im e t o fix all t he report ed bugs. I n t he end, release 3.51 was t hree weeks lat e. I t didn't cont ain all t he last - m inut e requirem ent s and was of m arginal qualit y. Nevert heless, t he developers were proud t hat t hey had m oved it out t he door. They could now st art t o lead a norm al life, see t heir fam ilies, and fix som e of t he m ost egregious bugs. On t he Monday following t he release, Lit ware's CEO called for a m eet ing wit h everyone in t he developm ent group. He surprised everyone by t elling t hem t hat t hey were not get t ing a bonus t his year. They were flabbergast ed. They had worked t heir heart s out and forgone a norm al fam ily life for at least four m ont hs! But t he CEO rem inded t hem t hat t he release had been lat e and didn't have everyt hing t hat had been asked for. Already t he cust om ers were com plaining about t he poor qualit y. The CEO t hen paused, looked at t he haggard developers and said, " By t he way, you look pret t y bad. Maybe you should t ake bet t er care of your healt h."

Application of Scrum The developm ent group at Lit ware select ed Scrum for it s pract ice of sust ainable pace. They reasoned t hat if t hey weren't going t o get a bonus, at least t hey wouldn't be worn out aft er t he next release! No ent erprise had ever select ed Scrum for such an unflat t ering reason. The VP of Developm ent , St an Hat z, had no problem selling Scrum t o t he CEO and m anagem ent . Everyone had been so dissat isfied wit h t he process for release 3.51 t hat t hey said, " I t couldn't get any worse! " I worked closely wit h St an t hroughout t he Scrum im plem ent at ion at Lit ware. There were days when St an and I despaired of ever undert aking t he proj ect . Every problem t hat had been ignored t o dat e suddenly was visible, big, and ugly. St an could cont inue forward only when he looked back at t he progress already m ade. We also not iced t hat every problem we encount ered had been at Lit ware long before Scrum was known. When we im plem ent ed Scrum , however, t hey becam e evident . For exam ple, t he developm ent group at Lit ware had previously st ruggled t o get a release shipped by t he scheduled dat e. Scrum dem anded t hat t hey have a full increm ent every Sprint . Everyt hing t hat had m ade t his difficult t o do yearly was now difficult m ont hly. At t he end of j ust one Sprint , however, t he developers w ere able t o show m anagem ent funct ionalit y t hat was pot ent ially shippable. Everyone want ed t o build on t his success, so t heir willingness t o work t hrough t he problem s increased. Problem s were seen in t erm s of t heir im pact on t his m ont hly progress, rat her t han as isolat ed event s t hat could be ignored. For inst ance, if t he daily build of soft ware wasn't successful, ot her daily builds m ight not be successful. And by t he end of t he Sprint , not hing m ight be available for viewing and shipping. The feedback was im m ediat e, and t he consequences were t angible and near- t erm .

Outcome As Lit ware's m anagem ent wat ched release 4.1 em erge, Sprint by Sprint , t hey saw an opport unit y. The user conference was com ing up. The user conference was a great social event , but it hadn't been very useful for real product inform at ion because no real product was available. Usually, m arket ing would present screen m ock- ups and prot ot ypes of what t he upcom ing release m ight look like. This t im e t hey had a part ially developed product act ually working, and t he funct ionalit y was of t he highest value t o t he cust om ers and prospect s.

Why not show t hem t he act ual product ? A cont ingent from t he developm ent ent erprise was invit ed t o dem onst rat e t he part ial release at t he user conference. The cust om ers were ecst at ic. They were t hrilled t o be asked t heir opinion based on real funct ionalit y. The developers were delight ed t o collaborat e wit h m arket ing and cust om ers about what t o do next . The ent ire experience was ext rem ely grat ifying and reinforcing for everyone involved. At t he user conference, one of Lit ware's largest cust om ers, Woodgrove Bank, had been im pressed by som e of t he funct ionalit y in release 4.1. The Lit ware salesm an handling t he bank's account , Danny Fort e, report ed t o t he VP of Sales, t hat Woodgrove Bank want ed t o buy m ore copies of Lit ware's new release 4.1 if Lit ware would j ust add a couple of addit ional pieces of funct ionalit y. Then Woodgrove Bank would be willing t o license an addit ional $14 m illion dollars wort h of product . Fourt een m illion dollars isn't m uch m oney t o huge ent erprises, but t he opport unit y t o add it t o t he $100 m illion annual revenue at Lit ware was very com pelling. I t was so com pelling t hat t he Vice President of Sales t alked t o t he CEO, who t old St an t o m ake it happen. St an t hen t old t he developers, " Make it happen, no m at t er what ." I n t he soft ware indust ry, t his m eans t o build t he addit ional funct ionalit y int o t he product and keep t he sam e dat e. Just do it . Three weeks before t he scheduled release dat e, I visit ed Lit ware t o check up on it s progress. When I got off t he elevat or at t he developm ent floor, I knew som et hing was wrong. There was no noise. A charact erist ic of an ent erprise using Scrum is com m unit y, people working t oget her on ideas, collaborat ing over different approaches, sharing in work. No noise was not good noise. I n t he work areas, t he t eam m em bers all had t heir heads down at t heir workst at ions, looking grim . There was no j oy, no excit em ent , no sharing. I gat hered a group of t he developers and asked what was going on. They replied t hat t he overt im e was killing t hem . I asked how t his could be since Scrum called for a sust ainable pace. They t old m e t hat t he addit ional $14 m illion dollars from Woodgrove Bank would m ake t he financial year. Wit hout t he new funct ionalit y for Woodgrove Bank, t he t arget release dat e was Decem ber 1. Wit h t he new funct ionalit y, t he release dat e should have changed t o January 15, but it had been ordered t o be done by t he t arget dat e. St an had t old t hem t o do what ever it t akes.

Developm ent velocit y is a m easure of t he developer's abilit y t o t urn requirem ent s int o shippable funct ionalit y across t im e. A significant increase in developm ent velocit y was required t o build t his new Woodgrove Bank funct ionalit y by t he init ial release dat e. Velocit y increases are gradual, t he result of bet t er developm ent t ools and pract ices, and of bet t er t eam work. How could t he velocit y have increased so quickly? The developers t old m e what I suspect ed. They increased t heir velocit y by working night s and weekends and reducing t he am ount of work by cut t ing qualit y. I becam e irrit at ed. I asked t he developers how t his was different from release 3.51, when t hey were exhaust ed, t he product was shabby, and t he dat es and funct ionalit y were m issed. Had t hey forgot t en? The developers said t hat t hey hadn't forgot t en, but St an had t old t hem t o do it , so t hey had no choice. I knew St an well by t his t im e and was surprised. When I went t o see him , he was st unned. He hit his forehead wit h his hand and said, " I absolut ely forgot ! When t he CEO and VP of Sales cam e t o m e, I knew t hat we needed t o do it for t he business, so I revert ed t o old form . My old habit s t ook over, and I did what I used t o do. Now we are building t his release wit h poor qualit y and exhaust ed developers j ust like before." St an decided t o get t he developers back on t he t rack t o building a qualit y product at a sust ainable pace. Because t he sale t o Woodgrove Bank was crit ical, he asked t he developers t o include it as qualit y funct ionalit y! We t hen calculat ed t he new delivery dat e for release 4.1. I t was eight weeks aft er t he init ially planned dat e, including t im e t o rest ore lost qualit y and build t he new funct ionalit y. St an called t he CEO t o confirm t he new schedule. Adding $14 m illion dollars t o t hat year's revenues was at t ract ive, but was t he cost of t he eight - week delay accept able? A m eet ing was set up for t he next day wit h t he CEO, t he VP of Sales, t he VP of Market ing, and t he Chief Financial Officer ( CFO) . I n t he m eant im e, St an and I calculat ed t he cost of t he release's delay. I ncluding addit ional developm ent cost s, delayed m aint enance revenues, and several cust om ers t hat we m ight lose, t he probable cost was $5 m illion dollars. At t he m eet ing, t he VP of Sales st art ed by saying, " I m ay not be a PhD in Mat hem at ics, but $14 m illion dollars looks at lot larger t han $5 m illion dollars. Let 's do it ! Right , Danny?" He looked over at t he Woodgrove salesm an. But , Danny wasn't m eet ing his eyes. When a

salesm an doesn't m eet your eyes, it is a very bad sign. So, he again asked, " Right , Danny?" Danny looked up and said, " Well, I don't act ually have a signed cont ract yet ." The VP of Sales at t hat point asked t o reconvene t he m eet ing t he next day. When we got back t oget her, Danny wasn't wit h us. ( He was no longer wit h Lit ware.) I t t urned out t hat he not only didn't have a cont ract , t he person he had been dealing wit h didn't have t he aut horit y t o sign a cont ract . Worse, t he budget ing period when funding could occur was six m ont hs lat er! Danny was behind in sales for t he quart er and had been overeager at t he user conference. He had det ect ed a Woodgrove Bank m anager's int erest in release 4.1. The m anager had indicat ed t hat he want ed som e m ore funct ionalit y. Danny had figured t hat if he could get it , he would t hen have a lever t o get t he m anager t o sign for m ore product s. The $14 m illion dollars was sim ply a proj ect ion based on a hypot hesis t o support Danny's need t o hit sales t arget s. Why not ? To Danny and t he VP of Sales, it cost not hing t o dem and t he funct ionalit y. They never saw t he direct correlat ion bet ween t hese dem ands and t he product qualit y, which got worse release by release. They never correlat ed t hese dem ands wit h t he t urnover and generally poor m orale in t he developm ent ent erprise. They figured t hat t he developm ent ent erprise always had slack. They always had been able t o fit m ore int o a release in t he past . So why not ask for m ore again?

Additional Comments Two m aj or changes occurred from using Scrum , bot h causing ripple effect s far beyond t heir im m ediat e point of im pact . First , cust om ers and prospect s were able t o see release 4.1 early and evaluat e m aj or pieces of it . They responded t o t his change ent husiast ically, t hinking of addit ional uses for t he product wit hin t heir ent erprises. Second, t he sales force saw t he cust om ers and prospect s responding different ly. They saw sales opport unit ies because excit ed cust om ers could m ean addit ional sales. When m ore sales revenues were seen as possible, everyone revert ed t o form and fell back on t he habit s of release 3.51 and before. Managem ent t old t he developers t o do what it t akes t o build m ore funct ionalit y wit hin t he sam e t im e period. Consequent ly, t he qualit y of t he product and st aff suffered. Only when rem inded of t heir " m uscle- m em ory" behavior did t hey rat ionally evaluat e t he realit y of t he opport unit y.

I ncrem ent s of soft ware were produced every m ont h, and t he cust om ers were able t o see t hem at t he user conference. What could be bet t er? But every change has t wo sides, and we t end t o focus on t he good side. The opport unit y provided t o Danny was one of t he unant icipat ed, negat ive consequences. I n our hast e and eagerness t o only see t he good, we som et im es m iss or ignore t he negat ive part s of change.

Part II: Start Using Scrum for Enterprise Work New processes and pract ices are dem anded as your ent erprise rem oves dysfunct ions and problem s ident ified wit h Scrum . When Scrum is used in a single proj ect , t hese changes are isolat ed. When t he ent erprise adopt s Scrum , t hese changes are widespread. Sect ion 2 lays out som e processes, pract ices, and t echniques t hat will help you adopt Scrum at an ent erprise level. None of t hem are new. They are j ust different from t he way work is current ly done. The t ypes of pract ices described are not ed in t he following list of chapt ers in t his sect ion: • • • •

Chapt er 6, " Organizat ional Pract ices," covers pract ices for organizing t he work of t he ent erprise. Chapt er 7, " Engineering Pract ices," addresses int egrat ing ent erprise work regardless of t he t echnologies, archit ect ures, or processes used. Chapt er 8, " People Pract ices," describes what changes are needed for people t o successfully use Scrum in self- m anaging, cross- funct ional t eam s. Chapt er 9, " The Relat ionship Bet ween Product Managem ent / Cust om er and t he Developm ent Team ," looks at t he new relat ionship t hat is form ed bet ween Product Owners and developm ent t eam s. This is t he m ot her of all changes. I f it doesn't succeed, you don't accrue Scrum 's benefit s.

Several caveat s apply t o t hese changes. This sect ion consist s of proven pract ices and processes. You probably will have t o refine t hem for your ent erprise. Let t he people who are going t o do t he work define and refine t he new pract ice or process. I f you define it for t hem , t hey will feel t hat t hey can't cont inually m odify t hem t o m eet new circum st ances. Second, don't plan a perfect process or pract ice. Just com e up wit h one t hat seem s appropriat e. Any short com ings will im m ediat ely be det ect ed by Scrum . You can t hen refine it . Ent erprises oft en t ry t o get it perfect before st art ing. During t his t im e, t hey could have been building product .

Chapter 6. Organizational Practices I n t his chapt er: # 1: Organizing Ent erprise Work

46

# 2: Organizing Ent erprise Work for a High- Technology Product Com pany

46

# 3: Organizing Ent erprise Work in Ot her Ent erprises

51

# 4: Organizing Ent erprise Work for New Syst em s t hat Aut om at e an Ent erprise Operat ion

52

# 5: Organizing t he Com plexit y of Mult iple Views

54

# 6: Organizing Work t o Opt im ize Soft ware Product Fam ily Archit ect ures

55

When your ent erprise uses Scrum , you can m onit or all developm ent every Sprint . You can redirect ent erprise work t o t ake advant age of new opport unit ies and m axim ize ent erprise ret urn on invest m ent ( ROI ) . The ent ire ent erprise can change course quickly. To be able t o do t hese t hings, you m ust have all your ent erprise's work in a single Product Backlog. Creat ing such a backlog can t ake over one year and is very difficult . Once it 's done, however, you'll wonder how you m anaged previously. Wit hout an int egrat ed pict ure of all of t he ent erprise's work, it is im possible t o assess progress and perform im pact analyses. I n t his chapt er, I 'll explain how t o creat e such an ent erprise Product Backlog. An overview is present ed in t he " # 1: Organizing Ent erprise Work" sect ion. The ent erprise Product Backlog st ruct ure is som ewhat different for high- t echnology product ent erprises t han it is for an ent erprise t hat deploys t echnology t o m ake it s operat ions m ore com pet it ive. We'll look at high- t echnology Product Backlogs in t he " # 2: Organizing Ent erprise Work for a High- Technology Product Com pany" sect ion. I n " # 3: Organizing Ent erprise Work in Ot her Ent erprises," we'll look at creat ing a Product Backlog for ot her ent erprises. Anot her Product Backlog variant is organizing work when a new ent erprise operat ion, including syst em s t hat aut om at e it , is being developed. This scenario is discussed in " # 4: Organizing Ent erprise Work for New Syst em s t hat Aut om at e an Ent erprise Operat ion."

A Product Backlog is t he work of t he com pany. Many views of t his work are oft en required. The " # 5: Organizing t he Com plexit y of Mult iple Views" sect ion shows how t o correlat e and m anage m ult iple views. The inform at ion in t his sect ion will help you handle som e com plexit ies of m aint aining m ult iple views. Finally, we'll look at how t o organize work if your ent erprise is using a soft ware product fam ily archit ect ure t o opt im ize reusabilit y in " # 6: Organizing Work t o Opt im ize Soft ware Product Fam ily Archit ect ures."

#1: Organizing Enterprise Work Scrum seem s t o organize work int o Product Backlogs. But how do I organize m y ent ire ent erprise's work int o a Product Backlog and what are t he benefit s of doing so? We can organize all of an ent erprise's developm ent work int o an ent erprise Product Backlog. To creat e an ent erprise Product Backlog, creat e an ent erprise view of all proj ect s and program s. These views are t op- down decom posit ions t hat organize t he Product Backlog by ent erprise product archit ect ure, organizat ion, or program s. I f t he ent erprise sells high- t echnology product s, use a product decom posit ion t hat consist s of t he following inform at ion: product fam ily, product , feat ures, funct ion, and t ask. I f t he ent erprise uses t echnology t o aut om at e it s product s, like a financial inst it ut ion does, use det ails of t he organizat ional st ruct ure. The rest of t his chapt er present s ways of creat ing t hese views and linking t hem t o each proj ect 's Product Backlog. As we correlat e and link t he det ailed Product Backlog of Scrum proj ect s t o t he ent erprise view, t he ent erprise Product Backlog st art s t aking form . We t hen fill in t he ent erprise Product Backlog as m ore proj ect s are st art ed. You m ust event ually ident ify, organize, and priorit ize all current and planned work. To t he degree t hat all t he work of t he ent erprise is in an ent erprise Product Backlog, you can t rack t he progress of every program , release, and proj ect t hrough burn- down chart s. For any area of int erest , a burn- down chart t racks progress t ow ard a release goal across t im e. Wit h burn- down chart s, you can assess t he im pact various proj ect s and program s have on each ot her and on t he ent erprise. You probably will be unpleasant ly surprised. Program s t hat you t hought were well underway m ight be behind. You m ight find t hat split t ing people across m any proj ect s has slowed overall work rat her t han allowing t he ent erprise t o t ake on m ore. You will get a lot of inform at ion, som e confirm ing your hopes and ot hers dashing t hem .

You will, however, have solid inform at ion wit h which t o m anage t he ent erprise.

#2: Organizing Enterprise Work for a High-Technology Product Company My ent erprise builds product s t hat we sell t o ext ernal cust om ers. Scrum organizes work int o Product Backlogs. How do I organize m y ent erprise's work? I n part icular, if I have an opport unit y t o do som et hing new, how do I quickly reorganize t o do so? A Product Backlog can represent all known developm ent work for an ent erprise's product s. The product s decom pose int o feat ures, funct ions, act ivit ies, and t asks, reflect ing t he product st ruct ure and t erm inology. A Product Backlog defines t he changes t hat are needed at t his lowest level. This decom posit ion can be aggregat ed int o product fam ilies and all of t he ent erprises' developm ent work, as shown in Figure 6- 1.

Figur e 6 - 1 . En t e r pr ise Pr odu ct Ba ck log Pr odu ct Fa m ily Personal Finances Corporat e Taxes Personal Taxes

Pr odu ct

Fe a t u r e

Fu n ct ion Act ivit y

Ba ck log

ID

...... ...... WhirlWind Personal About Deluxe I nform at ion You Filing St at us Personal I nform at ion Locat ion User m ust be able t o t ype in different form at Mailing t elephone Address/ Phone num bers C413 St at e of Residence

A product or syst em archit ect ure consist s of m odules or com ponent s at t he lowest level of decom posit ion. One or m ore of t hese com ponent s will be changed t o sat isfy a Product Backlog it em . We can organize a

separat e Product Backlog for product funct ionalit y com m on t o m ore t han one product . This Product Backlog's st ruct ure reflect s t he syst em 's archit ect ure, as shown in Figure 6- 2. Overall priorit izat ion for t he good of t he ent erprise is m andat ory. The Product Owner of t he com m on funct ionalit y has t o be som eone wit h ret urn on invest m ent ( ROI ) responsibilit y for all ent erprise product s.

Figur e 6 - 2 . Com m on infr a st r uct u r e Pr oduct Ba ck log of r e qu ir e m e n t s Aspe ct

Act ivit y

Ta sk

Screen Form at t ed User Num eric I nt erface Cont rols Ent ry Business Logic Dat a Base Cont rols Dat a Base

M odu le

ID

Dom est ic Telephone Num ber

C413

SPF SPF CI CI Pr t y Size Pr t y Size

72

2

61

Let 's look at how we could respond t o a cust om er requiring enhanced funct ionalit y in t he Corporat e Taxes product fam ily. We est im at ed t he effort t o m ake t he enhancem ent at 100 point s of work. ( A point of work is an arbit rary m easure.) The cust om er needs it wit hin six m ont hs. We are in t he fift h m ont h of our ent erprise's annual plan. An ent erprise burn- down chart shows t he annual baseline plan, as shown in Figure 6- 3.

Figur e 6 - 3 . Bu r n - dow n of ba se lin e r oa dm a p pla n

1

We assess progress against t he plan. The plan is m aint ained in an ent erprise Product Backlog. The m easurem ent is against t he m ost current plan, which is usually different from t he baseline plan. I n t he fift h m ont h, we can com pare t he current ly planned funct ionalit y against t hat which has already been delivered, as shown in Figure 6- 4.

Figur e 6 - 4 . Bu r n - dow n of e nt e r pr ise a ct u a l vs. pla n

The difference bet ween t he t wo plans represent s t he degree t o which t he ent erprise is ahead of or behind plan. Figure 6- 4 shows t hat we are behind our plan and behind on our com m it m ent s. At t he end of t he fift h m ont h, t he plan com m it t ed us t o have 1214 point s of work left . I nst ead, t here are 1320 point s of work left t o be com plet ed. I f we add t he new 100 point s of work request ed in t he Corporat e Taxes product line, t he planned versus act ual m easurem ent becom es worse, as shown in Figure 6- 5.

Figur e 6 - 5 . Bu r n - dow n of a ct u a l vs. pla n w it h n e w w or k a dde d

The planned work is t he bot t om t rend line. The act ual work left wit hout t he addit ional work t aken int o account is t he m iddle t rend line. The t op t rend line shows act ual work rem aining if t he new work is com m it t ed t o. All of t hese t rend lines have been proj ect ed t o year end t o show t he probable gap bet ween planned and act ual work. To t ake on t he addit ional Corporat e Taxes enhancem ent s, we need t o decom m it t o ot her work. We could increase cost s t hrough addit ional new hires, but product ivit y drops as new people are brought on board and increases only aft er six or so m ont hs. We need t o find som e ot her work t hat we can defer. First , let 's add t he new work t o t he Corporat e Taxes part of t he Product Backlog. I t is t he fift h row of Figure 6- 6. We t hen est im at e and priorit ize it com pared t o all ot her work in t he

ent erprise's Product Backlog. For Scrum est im at ion t echniques, see Mike Cohn's recent book, Agile Est im at ing and Planning ( Prent ice Hall, 2004) . The priorit ized ent erprise Product Backlog ( sum m arized) looks like Figure 6- 6.

Figur e 6 - 6 . En t e r pr ise Pr odu ct Ba ck log w it h n e w w or k En t e r Pr odu ct pr ise Fa m ily Personal Taxes Personal Taxes Personal Taxes Corporat e Taxes Personal Taxes Personal Taxes

Personal Taxes Corporat e Taxes

Pr odu ct Fe a t u r e Personal WhirlWin I nform at d Deluxe ion Personal WhirlWin I nform at d Deluxe ion Personal WhirlWin I nform at d Deluxe ion

Personal WhirlWin I nform at d Deluxe ion Personal WhirlWin I nform at d Deluxe ion

Fu n ct io Act ivit y n St at e of About Residenc You e Mailing Address/ About Phone You Mailing Address/ About Phone You

About You About You

Personal WhirlWin I nform at About d Deluxe ion You

Personal Personal WhirlWin I nform at Taxes d Deluxe ion Personal Finances Personal Personal WhirlWin I nform at Taxes d Deluxe ion

About You

About You

Ba ck log

I D om a Pr t Siz D in y e

I t em 5

90

33

I t em 3

82

47

I t em 4

73

33

New work

72 100

St at e of Residenc e I t em 7 Mailing Address/ Phone I t em 2 User m ust be able t o t ype in different Mailing form at Address/ t elephone num bers Phone Com m it t ed work St at e of Residenc e I t em 8 Com m it t ed work St at e of Residenc e I t em 6

C 4 1 Com m 3 on

65

29

63

52

62

20

42 432

21

82 104 12 8

11

We need t o accom m odat e 206 new point s of w ork ( 100 new point s of work added t o t he current short fall of 106 point s) . We can decom m it

58

lower priorit y work. The first it em t o put on hold is t he lowest priorit y in t he bot t om row: Personal Taxes, St at e of Residence, I t em 6. The rem aining 148 point s of work t o be deferred ( 206 needed less t he 58 point s of I t em 6) has t o com e from t he Personal Finances product , t he next lowest priorit y. I t s ent ire workload has 1048 point s of work planned for t he year. When we drill down and look at t he burn- down for t he Personal Finances product line, it is ahead of plan. We t hen drill down int o it s work t o see where we can free up som e effort while m inim izing t he im pact . I n Figure 6- 7, we drill down t o look at j ust t he work for Personal Finances.

Figur e 6 - 7 . Pe r son a l Fina n ce s a ct ua l vs. pla n

The Personal Finances work is ahead of schedule. At t he end of t he fift h m ont h, we had planned t o have 217 point s of work left , but only 160 rem ain. We are 57 point s ahead of plan. We m ight be able t o use t his capacit y for t he new work in t he Corporat e Taxes product line. Drilling down in t he Personal Finances work, we can see which specific areas are ahead of plan. Then we can assess whet her t he people doing t hat work are skilled and capable of helping t he Corporat e Taxes product . I f t hey are, we m ight be able t o redeploy t hem . We will ask t he Product Owner of t he Personal Finances product line whet her he or she can form a new t eam t hat can be reassigned for four m ont hs.

This exercise t ook care of t he new work and enabled us t o get t he new cust om er's business. We assessed t he ent erprise's ongoing work t o ident ify excess capacit y. We could do t he sam e t hing every m ont h t o det ect short falls and slippages. As priorit ies change and new opport unit ies occur, we can realign our work t o m axim ize ent erprise ROI . The Product Owners at every level of t he ent erprise are able t o t rack t heir work against t heir com m it m ent s. We can shift t he ent erprise t o t ake advant age of new opport unit ies while assessing and t hen t racking t he im pact .

#3: Organizing Enterprise Work in Other Enterprises My com pany uses our I nform at ion Technology organizat ion t o develop soft ware for m y line operat ions. This soft ware m akes t he operat ions m ore effect ive. How does t he m anagem ent of t hese operat ions use Scrum , or do I leave t his t o t he I nform at ion Technology depart m ent ? Product Owners are t he m anagers of t heir operat ions. They define work t o enhance t heir product s in t he Product Backlog. The developm ent work can be t o enhance aut om at ed syst em s or m anual operat ions. Training and im plem ent at ion work is also part of t he Product Backlog. The Product Backlog is sort ed by Syst em and Priorit y t o organize work wit hin t he I nform at ion Technology ( I T) organizat ion. I T t eam s are form ed based on Product and Syst em ident ifiers. We can use t he following exam ple of a banking ent erprise t o see how t o do t his. A bank sells financial product s t o it s cust om ers. I t is organized int o lines of business ( LOB) . Each line of business consist s of operat ions t hat sell and service financial product s. These operat ions are aut om at ed t hrough int ernal syst em s. For inst ance, a bank can have a Trust LOB, a Com m ercial Banking LOB, and a Consum er Banking LOB. Wit hin t he Consum er Banking LOB is a Teller operat ion, a Loan Creat ion operat ion, and so on. These are serviced by a Product Developm ent and Managem ent depart m ent t hat devises t he various financial product s. Each operat ion is support ed by one or m ore com put er syst em s. As new product s are conceived, t he operat ions and syst em s support ing t hem m ust be developed or enhanced. The Product Backlog, or requirem ent s, t o do so are organized by LOB, operat ion, act ivit y, and t ask. Figure 6- 8 represent s such a decom posit ion.

Figur e 6 - 8 . Fin a n cia l e nt e r pr ise Pr oduct Ba ck log Ent e Line of Ope r r pr is Busine a t io Pr oduc Act ivit y t e ss n Bank

Trust

Com Syst e pone Re quir e m Pr t Siz m e nt y e nt

......

Corporat e Banking ...... Consum er Banking Teller Mort gage

Savings

Deposit s

Teller31 C524

C325

Cust om er can m ake a deposit across account s Cust om er can perform deposit t hem selves using new aut om at ed t eller t erm inal

33

13

42

21

Wit hdrawals Checking Plat for m I RA

Filing St at us Personal I nform at ion 401K Mort gage Locat ion Personal Loan Savings Checking

#4: Organizing Enterprise Work for New Systems that Automate an Enterprise Operation We are building a new syst em for a division in our ent erprise. I t will replace a pat chwork, older syst em . How can t he work be direct ed by t he Chief Operat ions Officer of t hat division so t hat it m akes sense t o

her, while being organized and priorit ized in a way t hat m akes sense from a syst em s archit ect ure viewpoint ? Dat a is t he business of som e ent erprises, such as credit report ing, encyclopedias, news, and m apping. These ent erprises acquire, form at , and sell dat a. Ent erprises som et im es need t o build ent irely new syst em s for t hese t ype of operat ions. The m anagers of t hese operat ions need t o correlat e and priorit ize developing a new business operat ion wit h building new syst em s t o aut om at e it . The business operat ion is organized int o several prim ary funct ions. The dat a is acquired. The dat a is cont inually groom ed t o provide addit ional value t hrough new relat ionships and at t ribut es. The dat a is m anaged for accuracy and qualit y. The dat a is ext ract ed for sale t o cust om ers. Som e ext ract s are periodic, while ot hers are cont inuous. At t he lowest level of t he business operat ion, act ivit ies and t asks are perform ed. These t asks are m anual, m anual wit h aut om at ed assist , or com plet ely aut om at ed. The aut om at ed syst em is organized as an archit ect ure t hat has nonfunct ional at t ribut es such as perform ance, scalabilit y, securit y, and workflow. The person who runs t his operat ion is t he Product Owner. He or she is responsible for overall profit abilit y and t he long- t erm invest m ent in t he new syst em . He or she is responsible for priorit izing t he developm ent t o support a phased, secure im plem ent at ion as well as for m eet ing t echnical dependencies. As an exam ple of t echnical dependencies, t he workflow fram ework m ight be essent ial t o have in place prior t o im plem ent ing acquisit ion and edit ing funct ionalit y. The int ersect ion of operat ional and syst em s decom posit ion is shown in Figure 6- 9. The Product Backlog work occurs at t he int ersect ion.

Figur e 6 - 9 . I n t e r se ct ion of ope r a t ion a l a n d syst e m vie w s in a Pr oduct Ba ck log

[ View Full Widt h] The Product Backlog it em " Display areas t o be select ed" is part of t he operat ion's Dat a Managem ent funct ion. I t is used by t he supervisor of t he Referent ial I nt egrit y sect ion t o frequent ly inspect and check dat a referent ial int egrit y. The new syst em has a com ponent , CSet up04 ( which is part of Subsyst em TDX01- 05 and Syst em TDX01) , t o aut om at e t his. The operat ional viewpoint also uses Product Backlog it em s t o describe work t o enhance a work act ivit y, including creat ing docum ent at ion and ret raining. I t includes colum ns t hat reflect operat ional im plem ent at ion priorit ies and effort s. The syst em s view includes a colum n for t he effort t o build t he com ponent and t he priorit y in which it will be developed. The syst em s view also includes Product Backlog it em s for syst em s t hat provide infrast ruct ure used by t he ot her syst em s, such as workflow. Ot her work, such as const ruct ing dist ribut ed developm ent environm ent s and upgrading t he product ion environm ent , have t heir own Product Backlog it em s. This Product Backlog is priorit ized according t o t he m ost logical sequence for developing t he syst em .

#5: Organizing the Complexity of Multiple Views I 've seen how t o creat e several views of an ent erprise Product Backlog. But t here are som e com plexit ies you haven't discussed. Can you describe how t o handle t hem ? Product Backlog is a priorit ized list of work. We can relat e it t o t hree areas: it s occurrence in a product or syst em , it s occurrence in im proving a business operat ion, and it s occurrence in syst em s archit ect ure. We can t hen creat e com plex views by int ersect ing t hese relat ionships. Figure 6- 9, seen in t he previous sect ion, shows an exam ple of several views of a Product Backlog. I t shows t he relat ionship of a business operat ional view ( Divisions, Depart m ent s, Sect ions, Subsect ion, Act ivit ies, and Tasks colum ns) t o t he work in a Product Backlog ( Product Backlog colum n) , which is t hen relat ed t o t he syst em s archit ect ure view ( Syst em , Subsyst em , Module, and Com ponent colum ns) . Product Backlog it em s range from sm all t o big. Sm all it em s usually relat e t o fine- grained business operat ions, syst em archit ect ural com ponent s, or product t asks, as shown in Figure 6- 9 earlier. As t he it em s increase in size, t he corresponding it em s t hey relat e t o increase in size. For inst ance, a Product Backlog it em referred t o as " Aut om at ically flow applicat ions from invest igat ion t o accept ance and not ificat ion" relat es t o subsyst em s, business act ivit ies, and product t hem es. I t is large and high level. Modules or com ponent s are oft en used by m ore t han one operat ional t ask or product act ivit y. The Product Backlog it em t o change a com ponent t hen has t o be ent ered one t im e for each t im e it aut om at es t he t ask or act ivit y. However, it is est im at ed for only one of t he occurrences. All occurrences inherit t he highest priorit y need and are scheduled accordingly. Som et im es m ult iple occurrences of a Product Backlog it em are indicat ed in one colum n in t he spreadsheet .

#6: Organizing Work to Optimize Software Product Family Architectures Som e ent erprises develop product s and fam ilies of product s. Som e of t he funct ionalit y is product specific, but ot her part s are shared am ong all product s. How is t his work organized wit h Scrum ? Many ent erprises have m ore t han one product . They oft en separat e com m on funct ionalit y int o a com ponent infrast ruct ure library t o

sim plify defining new product s or enhancing an exist ing product . When product s are developed, som e com ponent s are unique t o t he product , but ot her com ponent s m ight already be in t he infrast ruct ure, reducing overall developm ent t im e and cost s. I f som e pot ent ially com m on funct ionalit y isn't already in t he infrast ruct ure, it is developed t here t o reduce t he cost s for fut ure product s. By keeping t he infrast ruct ure in good shape and well cat aloged, new product developm ent is sim plified. The role of t he Product Backlog needs t o be ext ended t o address t his com m on infrast ruct ure. The Product Backlog usually j ust list s requirem ent s of w ork t o be done for a product . Now t he Product Backlog w ill reflect t he st ruct ure of t he ent ire product fam ily. The product fam ily decom poses int o product s, feat ures, funct ions, and act ivit ies, as shown in Figure 6- 10. When som et hing new is needed, t he requirem ent is added. Som e Product Backlog requirem ent s will be sat isfied by com ponent s or dat abases in t he com m on infrast ruct ure. Figure 6- 10 dem onst rat es t his by using t he " Com m on" designat or in t he Dom ain colum n. I f t his is an exist ing com ponent t hat needs enhancing, t he I D for t he exist ing com ponent is recorded. When t he Product Backlog is sort ed by requirem ent priorit y and requirem ent , it st art s wit h a priorit ized list of work t o be done.

Figur e 6 - 1 0 . Soft w a r e pr odu ct fa m ily Pr odu ct Ba ck log of r e qu ir e m e n t s Pr odu ct

Fe a t u r e Fu n ct ion Personal WhirlWin I nform at io d Special n About You

Act ivit y

Ba ck log I D

Pr t D om a in y

Siz e

Filing St at us Personal I nform at ion Locat ion User m ust be able t o t ype in different form at Mailing t elephon Address/ Phon e C41 Com m o e n num bers 3 St at e of Residence

72

2

Figur e 6 - 1 0 . Soft w a r e pr odu ct fa m ily Pr odu ct Ba ck log of r e qu ir e m e n t s Pr odu ct

Fe a t u r e

Fu n ct ion

Act ivit y Mult iple Residence Ot her St at e I ncom e Occupat ion

Phone List ing Opt ion Creat e User ID Hurricane Kat rina Special Sit uat ions

Ba ck log I D

Pr t D om a in y

User m ust be able t o t ype in different form at t elephon e C41 Com m o num bers 3 n

72

Siz e

2

Dependent s Dependent s I m port I nform at io I m port from n Last Year Dependent s I m port Your I nform at io n Federal Taxes

I ncom e

Wages and Salary

The com m on infrast ruct ure support s all product s. I t has it s own Product Backlog. This is organized by aspect . This backlog is populat ed wit h m aint enance work and all work request ed for each Product Fam ily and Product , as shown in Figure 6- 11.

Figur e 6 - 1 1 . Com m on in fr a st r uct ur e Pr odu ct Ba ck log of r e qu ir e m e n t s Aspe ct

Act ivit y Ta sk

M odu le Dom est ic Telephone Screen User Form at t ed Cont rols Num eric Ent ry Num ber I nt erface Business Logic Dat a Base Cont rols Dat a Base

ID

C413

SPF Pr t y

72

SPF Size

CI CI Pr t y Size

2

61

1

The Product Owner for all product fam ilies priorit izes t he infrast ruct ure Product Backlog. Only t his person can evaluat e all product fam ily priorit ies against each ot her and against t he need t o m aint ain and sust ain t he com m on infrast ruct ure. This priorit y is m aint ained in t he Com m on I nfrast ruct ure ( CI ) Prt y colum n. The relat ive size of t he w ork, as evaluat ed by t he infrast ruct ure t eam s, is m aint ained in t he CI Size colum n. This work m ight be different in size t han t hat est im at ed by t he Product Team . Not e t hat t he duplicat e Product Backlog requirem ent s from Figure 6- 11 have been m erged int o one.

Chapter 7. Engineering Practices I n t his chapt er: # 1: Mult ilayer Syst em Work Organized by Funct ionalit y

60

# 2: I nt egrat ion of Mult iple- Layer Syst em s

63

# 3: I nt egrat ing t he Work of Scrum Team s and Team s Not Using Scrum

66

Sum m ary

68

Developm ent work happens in individual Scrum t eam s. These t eam s are oft en part of a larger proj ect . Only when t heir work is int egrat ed wit h t hat of ot her t eam s is it of use t o t he ent erprise. To t rack t he im pact of individual t eam s on a proj ect , you m ust int egrat e work frequent ly. Pract ices for doing so are present ed in t his chapt er. Scrum requires t hat all work be int egrat ed at least once per Sprint . To accom plish t his, t eam s usually m ust int egrat e t heir work wit h ot her t eam s at least daily, and preferably cont inuously. Frequent ly, int egrat ing each t eam 's work is difficult and your engineering organizat ion probably can't do it , yet . To int egrat e each t eam 's work, you have t o change t he way developm ent is organized. You have t o change t he t echnology t hat you use t o t est and build product s. Your organizat ion's overall engineering skills have t o im prove. When t hese requirem ent s were discussed in one ent erprise I had worked wit h, t he group m anager t old his m anagem ent t eam t hat he want ed t his done wit hin t wo m ont hs. This dem and led t o a lively conversat ion about how hard t his change was going t o be. Som e of t hese changes are local t o t he developer and his or her Scrum t eam . However, m ost ent erprises need significant , sust ained im provem ent s t hroughout . Product s are com plicat ed, despit e t he best archit ect ures. You have t o be t ough- m inded t o build increm ent s of t hese product s frequent ly. You have t o be m erciless t o know where t he developm ent st ands every day. Engineering organizat ions frequent ly t ell m e what t hey can't do wit hin Scrum : " We can't regression t est everyt hing wit hin t he Sprint window! ! " and so fort h. That is t he wrong answer. The right answer is, " We can't do t hat now. We'll figure out how t o do it ."

Let 's look at solut ions t o t he engineering problem of frequent ly int egrat ing work. I 'll use exam ples from m y experiences in t he field, again subst it ut ing fict it ious com pany nam es for t he real ones.

#1: Multilayer System Work Organized by Functionality How do w e organize t o develop an enhancem ent t hat includes new front - end funct ionalit y and enhanced back- end infrast ruct ure funct ionalit y? A com pany called Wingt ip develops and m arket s I nt ernet infrast ruct ure soft w are. Wingt ip adopt ed Scrum in m id- 2005. Wit hin six m ont hs, all of it s developm ent proj ect s used Scrum . Team s were organized t o own specific funct ionalit y. Every t eam was inst ruct ed t o select work for a Sprint only if it could com plet ely t est it , design it properly, and com plet e t he user docum ent at ion. This was Wingt ip's definit ion of a " done" increm ent , which was deployed m ont hly. As part of a new release of Wingt ip's advert ising product , cust om er report ing funct ionalit y was going t o be enhanced by t he advert ising developm ent t eam . The t eam select ed a Product Backlog it em t o allow a cust om er t o display all ad t ypes over a variable t im e period on one screen. Cust om ers current ly had t o scroll am ong m ult iple screens and m anually t ally t he count s. The work consist ed of changes t o t he user screens, business logic, and dat abase. The ad server had m ost of t he business logic and all t he dat abases. I t was part of Wingt ip's infrast ruct ure t hat support ed all Wingt ip's product s. Exist ing ad server capabilit y ret rieved usage by hour and day for each usage t ype. To support enhanced report ing, t he infrast ruct ure had t o be enhanced t o m aint ain m ore t im e fram es of usage. I t also had t o be able t o aggregat e count s for m ult iple ad t ypes, which required addit ional dat abase fields. Once t he infrast ruct ure was so enhanced, t he front end could m ake a single request across t he I nt ernet wit h t he variable for t hat account , t im e period, and ad t ypes. The infrast ruct ure t eam was a separat e t eam t hat m aint ained and enhanced only t he infrast ruct ure. There were only eight people who could do t his in all of Wingt ip, and t hey were on t his t eam . This const rained ot her t eam s because nobody else was allowed t o work on t he infrast ruct ure. The advert ising developm ent t eam t old t he Scrum Mast er t hat it needed people from t he infrast ruct ure t eam . Unfort unat ely, t he people t hey needed were booked for m ont hs. The

t eam had t o proceed wit hout t hem wit h a localized solut ion t hat didn't require any infrast ruct ure changes, as shown in Figure 7- 1.

Figur e 7 - 1 . Loca lize d solu t ion

At t he Sprint Review, t he advert ising t eam dem onst rat ed t he screen. The funct ionalit y was very slow. Because t he infrast ruct ure couldn't be changed yet , m ult iple request s were m ade t o t he infrast ruct ure ad server for dat a, which t he front end t hen accum ulat ed. The advert ising t eam m im icked t he ad server in t he front end. The advert ising t eam had developed t he following localized solut ion: Code View: Scroll / Show All Set up variables with account number and time period. Set up a variable with all known ad types. Pull the first ad type from a string of all ad types. Request the count for that ad type, account, and day. Aggregate the count in a counter. Continue making requests across the Internet until the string with ad types is depleted. Continue making requests across the Internet to the ad server until the time period is fulfilled.

Alt hough t his funct ionalit y worked, t he t eam had devised a local solut ion t hat was far t oo slow t o ship. The Product Owner asked t he Scrum Mast er t o figure out how t o get t he needed help from t he infrast ruct ure t eam . The Scrum Mast er devised t he following ent erprise solut ion. Team s could only build an increm ent t hat encom passed all necessary layers, including t he infrast ruct ure. I f infrast ruct ure support wasn't available, t he t eam had t o do ot her Product Backlog it em s first .

Anot her field was added t o each t eam 's Product Backlog t o indicat e dependencies on t he infrast ruct ure layer. I n t he following exam ple, t he use of " I nfrast ruct " in t he Dom ain colum n indicat es t his dependency: D om a in Pr t y

Fe a t ur e Funct ion Act ivit y

Ba ck log

ID

Adm inist er Mont hly Billing

Allow a cust om er t o display all ad t ypes over a variable t im e period for his or her account on one screen

C213 I nfrast ruct 22

Display ad count s

The work t he infrast ruct ure t eam had t o do was added t o t he infrast ruct ure Product Backlog, as shown in t he next t able. Ot her work was priorit ized t o be done before t he ad server t eam 's work. Aspe ct

Act ivit y M odule

Advert ising Report ing

Ad aggregat ion

Ba ck log

Sour ce Pr t y Size ID

Allow a cust om er t o display all ad t ypes over a variable t im e period for his or her account on one screen

C213

42

8

A funct ional t eam and t he infrast ruct ure t eam would t ry t o synchronize t heir work t o t he sam e Sprint , when t hey could work t oget her, as shown in Figure 7- 2. I f t he infrast ruct ure t eam got t he work done in an earlier Sprint , t he funct ional t eam could m ake com m it m ent s t o t he overall funct ionalit y. Ot herwise, t he funct ional t eam had t o defer it s dependent work. I t had t o wait unt il t he ot her t eam was available.

Figur e 7 - 2 . En t e r pr ise solu t ion —Te a m s bu ild fun ct ion a lit y a cr oss a ll r e qu ir e d la ye r s

Prior t o t he t eam select ing t he " Display ad count s" Product Backlog it em , t he advert ising t eam t alked t o t he Product Owner for t he infrast ruct ure t eam . The people it needed were unavailable for t he next t wo Sprint s. The advert ising t eam had t o select lower priorit y Product Backlog for t hese Sprint s. When t he infrast ruct ure people were available in t he t hird Sprint , all layers—including infrast ruct ure—were m odified t o provide a com plet ely usable piece of funct ionalit y. When t he t eam com plet ed t he aggregat ion funct ionalit y, it s localized code looked like t he following: Set up variable with account number, time period, and "all types" indicator Request count from ad server

This solut ion required only t wo t ransm issions across t he I nt ernet , and it had adequat e perform ance. One t ransm ission m ade t he request , and t he ot her received t he result s. All t he logic for det erm ining what dat a was required, ret rieving t he dat a, and t hen aggregat ing it was placed at t he ad server. A Scrum t echnique for handling ext ernal dependencies arose from t his sit uat ion. Whenever a t eam cannot do an increm ent because t hey have an ext ernal dependency, t hey cannot com m it unless—and only unless—t he ot her people or t eam s are also at t he Sprint Planning Meet ing. These ext ernal t eam s or people have t o com m it also. Ot herwise, t he ext ernal part ies m ight be int erest ed part ies, but t hey cert ainly are not com m it t ed part ies. When an infrast ruct ure t eam provides funct ionalit y for m ult iple product s, who priorit izes it s work? Each product 's Product Owner will, of course, lobby for t he urgency of his or her work. One solut ion is t o int egrat e all t he Product Backlogs int o an ent erprise Product Backlog. The burn- down and progress for each individual product can be t racked. The burn- down and progress for a fam ily of product s t hat is dependent on shared funct ionalit y can also be t racked. A Product Owner who is responsible for overall profit abilit y priorit izes t he infrast ruct ure Product Backlog t o m axim ize ent erprise profit s and reduce risks.

#2: Integration of Multiple-Layer Systems How does an ent erprise organize it s work when it is developing an overall product wit h m any funct ions and feat ures but t he work is divided according t o t he various archit ect ural layers of t he product ? Many product s are archit ect ed int o layers. Even a sim ple Web applicat ion has int erface, logic, and persist ence layers. I n our exam ple, Wingt ip t ied t heir layers t oget her wit h t eam s t hat developed funct ionalit y across all layers. Som et im es t his doesn't work and ot her approaches are devised. When devising t hese, keep in m ind t hat any approach has t o m eet at least t wo crit eria. First , we have t o know where we are in a proj ect at any t im e. Second, we have t o be able t o release a com plet ed increm ent as oft en as possible. Fabrikam produces an I nt ernet - enabled alt ernat ive t o cable and sat ellit e TV. Fabrikam m arket s it s product s t o t elephone com panies wit h large- scale DSL offerings. Fabrikam delivers it s funct ionalit y t hrough five layers. The first layer collect s and st ores all ent ert ainm ent m at erial. A second layer m aint ains cust om ers and account inform at ion. These layers are locat ed in com m on Fabrikam server facilit ies. The t hird layer packs, t ransm it s, and unpacks ent ert ainm ent from t he I nt ernet . The next layers are on t he TV- t op cont rol box. The fourt h layer m anages program m ing and st orage of ent ert ainm ent . The fift h layer is for select ing and playing program s. Each of t he layers was developed by separat e organizat ions at different geographic locat ions: one layer in I srael, anot her in t he UK, t wo layers at different locat ions in t he Unit ed St at es, and one layer in China. Each layer had it s own Product Owner and Scrum t eam s. The product and it s layers are shown in Figure 7- 3.

Figur e 7 - 3 . Fa br ik a m pr odu ct la ye r s

The fift h- layer t eam present ed it s progress at it s Sprint Review in California. The t eam showed excellent progress in developing funct ionalit y on it s layer. Not only was t he funct ionalit y powerful, but it s arrangem ent was elegant and int uit ive. The ot her layer t eam s also present ed t heir layers at t heir respect ive locat ions. They w ere all progressing according t o t he schedule. The Fabrikam Vice President was pleased wit h t he progress. Aft er t he Sprint Reviews, t he Scrum Mast ers for all t he layers had a conference call wit h m e. They asked if, wit hin t he rules of Scrum , t hey could discont inue t he Scrum of Scrum s. They felt t hat t he m eet ings weren't fruit ful. They felt t hat very lit t le inform at ion was shared t hat everyone was int erest ed in. The geographical dispersion and t im e differences m ade t hese m eet ings even less wort hwhile. Scrum of Scrum s are short , daily Scrum m eet ings at which an engineer from each t eam working on an int egrat ed product gat her t o share t he st at us of t heir t eam s. This m eet ing helps t eam s keep t rack of progress bet ween part s of t he product so t hat t hey can m ore closely m onit or any dependency or t im ing problem s. I wondered why t his wasn't im port ant t o t he t eam s building t he various part s of t he Fabrikam product s. Didn't t hey need t o know each ot her's progress? When queried, t he Scrum Mast er for t he fift h layer said t hat t he progress of ot her layers wasn't im port ant t o his t eam . His t eam 's Product Backlog and Sprint Reviews were only for his layer. I asked how his t eam s knew if it s increm ent int egrat ed wit h t he ot her layers. He replied t hat t hey had very det ailed specificat ions t hat t hey were developing t o.

The int erface design for each layer had changed since t he proj ect began. Unfort unat ely, t eam s at each layer were st ill building t o t he original and now out - of- dat e int erface specificat ion. Each layer was progressing, but nobody knew whet her t heir increm ent s int egrat ed t o form a com plet e product . Such a check would have exposed any int egrat ion discrepancies and allowed for correct ive work. The part icipant s in t he daily Scrum of Scrum s should have been t racking any changes from t he original specificat ion. The Product Backlog is oft en decom posed by layers: archit ect ural, funct ional, and geographical—or a m ix of all of t hese. There has t o be an overall Product Owner. He or she can delegat e decom posed Product Backlog m anagem ent t o ot her Product Owners. I n large proj ect s, t here m ight be four or five layers of Product Backlog decom posit ion. Each has a Product Owner report ing t o t he overall Product Owner. At any t im e, t he com bined Product Backlog dynam ically describes t he progress in developing a com plet e product . The Fabrikam Product Backlog was com bined int o one Product Backlog, st ruct ured int o t he five layers. The Vice President becam e t he overall Product Owner. By t racking t he com bined burn- down and t rend lines, he could m anage overall product developm ent . However, as t hings current ly st ood, t he various layers were unlikely t o work t oget her. The Vice President asked for a solut ion so t hat he could view an int egrat ed, pot ent ially shippable product as frequent ly as possible. The t eam s at each layer built t heir own layer at least daily t o see whet her it st ill fit and worked t oget her wit h ot her layers. The t op engineers of t he various levels m et and reasoned t hat an int egrat ion of builds from all t he layers could solve t he problem . Overall product int egrat ion could t hen be checked and t est ed. This int egrat ion of effort s is shown in Figure 7- 4.

Figur e 7 - 4 . Fr e qu e nt int e gr a t ion of la ye r s

They t ook t he following st eps: •

•

•

•

•

They agreed t o have a sixt h level, an int egrat ion layer. The int egrat ion layer t eam was m ade up of people from each of t he five ot her layers. The int egrat ion t eam im plem ent ed int egrat ion hardware and soft ware. I t pulled t he builds from each layer daily and t ried t o int egrat e t hem int o a single build. The int egrat ion t eam developed t est s t hat ran t hrough all layers and t est ed t he int egrat ed funct ionalit y. The t est s exercised t he layers as t hey would be operat ed when an end user t ried t o operat e t he TV. I nt egrat ion failures were report ed t o t he t eam working on t he layer t hat had caused t he failure. This t eam had t o resolve t he problem before m oving forward wit h any m ore developm ent . A rule was inst it ut ed t hat all five layers had t o work as an int egrat ed product at t he end of each Sprint . I f t hey didn't , none of t he layers was done or could be dem onst rat ed.

The work was added t o t he overall Product Backlog. I t t ook t wo Sprint s before an int egrat ed product could be dem onst rat ed. I ncom pat ibilit ies

and divergences from product specificat ions were exposed and had t o be fixed. Scrum 's inspect and adapt t echniques require a full, int egrat ed increm ent . I f t he increm ent being inspect ed isn't com plet e, t he adapt at ions m ight well be wrong. At Fabrikam , Scrum point ed out nobody was t racking t he overall product developm ent . The int egrat ion deficiencies wouldn't have been apparent ot herwise unt il near t he end of t he proj ect . When product s consist of m ore t han five layers, int egrat ion is m ore difficult and t akes longer. I f t he product consist ed of feat ures whose developm ent cycles varied, t he int egrat ion also m ight have been harder. For inst ance, hardware's build cycle is usually several m ont hs. I f t he hardware for Fabrikam 's TV- t op cont rol unit was part of t he developm ent , anot her int egrat ion t echnique would have been needed. The Wingt ip exam ple m ent ioned earlier provides insight s int o how t o organize work in an ent erprise for feat ure- driven developm ent . Fabrikam provides insight s int o how t o organize work wit hin an ent erprise for archit ect ural- layer- driven developm ent . These are only t wo of t he m any possibilit ies.

#3: Integrating the Work of Scrum Teams and Teams Not Using Scrum A product is being developed by m any t eam s. Som e t eam s use Scrum . Ot her t eam s use a wat erfall process. Ot her t eam s are developing hardware and use a propriet ary process. How can all t hese t eam s be m anaged, and how can t he Scrum t eam s fit t heir work in? Trey Research develops audio product s. A proj ect was st art ed t o build a new radio. A Product Requirem ent s Docum ent ( PRD) and plan were developed. Of t he m any t eam s form ed, one hardware t eam and one em bedded soft ware t eam were responsible for building t he handheld rem ot e cont roller ( rem ot e) . The hardware requirem ent s were specified. The hardware would be a per- unit cost for every unit shipped. The cost of t he soft ware was a one- t im e cost . Accordingly, t he hardware capabilit y was m inim ized t o save m oney. Com m odit y hardware was select ed. The hardware t eam was using it s own m ilest one- driven process as it worked from t he PRD. The m ilest ones were a design docum ent , a hardware breadbox, a prot ot ype, and t hen t he finished product . The

breadbox was a large- scale, crude im it at ion of t he rem ot e cont roller. The breadbox cont ained but t ons and cont rols t hat would generat e t he t ypes of int errupt s t hat t he rem ot e could expect and should handle. I t provided a t est environm ent for t he em bedded soft ware and could be used t o verify every Sprint 's increm ent of funct ionalit y. However, t he breadbox delivery m ilest one was t hree m ont hs int o t he proj ect . The soft w are t eam used Scrum . The Product Owner and t he t eam ext ract ed t he Product Backlog from t he PRD t hat addressed soft ware funct ionalit y. During t he first t hree m ont hs, t he soft ware t eam com plet ed t hree Sprint s. I t built a sim ulat ion layer t o t he specificat ions of t he rem ot e on a PC. Once t he breadbox was delivered, developm ent done on t he PC would be t est ed on t he breadbox. I n t he fift h m ont h of developm ent , a com pet it or int roduced a radio wit h m ore rem ot e funct ionalit y t han t he Trey Research rem ot e. I n response, t he goals for t he Trey Research rem ot e were expanded. The Product Manager rewrot e t he PRD and briefed bot h t he hardware and soft ware t eam s. She t hen worked wit h t he soft ware t eam t o updat e it s Product Backlog. The hardware t eam figured t o have a new design specificat ion done in t wo m ont hs. A breadbox would be ready in t hree m ont hs. The prot ot ype would be ready wit hin six m ont hs. Unt il t he new design specificat ion was available, t he soft ware t eam couldn't det ail t he funct ionalit y of t he sim ulat ion layer on t he PC. The soft ware t eam also wasn't sure whet her all t he new capabilit ies could be handled on t he select ed com m odit y hardware. The m ore com plex t he product is, t he m ore change and m iscom m unicat ion can be expect ed. Scrum 's answer is t o require int egrat ion of all product com ponent s as frequent ly as possible, m inim izing lat er rework. I nt egrat ion should occur at least once per Sprint , and t he int egrat ed product is dem onst rat ed at t he Sprint Review. Som et im es ot her t eam s aren't using Scrum . Then t he Scrum t eam s are required t o int egrat e as oft en as possible t o t he best possible represent at ions of t he ot her part s of t he syst em . These represent at ions can be sim ulat ion layers, which are built by Scrum t eam s using t he best available designs from t he ot her, non- Scrum t eam s. What ever is possible m ust be devised and used t o m inim ize lat er rework. Unt il t he breadbox was ready, t he soft ware t eam had t o build a sim ulat ion of t he rem ot e's new funct ionalit y and int errupt st ruct ure as

best as it underst ood it . The t eam 's st art ing point was t he PRD and t he Product Owner. The soft ware t eam select ed several enhanced funct ions and several new funct ions for t he first Sprint . I t refact ored t he design t o broadly t ake t he ant icipat ed changes int o account . I t also ensured t hat t he previously developed funct ionalit y cont inued t o work. By t he end of t he first m ont h, t he hardware t eam had part ial specificat ions ready. For t he second Sprint , t he soft ware t eam select ed som e m ore new Product Backlog. The t eam also select ed several previously " done" it em s from t he first Sprint . I n t he second Sprint , it expanded and refact ored previous work t o t he new design inform at ion. I t m ade det ailed changes t o t he sim ulat ion layer. I t t hen t est ed t he previous " done" it em s t o ensure t hey st ill worked. By t he end of t he second m ont h, t he hardware t eam had t he design specificat ions done. During t he t hird Sprint , t he soft ware t eam first rebuilt t he sim ulat ion layer t o reflect t he new design. I t t hen com plet ely refact ored and redeveloped previously done work t o t he new design. The soft ware t eam t est ed it against t he sim ulat ion layer. At t he end of t he t hird m ont h, t he breadbox was done and delivered t o t he soft ware t eam . I f t his were a perfect world, t he breadbox and sim ulat ion layer on t he PC would operat e ident ically. To see whet her t his was t rue, t he t eam and Product Owner placed t he following new it em s on t he Product Backlog for t he fourt h Sprint : •

• • •

Test funct ionalit y t hat worked on t he sim ulat ion layer t o see whet her it also works on t he breadbox. Rect ify any discrepancies bet ween t he environm ent s t o t he correct design. Correct t he funct ionalit y if needed. Work wit h t he engineering t eam t o resolve overall discrepancies bet ween t he design and breadbox. Updat e t he sim ulat ion layer accordingly. Cont inue t o develop funct ionalit y for t he rest of t he Product Backlog.

During t he fourt h m ont h, t he hardware t eam was busy building t he prot ot ype. The soft ware t eam cont inued Sprint ing, but discovered t hat t he com m odit y hardware was no longer adequat e. The CPU was t oo slow and t he m em ory t oo lim it ed. The soft ware t eam negot iat ed wit h t he Product Owner and t he hardware t eam t o procure new hardware. This int roduced new work for t he hardware t eam . I t had t o revise t he design, t he breadbox, and t he prot ot ype. Com plet ed work had t o be revised t o t ake int o account t he changed hardware perform ance and charact erist ics.

The soft w are t eam revised t he Product Backlog. I t now had t o sim ulat e t he new m em ory and CPU capabilit ies on t he PC. I t had t o ret est all com plet ed funct ionalit y in t his environm ent . The design docum ent s were revised, and t he breadbox wit h t he m ore capable hardware was rebuilt . All com plet ed work again had t o be ret est ed. The solut ion j ust described required t he soft ware t eam t o ret est it s work against t he best possible represent at ion of t he com plet ed product . Every t im e t he design changed, t hese represent at ions had t o be changed for ret est ing. The rework was lim it ed t o t hat funct ionalit y and t he design com plet ed when t he change occurred. I f t he ent ire product was soft ware, several t eam s could be developing funct ionalit y using Scrum . The rest of t he proj ect t eam s could develop funct ionalit y using a wat erfall m et hodology. I n t hat case, a sim ulat ion layer could be built by t he Scrum t eam s from t he init ial wat erfall archit ect ure and design docum ent at ion. I t would be enhanced as t he wat erfall design changed. However, no com plet e int egrat ion could be accom plished unt il t he end of t he wat erfall, when overall int egrat ion t est ing could begin. The real soft ware from t he wat erfall part s of t he proj ect t hen would replace t he Scrum t eam s' sim ulat ion layer.

Summary We've looked at som e pract ices for int egrat ing ent erprise- wide Scrum engineering in t his chapt er. There are m any ot her variat ions t hat m ight be required. Each variat ion should bring you closer t o rapid developm ent and release of funct ionalit y. You have t o devise t hese solut ions yourself, based on Scrum principles, best engineering pract ices, and com m on sense. St art wit h an increm ent a m ont h. Figure out what has t o be done t o m ake it shippable. Then reduce t he lengt h of t he Sprint . Keep reducing t he lengt h. The solut ions aren't as hard t o figure out as t hey are t o im plem ent . You will know if t he solut ion works by asking, " Have we m oved our ent erprise closer t o being able t o ship yest erday's work t oday?" I f not , revise t he solut ion and t ry again. You have a long row t o hoe. St art now.

Chapter 8. People Practices I n t his chapt er: # 1: Organizing People t o Do Ent erprise Work

70

# 2: Team Creat ion

73

# 3: Team Work

75

# 4: How People Are Managed

76

# 5: Funct ional Expert ise

80

# 6: Com pensat ion

81

# 7: Ext ra Managers

81

# 8: Team s wit h Dist ribut ed Mem bers

82

# 9: Scarce Skills Needed by Many Team s

83

For t he last 30 years, product m anagem ent and developm ent have been driven by predict ive and funct ional pract ices. Because Scrum is radically different , t he way people work wit h it is different . When you view t he Scrum people pract ices recom m ended in t his chapt er, you m ight at first be t aken aback. You m ight wonder how t hese pract ices could m ake sense. Your react ion isn't because current pract ices m ake sense or even work. They are j ust your current way of doing t hings. I f you consider t hat t hey are t he basis of your current problem s wit h product m anagem ent and developm ent , changing t hem doesn't seem so unreasonable. When you consider t he pract ices in t his chapt er, consider t hem on t heir own m erit . Then, separat ely, consider t he st eps t o adopt t hem . Why are people willing t o m ake t he changes Scrum requires? We ask people t o m ove out of a com fort zone int o t he unknown. They m ake t he changes as a t radeoff t o have work t hat is creat ive and enj oyable. I t is an exchange for doing work in a way t hat m akes sense. Moving out of your com fort zone is t he cost for having cust om ers who can't wait t o get your product s. I t provides t he reward of t he j oy of fulfilling work. To m any, it is a fair t rade. This chapt er addresses how Scrum t eam s do t he ent erprise's work, t op t o bot t om . Chapt ers 6 and 7 described new ways t o organize your work. Now we'll look at how you can form , care for, and feed t he t eam s of people who will do t he work.

#1: Organizing People to Do Enterprise Work How do w e organize our people t o do our ent erprise's work using Scrum ? Your ent erprise's work can be organized, t op t o bot t om , int o a single Product Backlog. The organizing m echanism is a t op- down decom posit ion of product s, syst em archit ect ures, or business operat ions. Figure 8- 1 shows product decom posit ion by product , funct ion, act ivit y, and t ask.

Figur e 8 - 1 . En t e r pr ise w or k or ga n iza t ion , pr oduct de com posit ion [ View full size im age]

People are organized in Scrum t eam s t o m irror t he organizat ion of work. I n Figure 8- 1, a Scrum t eam exist s at each node in t he decom posit ion. Each Scrum t eam at each node is com m it t ed t o it s work. I t is also responsible for direct ing and successfully int egrat ing t he work of it s low er level nodes every Sprint . The work of any node is organized and priorit ized at t he next level up.

The bot t om - m ost node is where m ost developm ent occurs. Most Product Backlog requirem ent s select ed for Sprint s relat e t o t his level. All ot her levels are int egrat ion or infrast ruct ural developm ent levels. For inst ance, a com ponent " Ent er Telephone Num ber" is done at a node at t he lowest level, such as 1.1.1.1. During a proj ect , a Scrum t eam m ight be responsible for com plet ing a Product Backlog it em t o change t his com ponent . Product act ivit ies, such as " edit ," consist of m ult iple m odules. Act ivit ies, as out lined in Figure 8- 2, are t he next level of organizat ion for t he ent erprise's work, people, and m anagem ent .

Figur e 8 - 2 . Act ivit y- le ve l or ga n iza t ion

At t he Act ivit y level, an I nt egrat ion Scrum t eam is responsible for m anaging all t he work in it s lower nodes. The lower levels are direct ed by t he Act ivit y- level Product Backlog, which is m anaged by t he Act ivit y- level Product Owner. For exam ple, in Figure 8- 2, t he I nt egrat ion Scrum t eam at node 1.1.1 is responsible for m anaging all t he work of t he Scrum t eam s at nodes 1.1.1.1, 1.1.1.2, and 1.1.1.3. The I nt egrat ion Product Owner decom poses t he Product Backlog for each of t he Com ponent - level Scrum t eam s. There is a Product Backlog for t he node at 1.1.1. I t is parsed t o m inim ize dependencies and assigned t o t eam s at t he nodes of 1.1.1.1, 1.1.1.2, and 1.1.1.3. The I nt egrat ion- level Scrum developm ent t eam doesn't develop funct ional soft ware. I t develops facilit ies t o int egrat e, build, and t est t he work of t he low er level Scrum t eam s. I t builds infrast ruct ural facilit ies t o int egrat e t hese funct ions. The I nt egrat ion- level developm ent t eam also develops int egrat ion t est s t o confirm t hat all developm ent at lower level nodes works. A general rule is t hat if any

int egrat ion fails, t he levels below m ust fix t hat int egrat ion prior t o doing any new work. The I nt egrat ion Scrum Team at 1.1.1 m ust dem onst rat e t he int egrat ed increm ent s of t he Scrum t eam s at 1.1.1.1, 1.1.1.2, and 1.1.1.3 at t he Sprint Review. To do so, it m ust pull t oget her t he work of t he Scrum t eam s at 1.1.1.1, 1.1.1.2, and 1.1.1.3 as frequent ly as possible, but no less t han once per Sprint . I nt egrat ion- level t eam s can use t he sam e Scrum Mast ers, Product Owners, and Scrum developm ent t eam m em bers. Sharing bet ween t he Com ponent level and I nt egrat ion level should be m inim ized t o avoid t ask- swit ching overhead during act ual developm ent work. Sharing bet ween I nt egrat ion levels has fewer conflict s. An organizat ion of work at t he Product level m ight look like Figure 8- 3.

Figur e 8 - 3 . Pr odu ct - le ve l or ga n iza t ion [ View full size im age]

At t he Product level, a Product Owner is responsible for m aint aining an overall Product Backlog. For a specific release, he or she organizes a subset of t he overall Product Backlog int o a release Product Backlog. This Product Backlog is decom posed t o pieces owned by lower node Product Owners. For inst ance, t he Product Backlog owned by t he Product Owner at t he I nt egrat ion Scrum Team of node 1 cont ains all

t he Product Backlog owned by t he Product Owners at nodes 1.1 and 1.2. The Product Owner at node 1.1 cont ains all t he Product Backlog owned by t he Product Owners at nodes 1.1.1 and 1.1.2. This st ruct ure cont inues t o t he lowest level nodes. Product Owners, t op t o bot t om , are responsible for t he accuracy and t im eliness of t heir part of t he Product Backlog. To assist t hem , we usually have several people develop and groom t he Product Backlog in som e aut om at ed t ool such as Microsoft Office Excel. These people can com e from t he old Proj ect Managem ent Office. The Scrum Mast er on t he Product - level t eam at node 1 is responsible for enforcing t he rules and m echanism s of Scrum at t hat level and all lower levels. He or she ensures an int egrat ed, t est ed build at t he Product level for t he Sprint Review at each level of nodes—Product , Funct ion, Act ivit y, and Task. The Product Owner plans, com poses, dist ribut es, and t racks work from his or her level down. The overall Product Backlog is owned and m anaged by t he Product Owner on t he I nt egrat ion Scrum t eam at node 1. The higher t he level is, t he harder t he Product Owner's and Scrum Mast er's j ob is. The responsibilit y of Product - level j obs usually requires som eone wit h Vice President –level or Direct or- level t it le and aut horit y. Corresponding levels of responsibilit y and aut horit y are required at higher and lower levels. Daily Scrum s are held at t he lowest level nodes, such as 1.1.1.1. When m ult iple levels of Daily Scrum s are conduct ed, t his level is called S1. The higher level Daily Scrum of Scrum s are called S2, S3, S4, and so fort h and are held at each level. I f t here are m ore levels, t hey are num bered accordingly, but t he bot t om level node is always S1. Daily Scrum s for levels above S1, also called Daily Scrum s of Scrum s, are m eet ings bet ween represent at ives of all next - lower level t eam s t o discuss t he following four point s: • • • •

What did each t eam do yest erday? What will each t eam do t om orrow? What were ot her t eam s count ing on our t eam finishing t hat rem ains undone? What is our t eam planning on doing t hat m ight affect ot her t eam s?

These Daily Scrum of Scrum s m eet ings are working sessions t hat oft en last longer t han 15 m inut es. Their purpose is t o uncover and rem edy any dependency and int egrat ion issues bet ween t eam s as rapidly as possible.

At t he com ponent level ( S1) and act ivit y level ( S2) , t he Daily Scrum s are indeed held daily. The at t endees are people who are fam iliar wit h t he engineering cont ent of t heir area and can discuss t radeoffs wit h each ot her. At t he Feat ure level, t he S3 Scrum s m ight be held every t hird day. At t he Product level, t he S4 Scrum s are held weekly. At t he Product Fam ily level, t he S5 Scrum s are usually held no m ore oft en t han m ont hly. I f t he higher levels are held t oo oft en, t he am ount of inform at ion passing from t op t o bot t om and back, or churn, can overwhelm t he ent ire process.

#2: Team Creation How do I organize m y people int o Scrum t eam s? The Product Owner and Scrum Mast er are t he first people on a Scrum t eam . They are responsible for select ing t he Scrum developm ent t eam m em bers. To opt im ize t he product ivit y of t he t eam , t he developers are select ed based on t hree variables: • • •

People who have successfully worked t oget her previously People who underst and t he product or business dom ain People who know how t o use t he select ed t echnology

The t eam is also select ed based on what const it ut es a " done" increm ent . For inst ance, if user docum ent at ion is part of an increm ent , t he t eam should have a t echnical writ er. These people can be select ed from ot her, lower priorit y work t eam s. Or t hese people can be select ed from som et hing called t he bench. The bench is where unassigned Scrum t eam m em bers wait for work. They m ight be on t he bench because t heir work has been com plet ed or t hey were asked t o leave t heir Scrum t eam s. I n a brand new Scrum adopt ion, we line up t he Product Owners and Scrum Mast ers by t he ret urn on invest m ent ( ROI ) and priorit y of t heir work and let t hem choose t heir t eam s from t he bench. When no m ore people are left on t he bench or nobody want s t he rem aining people, we st op form ing t eam s. At t he st art of a release cycle or proj ect , t he Product Owners can form new t eam s based on t he priorit y of t heir Product Backlog. They can st ay wit h t heir exist ing t eam s, reform ulat e t heir t eam s, or get new t eam s. We, of course, first m ake t hem aware t hat product ivit y will significant ly drop as a t eam reform s and renorm alizes. Whenever possible, leave t eam s int act .

I t is easy t o t hink t oo m uch about who should be on a t eam . The best way t o ident ify who should be on a t eam is for t he t eam t o m ake t he decision it self. I ran int o a sit uat ion t hat t aught m e t his lesson. Woodgrove Bank is a large financial inst it ut ion whose prim ary service is banking. Woodgrove Bank had regional origins but had been growing t hrough nat ionwide acquisit ions of ot her banks. The t eller syst em s in t he acquired banks were different from Woodgrove Bank's t eller syst em . All t he t eller syst em s were difficult t o use. Woodgrove Bank form ed a proj ect t o creat e a new t eller syst em , Teller4U. A developm ent group of 45 people was form ed. The ent ire t eam report ed t o t he vice president of developm ent , Jack Creasey. The Product Owner, Scot t Culp, want ed frequent releases of Teller4U. Jack and Scot t agreed t hat five releases in t he first year would be appropriat e, and t hat Scrum would be t he best process t o deliver t hem . Each release would be used by a prot ot ype banking t eam t o provide rapid feedback. I n addit ion, t he developm ent group was using CVS, an easy- t o- use, but lim it ed source- code m anagem ent syst em . CVS's weakness w as t hat it didn't support sim ult aneous m ult irelease developm ent very well. Jack devised a way for t he 45 developers t o build t he five releases wit hin one year using CVS. Unfort unat ely, when I visit ed t he t eam s, t hey hat ed t he approach. They com plained t hat it was inefficient , st ill only allowed t wo sim ult aneous copies of CVS, and wasn't working. When I discussed t his wit h Jack, he asked m e t o devise a bet t er process t han his. He had wracked his brain, and it seem ed pret t y good t o him . Then we rem em bered self- m anagem ent . The people who do t he work are supposed t o figure out how t o do it . We asked t hem t o use Scrum . They were supposed t o figure out how t o do Teller4U from wit hin t he t eam s. Jack and I m et wit h all 45 developers. Jack rem inded t hem t hat t hey were self- m anaging. This m eant t hat t hey were t o com e up wit h t he best t eam st ruct ure and int ernal processes for developing Teller4U using Scrum . The developers looked at us carefully. They were sure t hat t hey were being set up t o t ake t he blam e. We ignored t heir looks. We t hen t old t he developers t hat we would be back in t wo hours t o hear t heir approach for building t he next release. What if t his didn't work? What if t he developers weren't able t o figure out how t o do t heir work? What if 45 people were t oo m any for selfm anagem ent ? What if we cam e back and t hey had done not hing for

t he t wo hours? Our expect at ions were low. We feared t hat no m ore t han five or six of t he lead developers would be in t he conference room when we ret urned. Much t o our surprise, all 45 developers were in t he conference room when we ret urned. The developers had also invit ed Scot t and his m anager of t he prot ot ype t eam int o t he m eet ing. The whit e boards were covered wit h schem at ics and t he conference t able lit t ered wit h paper. The prot ot ype t eam m anager st art ed by t elling us t hat she want ed only t wo releases t hat year. She said t hat five releases were far t oo m any t o really work t hrough, since t hey would be refining and t est ing various workflows as t hey t est ed each release. One of t he lead developers t hen t old us t hat t hey had figured out how t o use Scrum t o generat e t he t wo releases t hat year. I n part icular, one person from t he prot ot ype t eam would be on each Sprint t eam t o help t hem m ake t he best design decisions. Jack asked how t hey were going t o use CVS t o do t his. Speaking for all t he developers, a lead developer t old us t hat was none of our business. The t eam was self- m anaging and had figured out som et hing t hat should work. I f it st opped working because of an unexpect ed problem , t hey would be responsible for revising t he approach so t hat t hey could deliver t heir com m it m ent s. We eit her t rust ed t hem t o m anage t hem selves or we didn't . Jack and I left t he conference room wit h Scot t . We were t reat ed t o increm ent s of Teller4U funct ionalit y every m ont h, and t wo m ore releases t hat year. The proj ect is now in it s second year and doing fine.

#3: Team Work The people in m y ent erprise aren't used t o working in t eam s all t he t im e. What can I do t o prepare t hem ? Every Scrum t eam , regardless of it s level in t he ent erprise, will go t hrough t he st eps of form ing, st orm ing, norm ing, and perform ing. [ 1] This process is shown in Figure 8- 4. [1]

Tuckm an, Bruce W. ( 1965) " Developm ent al sequence in sm all groups,"

Psychological Bullet in , 63, 384–399.

Figur e 8 - 4 . Br u ce Tuck m a n 's Te a m For m a t ion M ode l

When done form ally and properly, t he first st ep—form at ion—sim plifies all subsequent st eps. I t arm s t he t eam for upcom ing problem s. The form at ion act ivit y can be facilit at ed by t he Hum an Resources Depart m ent or som e ot her source of t eam - building expert ise. During t his act ivit y, t he t eam develops an ident it y, a way of working t oget her, and a way t o resolve conflict s. Use exercises based on real- life problem s t he t eam can expect t o encount er. For exam ple, I usually have a t eam work on how it will develop requirem ent s and accept ance t est s. The t eam m em bers usually expect t hat t he analyst will do t he first requirem ent s and t he t est er will do t he t est ing. There are alt ernat ives, but it is im port ant for t he t eam t o figure out it s first st eps. At t he end of t he form at ion act ivit y, t he t eam should have a t eam nam e, it should have a definit ion of Sprint and Daily Scrum " done," as well as having form ed rules of et iquet t e and engineering rules. The t eam should discuss and t ent at ively form alize t heir Sprint process for t urning Product Backlog it em s int o som et hing " done." The t eam also needs t o be t rained in how t o resolve it s inevit able conflict s. When t he t eam st art s Sprint ing, it develops product . As it does so, professional conflict s about how t o do so and personal conflict s about who does what will arise. This is t he st orm ing phase of t he Tuckm an m odel. The t eam will use it s knowledge of conflict resolut ion t o com e up wit h agreem ent s in t he norm ing phase of t he m odel. I f t he t eam is unable t o do so, it draws again on t he Hum an Resources Depart m ent or any ot her ext ernally est ablished source of

help. These new agreem ent s will be t he basis of it s abilit y t o perform in t he perform ing phase. The perform ing phase is not perm anent . Disagreem ent s and conflict can be expect ed in t he com plexit y of product developm ent . The t eam will repeat edly fall back int o t he st orm ing phase and need t o com e up wit h new norm s of operat ion. I rem em ber walking t oward a t eam room one day. The t eam had been working t oget her for six weeks. As I approached t he room , t he lead analyst and lead engineer em erged from t he room , yelling at each ot her and calling each ot her nam es. They t hen fled in separat e direct ions before I could ask what was going on. I ent ered t he t eam room and found t he rest of t he t eam shocked and wit hdrawn. The t eam 's product ivit y was now zero. I asked what had happened. Apparent ly, before Scrum was adopt ed, t he analysis group always wrot e t he funct ional specificat ion and gave it t o t he engineers. The engineers t hen t ook libert y wit h t he specificat ion and wrot e t he syst em as t hey saw fit . The analysis group decried t his, and t he engineering group ignored t hem . This was a long- st anding conflict in t he ent erprise. When we put people from t he analysis and engineering group t oget her on t he t eam , t hey brought t he problem and all t he t ension of it wit h t hem . The problem had now bubbled up and st opped t he t eam dead in it s t racks. Adequat e t raining in conflict resolut ion or an ext ernal resource t o help t hem could have resolved t he conflict before it got out of hand.

#4: How People Are Managed How do I m anage people t o m eet ent erprise obj ect ives? Who is responsible for what ? How do I ensure t hat t hings get done? Scrum t eam s m anage t hem selves, from t he t op t o t he bot t om of t he ent erprise. You don't m anage t hem t o do t hings. You set goals. The t eam s m anage t hem selves t o build t he Product Backlog and reach t he goals. You inspect t he result s at t he end of every Sprint and adapt accordingly. To underst and how t o do t his, let 's consider a one- Scrum t eam com pany. The t eam report s t o you, t he CEO, t o build and deploy product . The t eam consist s of one Product Owner wit h one Product Backlog of work, one Scrum Mast er, and a developm ent t eam of eight developers. You m anage t he Product Owner and t he Scrum Mast er. The t eam is a single ent it y and m anages it self. ( All Scrum t eam s are self-

m anaging.) However, it is answerable t o t he Product Owner for building t he product . I t is answerable t o t he Scrum Mast er for follow ing t he Scrum process. Your ent erprise is successful. The product sells. Prospect s clam or for m ore. Cust om ers dem and enhancem ent s. You need t o build m ore product s quickly. You ask t he exist ing Scrum t eam t o add m ore people as rapidly as it can. I t furt her decom poses and rearranges t he Product Backlog so t hat subset s of it can be assigned t o new t eam s. I t figures four new Scrum t eam s can be im m ediat ely added. All t he Product Owners on t he new t eam s will report t o t he init ial Product Owner, who is responsible for opt im izing overall ret urn on invest m ent and com pet it iveness. All t he new Scrum Mast ers will report t o t he Scrum Mast er on t he original t eam , who will ensure t hat everyone knows how t o use Scrum and does so. The new Scrum t eam s m anage t hem selves. The init ial Scrum developm ent t eam is responsible for t he work of all new Scrum t eam s. I t has t o be consist ent and int egrat e int o one high- qualit y product . The t eam devises an archit ect ure wit hin which m ore t eam s can work on individual pieces wit hout st epping on each ot her. The t eam devises a set of coding and design st andards t o ensure consist ency. The t eam also set s up a com m on developm ent environm ent . I n Figure 8- 5, each new Scrum t eam —such as 1.1, 1.2, and 1.3—has a nucleus of one person from t he original Scrum t eam . He or she works wit h t he new t eam 's Scrum Mast er and Product Owner t o hire t he rest of t he developers. He or she is responsible for t eaching t he new people how syst em s are developed in your ent erprise. New Scrum t eam s can be form ed unt il at least one developer is left on t he original Scrum t eam . The original t eam consist s of t hese rem aining developers and t he original Product Owner and Scrum Mast er. This t eam now becom es an I nt egrat ion Scrum t eam , responsible for t he work of all subordinat e nodes.

Figur e 8 - 5 . Ex a m ple of a n Act ivit y- le ve l or ga n iza t ion

The ent erprise cont inues t o succeed. More and m ore people are hired. They are int erviewed and hired by t he Product Owner, Scrum Mast ers, and Scrum developm ent t eam , such as at 1.1. The Scrum t eam at 1.1 form s low er level Scrum t eam s, such as 1.1.1 and 1.1.2. Each new t eam consist s of a Product Owner, Scrum Mast er, and developm ent t eam . The new Scrum developm ent t eam s are seeded wit h people from t he parent node, such as 1.1. As t he ent erprise fleshes out , it looks like Figure 8- 6.

Figur e 8 - 6 . Ex a m ple of a Pr oduct - le ve l or ga n iza t ion

The Product Owner at t he very t op of t he hierarchy, node 1, is responsible for overall Product ROI and success. The Scrum Mast er at node 1 is responsible for Scrum being used effect ively t hroughout t he ent erprise. This Scrum Mast er is also responsible for overall ent erprise change. At each node in t he hierarchy, t he Scrum developm ent t eam s report t o t he Product Owner t o find out what work t o do, and t o t he Scrum Mast er for inst ruct ions on follow ing t he Scrum process and facilit at ing change. The Scrum Mast er is responsible for t eaching t he Product Owner how t o m ost effect ively m anage t he work of t he Scrum t eam using t he Product Backlog, Sprint Planning Meet ing, and t he Sprint Review Meet ing. He or she t eaches t he Product Owner how t o m axim ize ROI and m eet t heir obj ect ives t hrough Scrum . The Scrum Mast er is also responsible for im proving t he lives of t he developm ent t eam by facilit at ing creat ivit y and em powerm ent . He or she is responsible for im proving t he product ivit y of t he developm ent t eam in any way possible. Also, t he Scrum Mast er is responsible for working wit h t eam s t o im prove t he engineering pract ices and t ools so t hat each increm ent of funct ionalit y is pot ent ially shippable. When people aren't fulfilling t heir roles, t he person held account able is t he Scrum Mast er. He or she hasn't t aught t he t eam how t o do t heir work.

The developm ent t eam s are responsible for m anaging t hem selves. Every Sprint , t hey evaluat e t heir processes for opport unit ies t o im prove t hem . They are required t o follow all t he convent ions, archit ect ures, and st andards devised by t he original Scrum t eam . As t hese evolve, t he developm ent t eam s are responsible for st aying conversant wit h t hem and cont inuing t o follow t hem . They are also responsible for int egrat ing t heir work wit h all higher levels at least once a Sprint . Som et im es t he new hires don't work out . When t hey degrade t eam perform ance or product ivit y, t he t eam is responsible for rem oving t hem . The t eam t ells t hem t hat t hey are no longer needed. The " purged" person goes t o t he bench. They can be select ed from t he bench by anot her t eam looking for new m em bers. I f t hey are on t he bench t oo long, Hum an Resources is responsible for placing t hem elsewhere in t he ent erprise. Team s are very reluct ant t o rem ove anyone, however. They are a social group t hat t ends t o be very forgiving and caring. Offset t ing t eam reluct ance t o rem ove t eam m em ber is t he Product Owner's need for product ivit y. I f t he Product Owner's developm ent t eam isn't product ive enough, t he ant icipat ed ret urn on invest m ent can't be achieved. He or she t hen m eet s wit h t he Scrum Mast er t o replace or reform ulat e t he exist ing t eam . On one proj ect I was involved wit h, t he Scrum Mast er rem oved four m em bers of a sevenperson t eam and product ivit y soared. When t his isn't possible, t he Product Owner m ight have t o cancel t he proj ect . Som et im es people on t he developm ent t eam or t he Product Owner won't or can't com ply wit h Scrum . The Scrum Mast er m ust replace t hem . They m ust be rem oved before t hey drag down t he ent ire t eam , process, and ent erprise. The t act ics for rem oving a Product Owner are oft en st icky. However, t he absence of a Product Backlog or Product Backlog burn- down is a com pelling reason t o do so. Worse, creat ion of irrelevant or off- t arget increm ent s, Sprint by Sprint , wit h no correct ion is appalling. The Scrum Mast er is responsible for t eaching t he Product Owner how t o do his or her j ob. I f t he raw m at erial is weak, t he Scrum Mast er can't let failure t o com ply wit h Scrum persist for m ore t han t wo Sprint s. Som et im es Scrum Mast ers are ineffect ive. They don't t each t he Product Owner how t o m anage t he Product Backlog. They don't t each t he t eam how t o self- m anage. They cont inue t o use com m and- and- cont rol t echniques. They should be rem oved by t he Scrum Mast er t hey report

t o. Som et im es Scrum developm ent t eam s are ineffect ive. They can't build enough product t o m eet t he Product Owner's needed ret urn on invest m ent . The Product Owner should eit her work wit h t he Scrum Mast er t o reform ulat e t he t eam or cancel t he proj ect . Som et im es t he Product Owners don't m eet t he ret urn on invest m ent required by t he Product Owner t hey report t o. That Product Owner should replace t hem . A Scrum report ing st ruct ure for an ent erprise is shown in Figure 8- 7.

Figur e 8 - 7 . Scr um r e por t in g r e la t ionsh ips [ View full size im age]

The Product Owners report t o each ot her, up t hrough t he hierarchy of nodes. At each node, t he Scrum developm ent t eam report s t o t he Product Owner regarding what work t o do and t he Scrum Mast er for inst ruct ion on conform ing wit h t he Scrum process. This report ing relat ionship is unusual because t he t eam m anages it self. The Product Owner is only responsible for t elling t he Scrum developm ent t eam what t o do at t he st art of every Sprint in t he Sprint Planning Meet ing. The Product Owner doesn't m anage or review t he individual t eam m em bers. He or she inspect s t he t eam 's work only at t he Sprint Review. The Scrum developm ent t eam sim ilarly report s t o t he Scrum Mast er for com pliance wit h t he Scrum process. Scrum Mast ers

report t o t he Scrum Mast er at t he next higher node, up t hrough t he hierarchy of nodes.

#5: Functional Expertise My developm ent organizat ion has different funct ional skills, such as syst em s archit ect ure, usabilit y engineering, program m ing qualit y assurance, and t echnical writ ing. People wit h t hese skills used t o be m anaged by a funct ional m anager. Now t hese funct ional m anagers are Scrum Mast ers, Product Owners, or Scrum developm ent t eam m em bers. How do I ensure t hat t he funct ional skills are kept at t he highest levels? I recom m end t hat you set aside a part of every em ployee's t im e t o pursue act ivit ies t hat are out side t heir current Scrum t eam s and t hat benefit t he ent erprise. I recom m end an allowance of 20 percent of t heir t im e. Let t he people coalesce int o int erest groups where t hey work t oget her. Som e of t his t im e can be spent working wit h peers in sust aining and enhancing funct ional expert ise. Som e of t he work can be researching and prot ot yping new ideas. The yellow st icky not es of 3M and Gm ail at Google were developed in t his way. Twent y percent of everyone's t im e m ight seem like a big invest m ent for your ent erprise. I f you add up all t he t im e you used t o invest in funct ional organizat ions, it will be m odest by com parison. Try t his approach and be prepared t o be surprised, as Google and 3M were. People form funct ional expert ise groups around syst em s archit ect ure, qualit y, program m ing, refact oring, and any ot her developm ent expert ise. They will define st andards, guidelines, and convent ions for such ent erprise work. These groups will also define career pat hs wit hin t hat discipline wit hin t he ent erprise, and crit eria and t est s for advancing along t he career pat h. They also m ight want t o be available as a recruit er and int erviewer of new people. These groups em erge based on m ut ual int erest . These groups self- m anage funct ional expert ise wit hin t he ent erprise. They do not have a m anager. All of t hese groups use Scrum . They elect Product Owners, Scrum Mast ers, and t eam s. They spell t heir work out in a Product Backlog.

#6: Compensation How do I com pensat e and reward people for t heir work? Does t he t eam st ruct ure change anyt hing?

Two variables cont rol a person's pay. Base salary of an em ployee is direct ly proport ional t o his or her responsibilit y and account abilit y. Direct ors earn a higher base pay t han supervisors. Lead program m ers earn a higher base pay t han j unior program m ers. The great er t he salary, t he m ore t hat is expect ed of t hem . The second variable is t he perform ance of ent erprise, t he big t eam . You can reward all t eam s' perform ances from a com m on pot of funds. The source of t he funds is all m oney t hat would ot herwise have been allocat ed t o bonuses or individual incent ive pay. Use t his pot of funds t o reward t eam perform ance t oward ent erprise goals. The incent ive pay is dist ribut ed t hrough a t eam t o it s m em bers proport ionally according t o base salary. I f one t eam m em ber m akes $x and anot her m akes $2x, t he t eam bonus is split so t hat t he person m aking $2x get s t wice as m uch of it as t he person m aking $x. This allocat ion is based on t he assum pt ion t hat som eone wit h a base pay t hat is t wice as m uch as anot her person has knowledge and skills t wice as valuable. The person who allocat es t he t eam bonus is t he Product Owner. This st art s at t he t op of t he ent erprise and is allocat ed downward according t o perform ance.

#7: Extra Managers I 've assigned people t o be Scrum Mast ers, Product Owners, and part of Scrum developm ent t eam s. There are st ill som e ext ra m anagers. What do t hey do? Alm ost all t he product m anagem ent and developm ent work is done in a hierarchy of Scrum t eam s. Unless rem aining st aff and m anagers have ot her solid work t o do, t heir idle hands are t he devil's workshop. They int erfere wit h t he Scrum t eam s. I visit ed several Wingt ip, I nc. t eam s at t heir Sprint Planning Meet ings. St rangely, t heir m anagers were in at t endance. The t eam m em bers sat in silence, while t he m anagers invest igat ed t he work, asked quest ions of t he t eam m em bers, com m it t ed t he t eam t o t he Sprint goal, and t hen broke down and assigned t he work. No self- m anagem ent occurred. The product ivit y and j oy of t eam work was forgone. I invest igat ed and found t hat 18 first - and second- level m anagers were st ill unassigned. They didn't want t o be Scrum Mast ers. They st ill want ed t he prest ige and aut horit y of t heir old j obs. I gat hered t hem t oget her. I asked t hem what t heir responsibilit ies were regarding t he people who report ed t o t hem and who were also in Scrum t eam s. The

t hings t hey t old m e t hey were responsible for included ensuring t here was no slack t im e, t hat t he work was appropriat e, and t hat t he people were doing t heir work correct ly. Of course, t hese weren't self- m anaging t eam s. Scrum developm ent t eam m em bers st ill report ed out side t heir Scrum t eam . Worse, unt il t heir m anagers found ot her m eaningful work, t hey would cont inue t o m anage t he people who st ill report ed t o t hem .

#8: Teams with Distributed Members The people in som e of m y t eam s aren't collocat ed. What do I do? I f people on a t eam haven't worked t oget her, t hey don't t rust each ot her. They don't know what t he ot her person is likely t o do. They can't ant icipat e how t o work wit h t hem . One com pany had a t eam t hat had m em bers in Lit huania, Finland, t he UK, Pennsylvania, and Alabam a. The ent ire t eam gat hered at headquart ers in Pennsylvania wit h t he Product Owner t o plan t he release. They st ayed t oget her for t he first one or t wo Sprint s of t he release t o iron out t he highest value and archit ect ural issues. Then t he t eam m em bers went back t o t heir offices. They cont inued t o use t he sam e shared developm ent environm ent . They had t heir offices connect ed all t he t im e by I nt ernet - enabled int ercom . Whenever anyone had a quest ion, he or she would j ust lean over t o t he int ercom and ask it of whom ever was nearby. I f nobody was present , t he em ployee would use inst ant m essaging or e- m ail. Daily Scrum s were st ill 15 m inut es long. Everyone would call in on a conference call. The call oft en ext ended past t he Daily Scrum as design and t est ing issues were worked out . For each Sprint Review and Planning m eet ing, at least half t he t eam would gat her again in Pennsylvania wit h t he Product Owner. Anot her com pany had a t eam t hat was evenly split bet ween New York Cit y and China. They followed t he sam e t eam pract ices as t he t eam j ust m ent ioned, but t he t im e- zone differences m ade t he Daily Scrum s hard t o schedule. The t eam decided t o form represent at ive t eam s. One person in China represent ed t he rest of t he Chinese at t he Daily Scrum for t he first week. For t he next week, one person in New York represent ed t he rest of t he New Yorkers at t he Daily Scrum . The person represent ing his or her locat ion was t hen responsible for com m unicat ing wit h t he rest of t he t eam at t heir locat ion.

I not only have t eam s wit h dist ribut ed m em bers, but m y t eam s are dist ribut ed in different locat ions. What do I do? These t eam s are required t o int egrat e t heir work int o one dem onst rable increm ent at least once every Sprint Review Meet ing. To do so, t hey probably will have t o int egrat e and t est t heir work at least weekly, and perhaps daily. I nt egrat ion will require t hem t o work t oget her t hrough several Sprint s t o resolve differences and use t he sam e design. The t eam s will devise t he best m echanism s t o do so if and only if t hey are held account able for one int egrat ed increm ent . The m echanics of int egrat ion across t eam s are t horoughly discussed in Chapt er 7, " Engineering Pract ices."

#9: Scarce Skills Needed by Many Teams Only a few people have cert ain skills. They are needed by m any t eam s at once. I know everyone on a t eam should be full t im e, but how do I handle t his? Three Scrum t eam s had work t hat originat ed from t he sam e Product Backlog. The t eam s used t he sam e developm ent environm ent . Every t eam needed t he sam e dat abase adm inist rat or ( DBA) full t im e for t he next several Sprint s. They asked m e t o t ell t hem what t o do. I invest igat ed t he Product Backlog wit h t he Product Owner. Each t eam 's work was about t he sam e priorit y as t he ot her t eam s. Rem em bering t he wisdom of Solom on, I t old t he t eam s t o split t he DBA's t im e, 33 percent t o each t eam . At t he next Sprint Planning Meet ing, t he t eam s t old m e t hat m y solut ion didn't work. The t eam s all needed t he DBA t he sam e t im e during t heir Sprint s. I was em barrassed. My solut ion hadn't worked. I wracked m y m ind for a bet t er solut ion. Then I rem em bered t hat t hese t eam s were supposed t o m anage t hem selves. I asked t hem t o spend t he next hour and devise t heir own solut ion. At t he end of t he hour, t he t eam s had agreed t hat t he DBA would spend m ost of her t im e wit h t he t eam where her work was m ost crit ical. However, she would m ent or and coach several people on t he ot her t eam s for all t heir DBA work. Most crit ically, t hey said t hat no t eam would com m it t o any work unless t he DBA was in t hat t eam 's Sprint Planning Meet ing and also com m it t ed. As a result , all t hree t eam s had t heir Sprint Planning Meet ing in t he sam e room at t he sam e t im e. The t eam 's solut ion becam e a general pract ice for Scrum t eam s wit h ext ernal dependencies. The ext ernal dependency can be a scare

resource, anot her t eam , or an ext ernal vendor. Regardless, a t eam cannot com m it t o Sprint work unless t he ext ernal dependency is in t he Sprint Planning Meet ing and also com m it s. People who represent scarce resources oft en argue t hat t hey need t o do t heir work in isolat ion, separat e from t he t eam s t hat will use t heir work. They argue t hat t hey are m ore effect ive t han if t hey were on Scrum t eam s. Whenever t his is done, t he scarcit y becom es am plified. Their separat ion from t he people who use t heir work increases and m iscom m unicat ions grow. Ment oring and cross- t raining disappear. The best solut ion is t o have t hem be part of t he t eam s t hat use t heir work. They t hen m ight see new solut ions t hat are bet t er t han t hose derived in isolat ion. As t hey work wit hin t he t eam , t he t eam m em bers learn from t hem . Som et im es t here j ust aren't enough resources for t he work t hat is desired. The t eam s can't devise clever solut ions t hat fully m it igat e t he short age. Then you have a real const raint t hat m ust be addressed by slowing down t he t eam s t o cross- t rain t hem . You can hire addit ional people, but t hey t oo have a learning curve before t he const raint is lessened and rem oved.

Chapter 9. The Relationship Between Product Management/Customer and the Development Team I n t his chapt er: # 1: Short ening t he Tim e t o Release Through Managing Value

86

# 2: Just Do I t

90

# 3: The I nfrast ruct ure, or Core

90

# 4: Accelerat ors t o Recovery

92

# 5: The Mot her of All Problem s

93

Unt il recent ly, I viewed t his relat ionship as one of m any changes in a Scrum adopt ion. I now view it as t he m ost crit ical change, t he lynchpin of t he adopt ion. I f t his change is successful, t he use of Scrum will persist and benefit s will increase. I f t his change isn't successful, t he use of Scrum in your ent erprise m ight well unravel. Many ent erprises can't develop and release product s as quickly as t hey would like. The lengt hened release cycle im pairs t hem com pet it ively. Surprisingly, t he cause can be t raced t o t he relat ionship bet ween an ent erprise's product m anagers/ cust om ers and t heir developers. This relat ionship is deeply ingrained. Product Owners cherish t heir half of t he relat ionship. I t is t he only way t hey know t o get releases done on t im e. Developers j ust do what ever is needed t o keep t he Product Owners happy. This relat ionship changes when you adopt Scrum . The Product Owner is asked t o m anage a proj ect t o opt im ize value. The developers are asked t o be open and honest about t heir progress even if it disappoint s t he Product Owner. I n t his chapt er, I 'll present a way you can short en t he t im e t o release t hrough m anaging value. The result s will not only be fast er developm ent , but higher qualit y and less expensive developm ent . I 'll t hen present t he im pact and consequences of your current cust om er and developer relat ionship on your ent erprise. We'll look at som et hing called t he infrast ruct ure and it s role in your woes. We'll t hen explore som e accelerat ors t hat m ight short en your developm ent cycle in conj unct ion wit h Scrum . Finally, I 'll expose t he origins of t he problem in t he t radit ional cust om er and developer relat ionship so t hat you can guard against it s recurrence.

#1: Shortening the Time to Release Through Managing Value We have t o com m it t o delivery dat es. The ent erprise has prom ised t he next release t o key cust om ers, and we have t o deliver on t im e t o keep t hem . How do we do t hat using Scrum ? Scrum int roduces t he possibilit y of value- driven developm ent . We usually cont rol proj ect s t hrough four variables: 1. 2. 3. 4.

The The The The

funct ionalit y we want and t he work needed t o build it t im e for delivering t he funct ionalit y, or t he due dat e cost of t he proj ect qualit y of t he funct ionalit y

Scrum int roduces a fift h variable, value. We can short en delivery dat es and reduce cost s by opt im izing t he value of t he proj ect . We opt im ize value by delivering t he highest value increm ent s of funct ionalit y first . We st op delivering increm ent s when t he value is less t han t he cost . We also st op delivering increm ent s when t he opport unit y value is great er t han t he m arginal value of t he next increm ent . A proj ect used t o be " done" when all t he funct ionalit y t hat we could t hink of was delivered. St at ist ics show t hat at least 65 percent of t his expensive, hard- won funct ionalit y is rarely or never used. [ 1] Think of t he m ost com m on deskt op soft ware. Most of t he lower m enu pat hs are rarely or never navigat ed. Regardless, t he vendors paid t o build t hem and cont inue t o pay t o m aint ain t hem . For exam ple, suppose t he Product Owner est im at es t he cost t o deliver t he release at $1,000,000. I t can be done in 10 m ont hs. The ent ire proj ect has a ret urn on invest m ent ( ROI ) of 28 percent . Som e of t he funct ionalit y m akes a significant cont ribut ion t o t he ROI , and ot her pieces don't . I f t he Product Owner knew which funct ionalit y were ROI drags, he or she would not build t hem . The Product Owner m ight be able t o deliver an im proved ROI by spending only $350,000 and delivering in four m ont hs. This is an exam ple of j udiciously m anaging t o opt im ize value. This is value- driven release m anagem ent . [1]

Jim Johnson, My Life I s Failure ( The St andish Group I nt ernat ional, I nc., 2006)

Opt im izing value is st raight forward wit h Scrum . The first st ep is t o est ablish a baseline plan represent ing t he funct ionalit y t o be delivered. I t is organized as an est im at ed, priorit ized Product Backlog. Capacit y, or developm ent velocit y, is t hen est im at ed. Divide t he t ot al work of t he Product Backlog by t he m ont hly capacit y. The result is t he

est im at ed num ber of m ont hs for t he ent ire proj ect and t he est im at ed com plet ion dat e. Personnel cost s are calculat ed from t ot al ut ilized capacit y. The proj ect st art s t oward t hese goals, and t he Product Owner m onit ors it s progress, Sprint by Sprint . A full descript ion of t his approach is in m y earlier book, Agile Proj ect Managem ent wit h Scrum ( Microsoft Press, 2004) . Som et im es proj ect progress doesn't m eet t he baseline plan. The est im at es were wrong. The t eam 's velocit y was lower t hen expect ed. Changes were needed. The baseline dat e is in danger. The Product Owner can m onit or t his, as shown in Figure 9- 1, by t racking t he burndown of rem aining Product Backlog work.

Figur e 9 - 1 . D e via t ion fr om t h e ba se lin e pla n

At t he end of t he t hird Sprint , less work has been com plet ed t han expect ed. The Product Owner has early warnings of schedule variance. He or she can adj ust everyone's expect at ions accordingly. This is sim ilar t o an ent erprise's financial and sales plans when a forecast becom es a baseline plan. Everyone synchronizes t heir work t o t he forecast . On a m ont hly basis, act ual result s are com pared t o forecast and t he ent erprise adj ust s. The act ual result s m ight not be what are desired, but we can t ake early act ion. Now we can do t he sam e adj ust m ent wit h developm ent proj ect s.

The Product Owner m anages value t o cont rol a proj ect 's end dat e. By re- evaluat ing and rest ruct uring t he cont ent of t he proj ect , t he overall work can be reduced. He or she priorit izes t he funct ionalit y as t he Product Backlog changes so t hat t he m ost valuable work is always t he highest priorit y. As each increm ent is done, t he Product Owner evaluat es it . When t he ant icipat ed value st art s reducing ROI , t he proj ect can be st opped. The funct ionalit y can t hen be shipped and t he ent erprise can st art benefit ing sooner t han expect ed.

Relative Valuation with Scrum I t is hard t o det erm ine t he ROI of individual pieces of funct ionalit y. For inst ance, how m uch m ore revenue will accrue if we spend $270,000 t o develop funct ionalit y t o im port a prior year's t ax dat a? To com pensat e for t his difficult y, we can use t he st at ist ical t echnique of relat ive valuat ion. We can provide t he Product Owner wit h 1,000 im aginary Ping- Pong balls. Larger proj ect s get m ore. We ask him or her t o allocat e t hem am ong t he Product Backlog based on t he im port ance of each it em t oward m eet ing goals of t he release. Som e it em s are really, really im port ant and get m ost of t he Ping- Pong balls. Surprisingly, m ost of t he Ping- Pong balls go t o only 35 percent of t he funct ionalit y. The hypot het ical Product Backlog dem onst rat es t his in Figure 9- 1a.

Figur e 9 - 1 a . Pr oduct Ba ck log Va lu e D ist r ibu t ion PROD UCT BACKLOG

VALUE

EFFORT

I t em 1

80

13

I t em 2

75

34

I t em 3

75

21

I t em 4

74

13

. . .

. . .

. . .

I t em 28

10

34

I t em 29

8

13

Relat ive valuat ion of Product BacklogScrum t eam s t urn t he Product Backlog int o shippable increm ent s of funct ionalit y. We can t rack t he relat ive value of t he funct ionalit y delivered in each increm ent , count ed

in Ping- Pong balls. We can t rack t he accum ulat ed value delivered across t im e in a graph, as shown in Figure 9- 2.

Figur e 9 - 2 . Cu m u la t ive va lu e cur ve

At t he st art , cum ulat ive value rises slowly as infrast ruct ure and t he developm ent environm ent are put in place. The cum ulat ive value t hen rises quickly as t he highest value Product Backlog it em is com plet ed. When lower priorit y Product Backlog it em s are delivered, t he accum ulat ion of value slows. This t echnique works if t he num ber of Ping- Pong balls, or relat ive value, rem ains const ant t hroughout t he proj ect . However, t he t ot al am ount of value can increase or decrease as t he Product Backlog changes. The cum ulat ive value delivered for each Sprint m ust t hen be recalculat ed t o a new baseline. Tip Here is a form ula you can use t o help re- baseline t he relat ive value of all Product Backlog it em s whenever t he t ot al value changes: Code View: Scroll / Show All ((new total value/last total value) * old accumulated value at that Sprint = new cumulative value at that Sprint)

For exam ple, if t he baseline value is 1,000 and we add a Product Backlog it em wit h a value of 200, t he t ot al new value is 1,200. I f w e had delivered 200, 380, and 500 point s of value in t he first t hree Sprint s, t hese would be reevaluat ed t o t he following: (1200/1000)*200, (1200/1000)*380, and (1200/1000)*500

The Product Owner can now t rack bot h proj ect progress and cum ulat ive value delivered t o opt im ize t he proj ect 's value. For inst ance, in Figure 9- 3, t he ent erprise want s t o st art using t he product at t he end of m ont h 20. A t rend line drawn at m ont h 10 indicat es a lat er com plet ion dat e t o be likely. The cum ulat ive earned value curve in Figure 9- 2, t hough, shows t he cum ulat ive value slope dropping by m ont h 10. When t he slope is less t han 1, it could indicat e t here is an opport unit y for value- driven developm ent . The Product Owner could st op t he proj ect . I n t his exam ple, lower value funct ionalit y is rem oved from t he proj ect and t he rem aining am ount of work drops. At t he average velocit y, t he proj ect can now be com plet ed by m ont h 20. By direct ing work t o m axim ize ROI , t he Product Owner has m et t he ent erprise's obj ect ives. He or she has used Scrum t o opt im ize value.

Figur e 9 - 3 . Va lue - dr ive n pr oj e ct

#2: Just Do It We t ried value- driven m anagem ent . We've m assaged t he requirem ent s t o elim inat e low- value Product Backlog requirem ent s. We're st ill not going t o hit t he dat e. There is t oo m uch t o do. I n t he

past , we've asked developm ent t o work harder. We t ell t hem t o do what it t akes. They've always com e t hrough for m e. I s t his OK in Scrum ? What a dilem m a! We have a budget . We need t o get t he release t o t he cust om ers on t hat dat e, and we can't rem ove any m ore requirem ent s wit hout violat ing t heir expect at ions. Why can't we do what we've always done—j ust t ell t he developers t o do it ? Developers can increase t he am ount of funct ionalit y t hey build if t hey reduce t he qualit y of t he funct ionalit y. Reducing qualit y is a t im ehonored t radit ion. Why not ? As one product m anager point ed out t o m e, " Qualit y is int angible! " This t radit ion operat es as follows. We ask for m ore funct ionalit y or changes. The developers t ell us it will t ake m ore t im e. We say t hat is t oo m uch t im e. The developers prot est . We escalat e t o t heir m anagem ent . We t ell m anagem ent , " The developers aren't on board, t hey aren't part of t he t eam , and t hey are slacking off." The m anager of t he developers t hen t ells t hem t o " do it ." And, by golly, it works! They do it . The developers reduce qualit y by elim inat ing careful const ruct ion of design and logic. They don't review code for flaws. They don't creat e or run adequat e t est s. They work 12 t o 14 hours a day and on weekends. They hack out som et hing t hat kind of works. Developers can increase t he am ount of funct ionalit y delivered by a fact or of t hree, in t he short t erm . Cut t ing qualit y usually works for a single proj ect . However, it should be used only in ext rem e circum st ances. Aft erward, t he qualit y needs t o be rest ored im m ediat ely. The cost you can use is $4 t o rem ediat e every $1 of dropped qualit y. Dropping qualit y m ight seem like a good short - t erm fix, but it decreases t he value of an ent erprise asset . I t s repeat ed use has significant negat ive effect s on t he ent erprise.

#3: The Infrastructure, or Core Even cut t ing qualit y didn't do it . We can build new funct ionalit y sat isfact orily; however, it t akes us m uch longer t o build funct ionalit y in our core product s, or infrast ruct ure. How do we arrange t his work using Scrum t o m eet our deadlines? Alm ost every ent erprise t hat I 've worked wit h shares a com m on engineering problem . I t revolves around t he ent erprise's " core" or " infrast ruct ure" or " legacy" product . The core is t he heart of all t he soft ware or product s for t hat ent erprise. I t is t he com m on, basic

funct ionalit y of all it s product s. I t is where t he com m on shared dat abases, t ransact ion processing, and funct ionalit y reside. These ent erprises can rapidly build new funct ionalit y. However, m uch of t he new funct ionalit y also requires changes in t he core. The problem is t hat t he core t akes a long t im e t o change or m odify. For every one hour spent building new funct ionalit y, t en hours have t o be spent enhancing core funct ionalit y. Hundreds of developers m ight be held up wait ing for core funct ionalit y changes. The im pact of core funct ionalit y on developm ent proj ect s is expressed in t he following exercise. We need t o release a new feat ure t o our cust om ers wit hin t hree m ont hs. Three pieces of funct ionalit y are needed and consist of t he following work: • • •

Funct ion 1: 20 unit s of work—15 of new code and 5 in t he core Funct ion 2: 40 unit s of work—25 in t he new code and 15 in t he core Funct ion 3: 30 unit s of work—20 in t he new code and 10 in t he core

We have m ade m easurem ent s and know t hat our abilit y t o build funct ionalit y has t he following charact erist ics: • •

New funct ionalit y can be built at a velocit y of 15 unit s of work per Sprint per t eam . As m any t eam s as desired can be put on t his work because no pre- exist ing knowledge is needed. Core funct ionalit y can be built at a velocit y of 5 unit s of work per Sprint , t ot al. This is t he m axim um velocit y. I t can't be increased. There is nobody else wit hin t he ent erprise who can successfully work on t he core.

How do w e arrange t he t eam s t o m eet t he t hree- m ont h release dat e? Upon inspect ion, it appears possible. We usually j ust increase t he num ber of people working on a proj ect t o m ake a dat e possible. However, t he core velocit y const rains t his approach. There is no way we can m ake t his happen. We can get eit her funct ion 1 and 3, or funct ion 2, com plet ed in t hree m ont hs, but no m ore. We are st uck. This problem int rigued m e. Why was t he core developm ent velocit y so low? Why was t he core so hard t o m odify? I found t hat all cores had t he following com m on charact erist ics: •

They were fragile because t hey were poorly engineered. They have duplicat ed code, overly com plex code, code plast ered on

• •

t op of ot her code, undocum ent ed code, and code t hat didn't follow any st andards. Docum ent at ion is nil or alm ost useless. Whenever a change is m ade t o t he core, som et hing is likely t o break elsewhere in t he core. I nadequat e t est s were available t o check t hat t he core product st ill worked aft er m odificat ion. When t est s were available, t hey were rarely aut om at ed. Ret est ing t ook a very, very long t im e. Only a handful of developers were left t hat were st ill com pet ent t o m ake m odificat ions t o t he core. Even fewer were willing t o do so. Everyone else had ret ired, died, or gone on t o m ore int erest ing work.

I refer t o core product s wit h t hese charact erist ics as being " dead." I t is very hard t o get life from t hem . How did t he core get t his way? The process is well known t o all of us. I t is inherent in t he t radit ional cust om er and developm ent relat ionship. That t he process builds dead cores is less well known. Let 's look at how t his happens. We visit ed Wingt ip in Chapt er 7, in t he " # 1: Mult ilayer Syst em Work Organized by Funct ionalit y" sect ion. Wingt ip's sit uat ion had becom e worse since t he t im e of t hat anecdot e, wit h furt her det eriorat ion t o it s core. Several m ore core developers had left . However, t he com pet it ive pressure on t he advert isem ent serving product had grown m ore severe. Ten Scrum developm ent t eam s were assigned t o add new funct ionalit y in a product road m ap. The road m ap called for 160 new or enhanced pieces of funct ionalit y. The t eam s est im at ed t hat 33 percent of all work would have t o be done in t he core. I was at t ending a Sprint Review when I not iced som et hing funny. The t eam s were dem onst rat ing funct ionalit y wit hout required changes t o t he core. They had segregat ed t he approxim at ely 33- percent core funct ionalit y changes int o anot her Product Backlog. This work would be done lat er. As a consequence, what was dem onst rat ed couldn't be adopt ed and wasn't done. Only one t eam was able t o dem onst rat e fully working funct ionalit y. I t had developed an applicat ion program m ing int erface ( API ) around t he core. New funct ionalit y called on t he core t hrough t he API . Rat her t han m odify t he core, t he t eam rebuilt part s of t he core int o t he API . The t eam even put a new dat abase m anagem ent syst em in t he API . The core effect ively now exist ed in t wo places. This creat ed a conundrum for any furt her developm ent . Did j ust t he core have t o be updat ed? Or did t he API have t o be updat ed also? You can im agine t he chaos if all 10 t eam s had followed t his approach.

We rest ruct ured t he Sprint Planning Meet ing t o m ake t he velocit y const raint of t he core m ore visible. We brought all t he Product Owners, Scrum Mast ers, and developers for t he 10 t eam s int o a large room . We asked t he Product Owners t o collect ively priorit ize all t heir work. Then, in priorit y order, each Product Owner and lead engineer got t o form a t eam for t he next Sprint , including t he necessary core developers. As each t eam was form ed, we asked t he people on it t o leave t he room . Ten pieces of funct ionalit y were select ed. Then t here were no m ore core developers left . No m ore new t eam s could be form ed. Fort y people rem ained. I f t hey built new funct ionalit y, it would be unusable. We had t hem st art building t est harnesses for t he core, hoping t o m ake it m ore st able.

#4: Accelerators to Recovery Scrum seem s t o have im proved t he product ivit y in m ost part s of developm ent . But it hasn't im proved infrast ruct ure developm ent product ivit y. Since alm ost all of our work involves changing t he infrast ruct ure, how do we im prove product ivit y t here? We m ay not be able t o deliver product s any fast er if w e can't solve t his problem . Many ent erprises already have a dying core. You can figure out how bad t he im pact of t he core on t he ent erprise is by m odeling t he following it em s: •

• •

The cost and t im e needed t o rebuild t he core. ( See t he alt ernat ive approaches present ed next .) The cost and t im e depend on t he skills and availabilit y of exist ing core developers and on t he degradat ion of t he core. They also depend on how good t he rebuilt core has t o be and what velocit y it has t o support . The rapidit y wit h which t he ent erprise is losing m arket share. The t olerance of t he ent erprise's cust om er base t o t he increasingly poor qualit y of it s product s.

The following list det ails several alt ernat ives t o rest ore life t o t he core: •

Rem ediat e t he core. Rest ore t he qualit y t o t he core product . Form new t eam s t o redesign and refact or t he code. Writ e overall design inform at ion t o guide navigat ion in t he code. Develop aut om at ed t est harnesses t hat ensure t he core is working. This approach can be com pared t o rebuilding a house t hat has fallen int o severe disrepair. I t usually is quicker, cheaper, and safer t o t ear it down. Unfort unat ely, as core funct ions are rem ediat ed,

•

•

•

•

you will have t o m ake assum pt ions about how t he new code should work. Many funct ions use t he core and t here rarely is a com plet e invent ory. Because all t he usages are unknown, it m ight be im possible t o devise com plet e funct ional t est s. St rangle t he core. As t he engineers enhance or fix bugs in t he core, allocat e enough t im e for t hem t o rewrit e t hat area wit h a good design and clean, com m ent ed code. Bit by bit , t he new code will st rangle t he design dead code. Rewrit e t he core. Underst and what funct ions t he core perform s. Rewrit e t hem from scrat ch. This approach suffers m any of t he problem s of rem ediat ion. You m ight never know what has been done wrong or not done at all unt il t he cust om ers t ell you. You will also have t o synchronize any int erim changes bet ween t he new and old core. Prop up t he core. Live wit h t he core longer but wit h less dam age. Underst and as m uch funct ionalit y of t he core as possible. You should docum ent as m uch design and m apping as possible. Build aut om at ed t est harnesses around t he core so t hat you will know when it breaks. As any piece of core funct ionalit y needs enhancing, rewrit e it from scrat ch. This approach is bet t er t han t he first t wo, but it is st ill highly risky. Drain t he pond. Rebuild t he core in new t echnology wit h good design and t est harnesses. Rewrit e pieces of core funct ionalit y one at a t im e in t he new t echnology. Move known users of t he core funct ionalit y t o t he new core one by one. Assure t hat each user of t he core funct ionalit y works and t hat t est s are in t he core t est harness. When all known users of a piece of core funct ionalit y are convert ed, t ry t urning off t hat part of t he core. Find t he ot her users, one by one, as t hey com plain.

#5: The Mother of All Problems How did our ent erprise get in t his pickle of a dying core? We have excellent developers. We have a great m arket ing depart m ent . We have good m arket share and are loved by our cust om ers. We are respect ed in t he indust ry. Where did t his com e from , and how did it happen? The m et hods of im proving t he core are expensive, risky, and t im econsum ing. You m ight be shocked. Earlier, in t he sect ion " # 1: Short ening t he Tim e t o Release Through Managing Value," we looked at how you can avoid t he problem . But how and why did it occur originally? We have t o look at our t radit ions and habit s t o fully underst and t his so t hat we don't repeat ourselves.

Most ent erprises init iat e a proj ect by est im at ing t he cost and delivery dat e. Cust om ers provide input by defining everyt hing t hat t hey want done—t he requirem ent s. Each st ep t hereaft er decom poses cust om er requirem ent s int o t he ult im at e product . Changes becom e m ore expensive as t he decom posit ion progresses. I f 60 percent of t he proj ect is com plet e, m any of it s int ernal workings are com plet e. They are int errelat ed and depend on each ot her. A change at t he st art of a proj ect m ight cost one dollar. When t he product is in product ion and has already been shipped, t he sam e change cost s 100 dollars. [ 2] [2]

Barry W. Boehm , Soft ware Engineering Econom ics ( Prent ice Hall, 1981)

An average of 35 percent of t he requirem ent s change during a proj ect . Many of t hese changes occur lat e in t he proj ect . This put s t he cust om er in a bind. Developm ent t ells t hem t hat changes j eopardize t he init ial est im at ed dat es and cost s. The cust om ers want t he changes, but not if t hey cause cost overruns or delivery dat e slippages. Accurat ely predict ing a dat e and t ot al cost at t he st art of a proj ect is very difficult . The sheer com plexit y of t he requirem ent s and t he changes are unpredict able. The vagaries of t he t echnologies em ployed oft en aren't yet known. The people doing t he work cause huge variances bet ween predict ions and act ual result s. This is a dilem m a for cust om ers who have acquired enough funding t o support an expect ed cost and dat e. They expect t o get benefit s on t hat dat e. Cust om ers becom e increasingly frust rat ed as developers resist changes. Proj ect cost s and delivery dat es keep changing, always upwards. Developers are em barrassed t o t ell cust om ers t hat t hings have slipped again because t hey couldn't fit an ever- increasing am ount of work int o t he sam e size dat e/ cost box. A dysfunct ional relat ionship bet ween cust om ers and developers arises. Cust om ers rely on t elling t he developers t o " j ust do it ," while t olerat ing m odest slippage of cost and dat e. The developers t hen have t o do m ore work in less t im e. They cut qualit y so t hat t hey can do m ore work. The result ing funct ionalit y m ight wind up in t he core, m aking t he core harder t o enhance and m aint ain. Fewer enhancem ent s can be planned. Longer developm ent cycles are needed. The ent erprise becom es less com pet it ive. I can t ell whet her an ent erprise is heading t oward a dead core. Decreasing developm ent velocit y is t he first sign. Team s are able t o do less work in t he sam e t im e because of lowered qualit y. A reduced velocit y curve is shown in Figure 9- 4.

Figur e 9 - 4 . Re du ce d de ve lopm e n t ve locit y

You can t rack a core dying. You can see in Figure 9- 4 t hat in t he fift h release of a product , t he velocit y was 18 funct ional requirem ent s ( per $100,000 expended) . The cust om ers and developers developed a baseline plan. The plan port rayed an est im at ed com plet ion dat e. The cust om ers want ed t he release sooner and pressured t he developers t o do what ever it t akes. The developers accom m odat ed t hem by dropping t he qualit y. Wit h lowered qualit y, t he t eam was able m aint ain a short t erm velocit y of 20 funct ional requirem ent s per $100,000. They m et t he dat e. During t he sixt h release, t he developm ent velocit y was only 16. The reduced qualit y from t he fift h release produced product t hat was harder t o change and m ore fragile. Work went m ore slowly. The cust om ers again becam e upset and pressured t he developers t o not let t his slip. The developers dropped qualit y again and achieved a short t erm velocit y of 18. During t he sevent h release, t he baseline velocit y was 14. The developers were having a hard t im e m aking changes and keeping t he core running. Cust om ers felt t hat t he developers m ust really be slacking off. The cust om ers pressured t hem again. This wasn't pleasant , but what could t hey do? Also, t his had worked t he last t wo t im es. So t he developers dropped qualit y again and achieved a short t erm velocit y of 16. The core was get t ing m ore and m ore difficult t o m odify. I t was poorly designed. I t had code slapped on. I t didn't have any organized

st ruct ure. I t didn't follow st andards. You can proj ect t he pat t ern shown in Figure 9- 5. Short - t erm product ivit y in a proj ect is increased by dropping qualit y. As a result , t he core qualit y drops. The next proj ect t akes longer t o do t he sam e work. Under t im e and cost pressures, qualit y is dropped again. Each subsequent release has a lower velocit y. The cust om ers are m ore frust rat ed because of t he lowered velocit y. The pressure t o do m ore is repeat ed. The result is a vicious cycle t hat progressively degrades t he qualit y of t he core. The cust om ers becom e m ore frust rat ed. The developers becom e m ore dissat isfied.

Figur e 9 - 5 . Ve locit y t r e nd cu r ve le a ding t o a de a d cor e

You can see how we have built our ow n dead core—fragile, unt est ed, and wit h fewer developers w orking on it —release by release. Less funct ionalit y can be developed for t he sam e cost in each progressive release. Ent erprises can creat e dead cores wit hin five years. Anot her fact or progressively slows velocit y. As t he product becom es m ore fragile, m ore bugs and defect s are found aft er it is shipped. The developers have t o fix t hese defect s while building t he next release. I ncreasing effort and cost are spent m aint aining each release. This is a double wham m y: t he developers have a m ore difficult product t o enhance, and t hey also have less t im e t o do t he enhancem ent s. Cust om er anxiet y furt her increases. Cust om ers increase t he pressure for developers t o do m ore and speed down t he slippery slope. Figure 9- 6 depict s t he m aint enance curve for a dead core. Maint enance is reasonable at first , but wit h each progressive poor qualit y release, it increases. A m aint enance curve such as t hat shown in Figure 9- 7 presages a dead core. We can suspect t hat t he ent erprise

also has t he decreased velocit y curve of Figure 9- 5. We can be sure t hat t he ent erprise em bodies a dysfunct ional relat ionship bet ween cust om ers and developers.

Figur e 9 - 6 . M a int e n a nce cost cur ve

What are t he com pet it ive consequences t o t he ent erprise? I graphed t he velocit y of enhancing core funct ionalit y at several ent erprises. I t hen graphed t he velocit y of building new funct ionalit y. The graph looked like Figure 9- 7.

Figur e 9 - 7 . Ve locit y of cor e fun ct iona lit y a n d n e w fun ct iona lit y

I n Figure 9- 7, t he velocit y for new funct ionalit y averages 20 pieces of funct ionalit y per $100,000. The velocit y for core funct ionalit y averages 1 piece of funct ionalit y per $100,000. All new developm ent could be const rained t o t he velocit y of core developm ent . To rem ove t he const raint , we usually can increase t he num ber of core developers. Unfort unat ely, very few people in an ent erprise know how t o work on t he core. There aren't any m ore people t hat we can add t o t he core t eam . Once, when t his wasn't recognized, t he core t eam was increased from eight t o over 100. The core velocit y dropped rat her t han increased because t he original eight infrast ruct ure developers had t o cope wit h t he ot her 100 people. A dead core is not good for an ent erprise. Com pet it ion can quickly int roduce new, com pelling funct ionalit y and t he ent erprise wit h t he dead core can't respond. As we wat ch ent erprises t oday, we can easily nam e Com pany A and B. Com pany A's prim ary product is an I nt ernet port al. This com pany is driving all of it s com pet it ors m ad. I t frequent ly int roduces sophist icat ed new funct ionalit y. None of it s com pet it ors can m at ch it s speed of int roduct ion. I have worked at Com pany A and at it s com pet it ors. Com pany A isn't bet t er. I t s engineers are no sm art er. However, Com pany A is relat ively new and it s code base is st ill clean. I t s com pet it ors have been in business longer. Their code bases are close t o dead. Unfort unat ely, Com pany A is arrogant . I t believes it com pet es bet t er because it is bet t er. Based on m y work at Com pany A, I give it anot her four years before it s core is alm ost dead. This is also t rue in t he insurance indust ry. One insurance com pany, Com pany B, is rapidly t aking m arket share from old- line com panies. I t rapidly int roduces new insurance product s. The ot her com panies can't respond. Com pany B has a new code base. I t also religiously uses Agile t echniques t o ret ain t he qualit y of t he code base. The healt h of an ent erprise rides on resolving t his problem . The root of t he change is t he relat ionship bet ween product m anagem ent and t he developm ent organizat ion.

Part III: Appendices • • • • •

Appendix Appendix Appendix Appendix Appendix

A, " Scrum 1, 2, 3" B, " More About Scrum " C, " Exam ple Scrum Kickoff Meet ing Agenda" D, " I nit ial Ent erprise Transit ion Product Backlog" E, " Scrum Musings"

Appendix A. Scrum 1, 2, 3 I n t his chapt er: The Science

101

Scrum : Skelet on and Heart

105

Scrum : Roles

106

Scrum : Flow

106

Scrum : Art ifact s

109

This appendix sum m arizes Scrum . Scrum is devised specifically t o wrest usable product s from com plex problem s. I t has been used successfully on t housands of proj ect s in hundreds of organizat ions over t he last 16 years. I t is based in indust rial process cont rol t heory, whose m echanism s have been used t o creat e com plex product s successfully since t im e began. I ndust rial process cont rol t heory em ploys em pirical processes t hat depend on such lit t le- underst ood m echanism s as self- organizat ion and em ergence.

The Science Product developm ent is a com plex endeavor. This isn't unusual because t he universe is full of com plexit y. Most com plexit ies we don't know about ; ot hers we are cont ent t o leave alone. Som e, like pressure t urning coal int o diam onds, t ake care of t hem selves. And ot hers we can use wit h a level of im precision such t hat t he com plexit y doesn't m at t er, such as firing a rocket t o Mars. However, it is im possible t o ignore t he com plexit y in soft ware developm ent . I t s result s are ephem eral, consist ing of signals t hat cont rol m achines. The process is ent irely int ellect ual, wit h all int erm ediat e product s being m arginal represent at ions of t he t hought s involved. The m at erials t hat we use t o creat e t he end product are ext rem ely volat ile: user requirem ent s of what t he users have yet t o see, t he int eroperat ion of t he signals of ot her program s wit h our program s, and t he int eract ions of t he m ost com plex processes yet —a t eam of people working t oget her. Because soft ware developm ent is a com plex process, t here is no short age of com plexit ies, and t here is no panacea for t hem ot her t han hard work, int elligence, and courage. Scrum is not for t hose who seek easy answers and sim ple solut ions t o com plex problem s; it is for t hose

who underst and t hat com plex problem s can only be m et head on wit h det erm inat ion and wit . Appendix A describes how em pirical processes are used t o cont rol com plex processes, and how Scrum em ploys t hese em pirical processes t o cont rol product developm ent proj ect s. When I say cont rol, I don't m ean cont rol t o creat e what we predict . I m ean t hat we will cont rol t he process t o guide t he work t oward t he m ost valuable out com e possible.

Empirical Process Control Com plex problem s are t hose t hat behave unpredict ably, and t he unpredict able m anner in which t hey behave is unpredict able. St at ed anot her way, a st at ist ical sam ple of t he operat ion of t hese processes will never yield a m eaningful insight int o t heir underlying m at hem at ical m odel, and at t em pt s at form ing m eaningful insight can only be m ade by sum m arizing t heir operat ion t o such a degree of coarseness as t o be irrelevant t o underst anding or m anaging t hem . Much of our societ y is based on processes t hat work only because t heir degree of im precision is accept able. Wheels wobble, cylinders shake, brakes j it t er—but all at a level t hat doesn't m eaningfully im pede our use of a car. When we build cars, we fit part s t oget her wit h a degree of precision fit for t he purpose and accept able t o t he eye. We can m anage m any processes because t he accuracy of t he result s is lim it ed by our physical percept ions. When I build a cabinet , t he m at erials need t o be cut and j oined wit h a precision accept able t o t he hum an eye and suit able for a relat ively st at ic daily life. What happens when we are building som et hing t hat requires a higher degree of precision t han t hat obt ainable t hrough averaging? What happens if any process t hat we devise for building cars is t oo im precise for our cust om ers, and we need t o increase t he level of precision? I n t hose cases, we have t o guide t he process st ep by st ep ourselves, ensuring t hat t he process converges on an accept able degree of precision. When t he convergence isn't occurring, we have t o m ake adapt at ions t o bring t he process back int o accept able t olerances. Laying out a process t hat will produce accept able qualit y out put over and over again is called defined process cont rol. When defined process cont rol cannot be achieved because of t he com plexit y of t he int erm ediat e act ivit ies, som et hing called em pirical process cont rol has t o be em ployed.

" I t is t ypical t o adopt t he defined ( t heoret ical) m odeling approach when t he underlying m echanism s by which a process operat es are reasonably well underst ood. When t he process is t oo com plicat ed for t he defined approach, t he em pirical approach is t he appropriat e choice." —Babat unde A. Ogunnaike and W. Harm on Ray Process Dynam ics, Modeling, and Cont rol ( Oxford Univ. Press, 1994) We t ry t o use defined processes whenever possible, because wit h t hem we can crank up unat t ended product ion t o such a quant it y t hat t he out put can be priced as a com m odit y. However, if t he com m odit y is of such unaccept able qualit y as t o be unusable, if t he rework is t oo great t o m ake t he price accept able, or if t he cost of unaccept ably low yields is t oo high, we have t o t urn t o and accept t he higher cost s of em pirical process cont rol. I n t he long run, m aking successful product s t he first t im e using em pirical process cont rol has t urned out t o be m uch cheaper t han reworking m any unsuccessful product s using defined process cont rol. Em pirical process cont rol has t hree legs underlying all of it s im plem ent at ions: t ransparency, inspect ion, and adapt at ion. Transparency m eans t hat t he aspect s of t he process t hat affect t he out com e m ust be visible t o t hose cont rolling t he process. Not only m ust t hese aspect s be t ransparent , but also what is being seen m ust be known. That is, when som eone inspect ing a process believes t hat som et hing is done, it m ust be equivalent t o t heir definit ion of " done." I n product developm ent , assert ing t hat funct ionalit y is done m ight lead som eone t o assum e t hat it is cleanly coded, refact ored, unit t est ed, built , and accept ance t est ed. Som eone else m ight assum e only t hat t he code has been built . I f everyone doesn't know what t he definit ion of " done" is, t he ot her t wo legs of em pirical process cont rol don't work. When som eone describes som et hing as " done," everyone m ust underst and what " done" m eans. The second leg is inspect ion. The various aspect s of t he process m ust be inspect ed frequent ly enough so t hat unaccept able variances in t he process can be det ect ed. The frequency of inspect ion has t o t ake int o considerat ion t hat all processes are changed by t he act of inspect ion. A conundrum occurs when t he required frequency of inspect ion exceeds t he t olerance t o inspect ion of t he process. Fort unat ely, t his doesn't seem t o be t rue of soft ware developm ent . The ot her fact or in inspect ion is t he inspect or. The inspect or m ust possess t he skills t o assess what he or she is inspect ing.

The t hird leg of em pirical process cont rol is adapt at ion. I f t he inspect or det erm ines from t he inspect ion t hat one or m ore aspect s of t he process are out side accept able lim it s and t hat t he result ing product will be unaccept able, t he inspect or m ust adj ust t he process or t he m at erial being processed. The adj ust m ent m ust be m ade as quickly as possible t o m inim ize furt her deviat ion. An exam ple of an em pirical process cont rol is a code review. The code is reviewed against coding st andards and indust ry best pract ices. Everyone involved in t he review fully and m ut ually underst ands t hese st andards and best pract ices. The code review occurs whenever som eone feels t hat a sect ion of code is com plet e. The m ost experienced developers review t he code, and t heir com m ent s and suggest ions lead t o t he developer adj ust ing his or her code.

Complex Software Development When we build soft ware, we are building a logical set of inst ruct ions t hat send signals t hat cont rol a m achine in it s int eract ions wit h ot her m achines, hum ans, or nat ure. The level of precision required for successful soft ware ranges from t he incredible t o t he t ruly daunt ing. Anyt hing can be com plex. When com plex t hings int eract , t he level of com plexit y increases t rem endously. I 've lim it ed m y enum erat ion of com plexit y in soft w are developm ent t o t he t hree m ost significant dim ensions: requirem ent s, t echnology, and people. Sim ple soft ware requirem ent s can happen. A single cust om er who is t he only person who will use t he syst em can spend so m uch t im e wit h m e t hat I firm ly believe t hat I underst and what he or she want s. I f t his cust om er t hen im m ediat ely dies, t he requirem ent s are st able and sim ple. No changes, no revisions, no last - m inut e m odificat ions. A m ore com m on sit uat ion is when t here are m any cust om ers or st akeholders ( t hose wit h an int erest in t he soft ware and how it works) who have different needs t hat change and are difficult t o art iculat e. I n m ost cases, t hese cust om ers really st art t o underst and what t hey want only when you provide t hem wit h what you and t hey t hink t hey want . These are com plex requirem ent s because t hey are not only am biguous, but t hey are t ent at ive and const ant ly changing. Sim ple t echnology exist s, but it is rarely used in soft ware developm ent . One could define soft ware developm ent proj ect s as t he applicat ion of advanced, not necessarily 100- percent reliable, t echnology t o solve business problem s for com pet it ive advant age. To com pound t he com plexit y of t echnology, m ore t han one piece is

usually em ployed and t he int erfaces of t he m any are far m ore com plex t han t he com plexit y wit hin any single piece. I n Figure A- 1, t he vert ical axis t races requirem ent s com plexit y and t he horizont al axis t races t echnology com plexit y. The int ersect ion of t hese com plexit ies defines t he level of com plexit y of t he proj ect . Alm ost all current soft ware developm ent proj ect s are com plex. Those t hat are chaot ic are unworkable, and som e com plexit ies m ust be resolved prior t o st art ing t he proj ect .

Figur e A- 1 . Com ple x it y a sse ssm e n t gr a ph

The t hird dim ension is t he people developing t he soft ware. They all have different skills, int elligence, experience, viewpoint s, at t it udes, and prej udices. Every m orning when t hey wake up, each has a different m ood from t he prior day, depending on his or her sleep, healt h, weat her, neighbors, fam ilies, and what is ant icipat ed from t he day ahead. Then t hese people st art t o work t oget her, and t he com plexit y goes t hrough t he roof. When t he t hird dim ension of people com plexit y is fact ored in wit h t he ot her t wo dim ensions of requirem ent s and t echnology, t he com plexit y increases even m ore. I believe t hat t he last " sim ple" proj ect occurred in 1969 when one person from order processing at Sears Roebuck asked m e t o sort som e cards and generat e a report on an I BM 360/ 20. Since t hen, t he com plexit y of soft ware developm ent proj ect s has only got t en m essier.

Scrum addresses t he com plexit y of soft ware developm ent proj ect s by im plem ent ing t he inspect ion, adapt at ion, and visibilit y requirem ent s of em pirical process cont rol in a set of sim ple pract ices and rules. These are described in t he following sect ions.

Scrum: Skeleton and Heart Scrum em ploys an it erat ive, increm ent al process skelet on on which hang all of it s pract ices. Scrum 's skelet on is shown in Figure A- 2. The lower circle represent s an it erat ion of developm ent act ivit ies t hat occur, one aft er anot her. The out put of each it erat ion is an increm ent of product . The upper circle represent s t he daily inspect ion t hat occurs during t he it erat ion, where t he individual t eam m em bers m eet t o inspect each ot her's act ivit ies and m ake appropriat e adapt at ions. Driving t he it erat ion is a list of requirem ent s. This cycle repeat s unt il t he proj ect is no longer funded.

Figur e A- 2 . Scr um sk e le t on

The skelet on operat es t his way: At t he st art of an it erat ion, t he t eam reviews w hat it m ust do. Then it select s what it believes it can t urn int o an increm ent of pot ent ially shippable funct ionalit y by t he end of t he it erat ion. The t eam is t hen left alone t o m ake it s best effort for t he

rest of t he it erat ion. At t he end of t he it erat ion, t he t eam present s t he increm ent of funct ionalit y t hat it built so t hat t he st akeholders can inspect it and m ake t im ely adapt at ions t o t he proj ect . The heart of Scrum occurs wit hin t he it erat ion. The t eam t akes a look at t he requirem ent s and t he t echnology, and evaluat es each ot her's skills and capabilit ies. The t eam t hen collect ively devises t he best way it knows t o build t he funct ionalit y, m odifying t he approach daily as it encount ers new com plexit ies, difficult ies, and surprises. The t eam figures out what needs t o be done and det erm ines t he best way t o do it . This creat ive process is t he heart of t he Scrum 's product ivit y. Scrum im plem ent s t his it erat ive, increm ent al skelet on t hrough t hree roles. I 'll provide a quick overview of t hese people operat ing wit hin t he Scrum process. Then I 'll describe t he Scrum art ifact s t hey use in m ore det ail.

Scrum: Roles There are only t hree Scrum roles: t he Product Owner, t he t eam , and t he Scrum Mast er. All m anagem ent responsibilit ies in a proj ect are divided bet ween t hese t hree roles. The Product Owner is responsible for represent ing t he int erest s of everyone wit h a st ake in t he proj ect and it s result ing product . The Product Owner achieves init ial and ongoing funding for t he proj ect by creat ing t he proj ect 's init ial overall requirem ent s, ret urn on invest m ent obj ect ives, and release plans. The list of requirem ent s is called t he Product Backlog. The Product Owner is responsible for using t he Product Backlog t o ensure t hat t he m ost valuable funct ionalit y is produced first and built upon; t his is achieved by frequent ly priorit izing t he Product Backlog t o queue up t he m ost valuable requirem ent s for t he next it erat ion. The t eam is responsible for developing funct ionalit y. Team s are selfm anaging, self- organizing, and cross- funct ional. A t eam is responsible for figuring out how t o t urn Product Backlog int o an increm ent of funct ionalit y wit hin an it erat ion, and for m anaging it s own work t o do so. The t eam m em bers are collect ively responsible for t he success of each it erat ion and t he proj ect . The Scrum Mast er is responsible for t he Scrum process, for t eaching it t o everyone involved in t he proj ect , for im plem ent ing it so t hat it fit s

wit hin an organizat ion's cult ure and st ill delivers t he expect ed benefit s, and for ensuring t hat everyone follows it s rules and pract ices.

Scrum: Flow A Scrum proj ect st art s wit h a vision of t he syst em and a sim ple baseline plan of cost and t im e fram es. The vision m ight be vague at first , st at ed in m arket t erm s rat her t han product t erm s. The vision will becom e clearer as t he proj ect m oves forward. The Product Owner is responsible t o t hose funding t he proj ect t o deliver t he vision in a m anner t hat m axim izes t heir ret urn on invest m ent . The Product Owner form ulat es a plan for doing so, which includes a Product Backlog. The Product Backlog is a list of funct ional and nonfunct ional requirem ent s t hat , when t urned int o funct ionalit y, will deliver t his vision. The Product Backlog is priorit ized so t hat t he it em s m ost likely t o generat e value are t he t op priorit y. The Product Backlog is divided int o proposed releases. This is a st art ing point , and t he cont ent s, priorit ies, and grouping of t he Product Backlog int o releases is expect ed t o and usually does change t he m om ent t he proj ect st art s. Changes in t he Product Backlog reflect changing business requirem ent s and how quickly or slowly t he t eam can t ransform Product Backlog int o funct ionalit y. All work is done in Sprint s. Each Sprint is an it erat ion of one m ont h. Each Sprint is init iat ed wit h a Sprint Planning m eet ing, where t he Product Owner and t eam get t oget her t o collaborat e about what will be done for t he next Sprint . Select ing from t he highest priorit y Product Backlog, t he Product Owner t ells t he t eam what is desired, and t he t eam t ells t he Product Owner how m uch of what is desired it believes it can t urn int o funct ionalit y over t he next Sprint . Sprint Planning m eet ings cannot last longer t han eight hours. They are t im e- boxed t o avoid t oo m uch handwringing about what is possible. The goal is t o get t o work, not t o t hink about working. The Sprint Planning m eet ing has t wo part s. The first four hours are spent wit h t he Product Owner present ing t he highest priorit y Product Backlog t o t he t eam . The t eam quest ions him or her about t he cont ent , purpose, m eaning, and int ent ions of t he Product Backlog. When t he t eam knows enough, but before t he first four hours elapse, t he t eam select s as m uch Product Backlog as it believes t hat it can t urn int o a com plet ed increm ent of pot ent ially shippable product funct ionalit y by t he end of t he Sprint . The t eam com m it s t o t he Product Owner t o do it s best t o com plet e t hat am ount of funct ionalit y.

During t he second four hours of t he Sprint Planning m eet ing, t he t eam plans out t he Sprint . I t creat es a design wit hin which t he work can be done. Because t he t eam is responsible for m anaging it s own work, it needs a t ent at ive plan t o st art t he Sprint . The t asks t hat t his plan is com posed of are placed in a Sprint Backlog; t he t asks in t he Sprint Backlog em erge as t he Sprint evolves. At t he st art of t he second fourhour period of t he Sprint Planning m eet ing, t he Sprint has st art ed and t he clock is t icking t oward t he m ont h- long Sprint t im e- box. Every day t he t eam get s t oget her for a 15- m inut e m eet ing called a Daily Scrum . At t he Daily Scrum , each t eam m em ber answers t hree quest ions: • • •

What have you done on t his proj ect since t he last Daily Scrum m eet ing? What do you plan t o do on t his proj ect bet ween now and t he next Daily Scrum m eet ing? What im pedim ent s are in t he way of you m eet ing your com m it m ent s t oward t his Sprint and t his proj ect ?

The purpose of t he m eet ing is t o synchronize t he work of all t eam m em bers daily and t o schedule any m eet ings t hat t he t eam needs t o forward it s progress. The t eam m em bers are inspect ing each ot her's work in light of t he t eam 's com m it m ent s, and m aking adapt at ions t o opt im ize t heir chance of m eet ing t hose com m it m ent s. At t he end of t he Sprint , a Sprint Review m eet ing is held. This is a four- hour t im e- boxed m eet ing at which t he t eam present s what has been developed during t he Sprint t o t he Product Owner and any ot her st akeholders t hat wish t o at t end. This is an inform al m eet ing, wit h t he present at ion of t he funct ionalit y int ended t o fost er collaborat ion about what t o do next based on what t he t eam j ust com plet ed. The Product Owner and st akeholder inspect t he t eam 's work in light of proj ect s goals, and t hey m ake adapt at ions t o opt im ize t heir chance of reaching t hose goals. Aft er t he Sprint Review and prior t o t he next Sprint Planning m eet ing, t he Scrum Mast er holds a Sprint Ret rospect ive m eet ing wit h t he t eam . At t his t hree- hour, t im e- boxed m eet ing, t he Scrum Mast er encourages t he t eam t o revise, wit hin t he Scrum process fram ework and pract ices,

it s developm ent process t o m ake it m ore effect ive and enj oyable for t he next Sprint . Collect ively, t he Sprint Planning m eet ing, t he Daily Scrum m eet ing, t he Sprint Review m eet ing, and t he Sprint Ret rospect ive m eet ing im plem ent t he em pirical inspect ion and adapt at ion pract ices wit hin Scrum . Figure A- 3 provides an illust rat ion of t he overall process.

Figur e A- 3 . Scr um pr oce ss ove r vie w

Scrum : Art ifact s Scrum int roduces a few new art ifact s. These are used t hroughout Scrum and are int roduced in t he following sect ions. Product Backlog The requirem ent s for t he product being developed by t he proj ect or proj ect s are list ed in t he Product Backlog. The Product Owner is responsible for t he Product Backlog, it s cont ent s, it s availabilit y, and it s priorit izat ion. Product Backlog is never com plet e, and t he Product Backlog in t he proj ect plan only lays out t he init ially known and best underst ood requirem ent s. The Product Backlog evolves as t he product and t he environm ent in which it will be used em erge. Product Backlog is dynam ic, in t hat m anagem ent const ant ly changes it t o ident ify what t he product needs t o be appropriat e, com pet it ive, and useful. As long as a product exist s, Product Backlog also exist s. An exam ple of Product Backlog m aint ained on t he Scrum Product Managem ent t ool, based in a spreadsheet , is shown in Figure A- 4.

Figur e A- 4 . Pr odu ct Ba ck log Backlog Descript ion

I nit ial Est im at e

Adj ust m en t Fact or

Adj ust e d Est im at e

Tit le I m port

Hours of work rem aining unt il com plet ion

1

2

3

4

5

6

7

25 6

20 9

19 3

14 0

14 0

14 0

14 0

Proj ect select ion or new

3

0.2

3.6

3.6

0

0

0

0

0

0

Tem plat e Backlog for new proj ect s

2

0.2

2.4

2.4

0

0

0

0

0

0

Creat e Product Backlog worksheet wit h form at t ing

3

0.2

3.6

3.6

0

0

0

0

0

0

Creat e Sprint Backlog worksheet wit h

3

0.2

3.6

3.6

0

0

0

0

0

0

Backlog Descript ion

I nit ial Est im at e

Adj ust m en t Fact or

Adj ust e d Est im at e

Tit le I m port

Hours of work rem aining unt il com plet ion

1

2

3

4

5

6

7

25 6

20 9

19 3

14 0

14 0

14 0

14 0

form at t ing Display t ree view of Product Backlog, Releases, Sprint s

2

0.2

2.4

2.4

0

0

0

0

0

0

Sprint - 1

13

0.2

15.6

16

0

0

0

0

0

0

Creat e a new window cont aining Product Backlog t em plat e

3

0.2

3.6

3.6

3.6

0

0

0

0

0

Creat e a new window cont aining Sprint Backlog t em plat e

2

0.2

2.4

2.4

2.4

0

0

0

0

0

Burndown window of Product Backlog

5

0.2

6

6

6

0

0

0

0

0

Burndown window of Sprint Backlog

1

0.2

1.2

1.2

1.2

0

0

0

0

0

Display t ree view of Product Backlog, Releases, Sprint s

2

0.2

2.4

2.4

2.4

0

0

0

0

0

Display burndown for select ed Sprint or Release

3

0.2

3.6

3.6

3.6

0

0

0

0

0

Sprint - 2

16

0.2

19.2

19

19

1.2

0

0

0

0

Aut om at ic recalculat ing of

3

0.2

3.6

3.6

3.6

3.6

0

0

0

0

Backlog Descript ion

I nit ial Est im at e

Adj ust m en t Fact or

Adj ust e d Est im at e

Tit le I m port

Hours of work rem aining unt il com plet ion

1

2

3

4

5

6

7

25 6

20 9

19 3

14 0

14 0

14 0

14 0

values and t ot als As changes are 2 m ade t o Backlog in secondary window, updat e burndown graph on m ain page

0.2

2.4

2.4

2.4

2.4

0

0

0

0

Hide/ aut om at ic redisplay of burndown window

3

0.2

3.6

3.6

3.6

3.6

0

0

0

0

I nsert Sprint capabilit y ... adds sum m ing Sprint row

2

0.2

2.4

2.4

2.4

2.4

0

0

0

0

I nsert Release capabilit y adds sum m ary row for Backlog in Sprint

1

0.2

1.2

1.2

1.2

1.2

0

0

0

0

Owner/ assigne 2 d capabilit y and colum ns opt ional

0.2

2.4

2.4

2.4

2.4

0

0

0

0

Print burndown graphs

1

0.2

1.2

1.2

1.2

1.2

0

0

0

0

Sprint - 3

14

0.2

16.8

17

17

17

0

0

0

0

Duplicat e 5 incom plet e Backlog wit hout affect ing t ot als

0.2

6

6

6

6

6

6

6

6

Not e capabilit y

0.2

7.2

7.2

7.2

7.2

7.2

7.2

7.2

7.2

0.2

18

18

18

18

18

18

18

18

6

What - if Release 15 capabilit y on

Backlog Descript ion

I nit ial Est im at e

Adj ust m en t Fact or

Adj ust e d Est im at e

Tit le I m port

Hours of work rem aining unt il com plet ion

1

2

3

4

5

6

7

25 6

20 9

19 3

14 0

14 0

14 0

14 0

burndown graph Trend capabilit y on burndown window

2

0.2

2.4

2.4

2.4

2.4

2.4

2.4

2.4

2.4

Publish facilit y for ent ire proj ect , publishing it as HTML Web pages

11

0.2

13.2

0

0

13

13

13

13

13

Fut ure Sprint s

39

0.2

46.8

34

34

47

47

47

47

47

85

70

65

47

47

47

47

Release- 1

This spreadsheet is t he Product Backlog in March 2003, from a proj ect for developing t he Scrum Proj ect Managem ent soft ware. I was t he Product Owner. The rows are t he Product Backlog it em s, int erspersed by Sprint and Release dividers. For inst ance, all t he rows above Sprint 1 were w orked on in t hat Sprint . The rows bet ween Sprint 1 and Sprint 2 rows w ere done in Sprint 2. Not ice t hat t he row " Display t ree view of Product Backlog, Releases, Sprint s" is duplicat ed in Sprint 1 and Sprint 2. This is because row 10 wasn't com plet ed in Sprint 1, so it was m oved down t o t he Sprint 2 for com plet ion. I f I decided t hat it was a lower priorit y aft er Sprint 1, I could have m oved it even lower down t he priorit y list . The first four colum ns are t he Product Backlog it em nam e, init ial est im at e, com plexit y fact or, and adj ust ed est im at e. The com plexit y fact or increases t he est im at e because of proj ect charact erist ics t hat reduce t he product ivit y of t he t eam . The next colum ns are t he Sprint s during which t he Product Backlog is developed. When t he Product Backlog is first t hought of and ent ered, it s est im at ed work is placed int o t he colum n of t he Sprint t hat is going on at t hat t im e. The developers and I devised m ost of t he backlog it em s shown before st art ing t his proj ect . The sole except ion is row 31 ( " Publish facilit y for

ent ire proj ect , publishing it as HTML Web pages" ) , which I didn't t hink of unt il som e t im e during Sprint 3. A burn- down chart shows t he am ount of work rem aining across t im e. The burn- down chart is an excellent way of visualizing t he correlat ion bet ween t he am ount of work rem aining at any point in t im e and t he progress of t he proj ect t eam or t eam s in reducing t his work. The int ersect ion of a t rend line for work rem aining and t he horizont al axis indicat es t he m ost probable com plet ion of work at t hat point in t im e. A burn- down chart reflect ing t his is show n in Figure A- 5. The burn- down chart helps m e t o " what if" t he proj ect by adding and rem oving funct ionalit y from t he release t o get a m ore accept able dat e, or by ext ending t he dat e t o include m ore funct ionalit y. The burn- down chart is t he collision of realit y ( work done and how fast it 's being done) wit h what is planned, or hoped for. Figure A- 5. Burn- down chart

The it em s in t he Product Backlog for fut ure Sprint s are pret t y coarse grained. The Product Owner hasn't had t he t eam st art t o w ork on t hese it em s, so he or she hasn't expended t he t im e t o analyze t hem t o m ore finely est im at e t hem . Sim ilarly, t here are plent y m ore requirem ent s for t his product . They j ust haven't been t hought t hrough. This is an exam ple of t he requirem ent s for t he product em erging. I can defer building an invent ory of Product Backlog unt il I am ready t o engage a t eam t o convert it int o funct ionalit y. Sprint Backlog The Sprint Backlog defines t he work, or t asks, t hat a t eam has specified for t urning t he Product Backlog it select ed for t hat Sprint int o an increm ent of pot ent ially shippable product funct ionalit y. The t eam com piles an init ial list of t hese t asks in t he second part of t he Sprint

Planning m eet ing. Tasks should have enough det ail so t hat each t ask t akes roughly 4 t o 16 hours t o finish. Tasks t hat are of longer est im at ed t im e are used as placeholders for t asks t hat haven't been finely defined. Only t he t eam can change t he Sprint Backlog. The Sprint Backlog is a highly visible, real- t im e pict ure of t he w ork t hat t he t eam plans t o accom plish during t he Sprint . An exam ple of a Sprint Backlog is shown in Figure A- 6. The rows represent Sprint Backlog t asks. The colum ns on t he right , labeled " Hours of Work," cont ain t he rem aining hours of work for t he various days of t he Sprint . Once a t ask is defined, t he est im at ed num ber of hours rem aining t o com plet e t he t ask is placed in t he int ersect ion of t he t ask and t he Sprint day by t he person working on t he t ask.

Figur e A- 6 . Spr in t Ba ck log Task Descript ion

Hours of work rem aining unt il com plet ion Origi Respon St at us ( Not nat o sible St art ed/ I n r Progress/ C om plet ed) 1

2

3

4

5

6

7

8

9

10 11 12

Meet t o discuss t he goals and feat ures for Sprint 3- 6

Dani Daniell elle e/ Sue

Com plet ed 20 0

0

0

0

0

0

0

0

0

0

0

Move Calculat ions out of Cryst al Report s

Jim

Allen

Not St art ed

8

8

8

8

8

8

8

8

8

8

8

Get KEG Dat a

Tom

Com plet ed 12 0

0

0

0

0

0

0

0

0

0

0

Analyse KEG Dat a - Tit le

George I n Progress

Analyse KEG Dat a - Parcel

Tim

Com plet ed 12 12 12 12 12 4

4

Analyse KEG Dat a Encum brance

Josh

In Progress

12 10 10 10 10 10

Analyse KEG Dat a Cont act

Daniell e

In Progress

24 24 24 24 12 10 8

Analyse KEG

Allen

In

24 24 24 24 12 10 10 10 10 10 10 10

8

24 24 24 24 12 10 10 10 10 10 10 10 4

6

0

6

0

6

0

6

0

6

Task Descript ion

Hours of work rem aining unt il com plet ion Origi Respon St at us ( Not nat o sible St art ed/ I n r Progress/ C om plet ed) 1

Dat a Facilit ies

2

3

4

5

6

7

8

9

10 11 12

Progress

Define & build Dat abase

Barry/ Dave

In Progress

Validat e t he size of t he KEG dat abase

Tim

Not St art ed

Look at KEG Dat a on t he G: \

Dave

In Progress

Confirm Agreem ent wit h KEG

Sue

Not St art ed

Confirm KEG St aff Availabilit y

Tom

Swit ch JDK t o 1.3.1. Run all t est s.

Allen

80 80 80 80 80 80 60 60 60 60 60 60

3

3

3

3

3

3

3

3

3

3

3

3

Not St art ed

1

1

1

1

1

1

1

1

1

1

1

1

Not St art ed

8

8

8

8

8

8

8

8

8

8

8

8

St ore PDF files in a st ruct ure

Jacquie Com plet ed 8

0

0

0

0

0

0

0

0

0

0

0

TopLink. Cannot get rid of net scape parser

Richard Com plet ed 4

0

0

0

0

0

0

0

0

0

0

0

Build t est dat a reposit ory

Barry

10 10 10 10 10 10 10 10 8

8

8

8

Move applicat ion and dat abase t o Qual ( incl Cryst al)

Richard Com plet ed 4

4

4

4

4

4

4

0

0

0

0

0

Set up Cryst al environm ent

Josh

Com plet ed 2

2

2

2

1

1

1

0

0

0

0

0

Test App in Qual

Sue

In Progress

In Progress

20

Task Descript ion

Hours of work rem aining unt il com plet ion Origi Respon St at us ( Not nat o sible St art ed/ I n r Progress/ C om plet ed) 1

2

3

4

5

6

7

8

9

10 11 12

Defining sprint goal required for solut ion in 2002

Lynne

In Progress

Reference t ables for im port process

Josh

In Progress

Build st andard im port except ion process

Josh

In Progress

Handle m ult iple file im port s on sam e page

Jacquie Disregarde 20 15 15 15 12 12 12 12 9 d

0

0

0

Migrat e CruiseCont rol Servlet t o iWS 6.0 ( landcc_7101) server

Allen

Not St art ed

4

4

4

4

4

4

4

4

4

4

4

4

Creat e web server for Qual on PF1D8

Allen

Com plet ed 1

0

0

0

0

0

0

0

0

0

0

0

LTCS Disk

Daniell e/ Geor ge

In Progress

12 12 12 12 8

8

8

8

8

8

8

8

Daniell e

Com plet ed 10 10 10 10 10 8

8

0

0

0

0

0

Follow t hru wit h quest ions about KEG dat a t o Sue/ Tom , re: Keg, LTO

Jacq uie

Map KEG dat a Jacq t o Act ive uie

Jacquie I n / Allen Progress

40 40 40 40 40 40 40 38 38 38 38 38

12 12 12 10

50 50 50 50 50 50 50 50 50 50 50 50

Task Descript ion

Hours of work rem aining unt il com plet ion Origi Respon St at us ( Not nat o sible St art ed/ I n r Progress/ C om plet ed) 1

2

3

4

5

6

7

8

9

10 11 12

Tables - see also # 14 Prepare SQL t o im port from KEG t ables t o Act ive Tables

Jacq uie

George I n Progress

25 25 25 25 25 25 25 25 25 24 23 22

I ncrem ent of Pot ent ially Shippable Product Funct ionalit y Scrum requires t eam s t o build an increm ent of product funct ionalit y every Sprint . This increm ent m ust be pot ent ially shippable, because t he Product Owner m ight choose t o im m ediat ely im plem ent t he funct ionalit y. This requires t he increm ent t o consist of t horoughly t est ed, well- st ruct ured, and well- writ t en code t hat has been built int o an execut able. I t also requires t he user operat ion of t he funct ionalit y t o be docum ent ed, eit her in Help files or user docum ent at ion. This is t he definit ion of a " done" increm ent . I t t akes som e developm ent organizat ions a while t o be capable of building som et hing t his " done."

Appendix B. More About Scrum I n t his chapt er: Scrum Term inology

113

Scrum and Agile Books

117

Scrum and Agile Web Sit es 118

This appendix cont ains a glossary of key t erm s used t o describe m echanism s and com ponent s of t he Scrum process, as w ell as addit ional resources you can consult t o broaden your knowledge of Scrum .

Scrum Terminology Som e t erm inology is used t hroughout t his book. I f you are new t o Scrum and t his t erm inology is unfam iliar, paper- clip t his page so t hat you can easily refer t o t hese t erm s. • • •

•

adapt at ion Reconst it ut ing and repriorit izing t he Product Backlog at t he end of a Sprint aft er considering t he result s of an inspect ion and changes in st akeholder needs. cross- funct ional t eam s A self- m anaging t eam t hat has all t he necessary skills t o creat e a " done" increm ent . Daily Scrum A daily m eet ing at which t he Scrum Developm ent Team gat hers t o inspect it s progress t oward t he Sprint Goal and adapt it s work t o opt im ize it s chances of building everyt hing it com m it t ed t o. The m eet ing is t im e- boxed t o 15 m inut es, during which each t eam m em ber answers t he following t hree quest ions: " What did I do yest erday?" , " What am I going t o do t oday?" , and " I s t here anyt hing im peding m y work?" The Sprint Backlog is updat ed before t he end of t he m eet ing t o reflect t he answers t hat t eam m em bers give t o t hese quest ions. done ( Sprint ) As in, " This is what we did in t his Sprint ." The t erm defines t he cont ent s of an increm ent and can vary. For exam ple, som e product s do not cont ain docum ent at ion, so t he definit ion of " done" does not include docum ent at ion. Som e organizat ions are incapable of building a com plet e piece of t he product wit hin one Sprint , so " done" act ually describes som et hing t hat is incom plet e, but nevert heless it is consist ent ly defined across all Sprit s and all t eam s Sprint ing. This approach works because t he definit ion of part ially " done" is known t o everyone, and t hey also

• • • • •

•

•

•

•

•

know what is left " undone" at t he end of t he Sprint and what rem ains t o be done prior t o shipping or using t he increm ent ( s) . em pirical process cont rol An experient ial m et hod of m oving t oward a goal by frequent ly inspect ing progress and m aking adapt at ions t o opt im ize t he overall progress. finished product Som et hing t hat is of pot ent ial use t o t he cust om er; t he cust om er can be an ext ernal consum er of t he syst em or an int ernal consum er of part s of t he syst em . increm ent A com plet e slice, or piece, of t he finished product or syst em t hat is developed by t he end of an it erat ion, or Sprint . inspect ion I nspect ing an increm ent at t he end of a Sprint , and adapt ing t he priorit y and cont ent of t he product backlog so t hat t he next it erat ion of work opt im izes value. it erat ion One of several successive periods of t im e when all t he work t o com plet e one full slice of t he finished product is perform ed; a proj ect consist s of m ult iple it erat ions, also referred t o as Sprint s. Product Backlog A priorit ized list of funct ional and nonfunct ional requirem ent s and feat ures t o be developed for a new product or t o be added t o an exist ing product . The Product Backlog it em s of t he highest priorit y are granular enough t o be readily underst ood by t he Scrum Team and developed int o an increm ent wit hin a Sprint . Lower priorit y Product Backlog it em s are progressively less well- underst ood and granular. Product Backlog it em s t hat are high risks are labeled as high priorit y t o ensure t hat t hey are underst ood and rem oved early in a proj ect . This list t ranscends any one release and is const ant ly em erging and changing. Product Backlog burn- down chart A graph of t he am ount of Product Backlog work rem aining in a proj ect or program across t im e. The am ount of work is represent ed by t he Y axis, and t he Sprint sequence is represent ed by t he X axis. A t rend line of one or m ore am ount s of work rem aining som et im es can be used t o predict when a proj ect will be com plet e. Product Backlog groom ing The Scrum Team spends 10 percent of each Sprint groom ing t he Product Backlog t o m eet t he definit ion of a Product Backlog it em and t o ensure t hat it m eet s t he requirem ent s of t he Sprint Planning Prerequisit es. Product Owner The person who is responsible for what t he Scrum Team builds and for opt im izing t he value of it . The Product Owner is responsible for m axim izing t he value of t he product being developed while m inim izing t he risk. Proj ect or Program The expendit ure of funds t o t urn one or m ore pieces of a Product Backlog int o pot ent ially shippable funct ionalit y t hat can be released for use.

• • •

•

• • • •

•

•

•

Proj ect or Program Goal The reason w hy t he Proj ect or Program has been undert aken. When it is fulfilled, t he Proj ect or Program is " done." requirem ent s What t he syst em or product m ust do. Requirem ent s are subset s of feat ures and funct ions. ret rospect ive A t im e- boxed m eet ing of four hours aft er t he Sprint Review when t he Scrum Team reviews t he j ust - finished Sprint . Aft er review ing everyt hing t hat worked well and t hings t hat could be im proved, t he t eam defines several changes t o how it will work t oget her for t he next Sprint . Scrum A process for m anaging t he developm ent and deploym ent of com plex product s t hat is based in em pirical process cont rol t heory and st ands on t he core pract ices of it erat ive developm ent , which generat es increm ent s of product by using self- m anaging, cross- funct ional t eam s. Scrum Developm ent Team The cross- funct ional, self- m anaging t eam t hat develops as m uch of what t he Product Owner want s int o an increm ent every Sprint . Scrum Mast er The person responsible for ensuring t hat everyone on t he Scrum Team follows t he Scrum process and rules, and who rem oves im pedim ent s t o t he success of t he Scrum Team . Scrum Team The people who work t oget her t o build increm ent s of product every Sprint ; t he t eam consist s of t he Product Owner, Scrum Developm ent Team , and Scrum Mast er. self- m anaging t eam s A group of no m ore t han nine people who figure out how t o do t he work wit hin a Sprint on t heir own and wit hin t he const raint s of ent erprise st andards, guidelines, and const raint s. The self- m anaging t eam can reach out for assist ance or guidance, but none can be given unless t he t eam request s it . Sprint A Scrum it erat ion, norm ally of a one- m ont h durat ion. Short er durat ions can be used, but all t eam s wit hin a proj ect consist ent ly synchronize t heir work using t he sam e lengt h it erat ion, which does not vary during t he proj ect . Sprint Backlog The t asks t he Scrum Developm ent Team perform s t o t urn Product Backlog it em s int o a " done" increm ent . Many are developed during t he Sprint Planning Meet ing ( How) , but up t o 40 percent m ight em erge during t he Sprint . For a Scrum Developm ent Team t o st art work on a Sprint Backlog it em , t he t ask m ust t akes 16 hours or less t o be com plet ed. Sprint Backlog burn- down chart A graph of t he am ount of Sprint Backlog w ork rem aining in a Sprint across t im e. The am ount of work is represent ed by t he Y axis, and t he Sprint sequence is represent ed by t he X axis.

•

•

•

•

•

•

Sprint Goal The purpose of t he Sprint . This is a st at em ent t hat provides guidance t o t he t eam on why it is building t he increm ent . The Sprint Goal is a subset of t he Proj ect or Program Goal. Sprint Planning Meet ing A m eet ing during which t he Sprint cont ent and t he goal of t he Sprint are planned. Required at t endees are t he Product Owner, Scrum Mast er, and developm ent t eam . The t im e- box is eight hours and is decom posed int o " what " and " how" t im e- boxes. Sprint Planning Meet ing ( Ent erprise) A Sprint Planning Meet ing of up t o seven Scrum Team s t hat build a com m on, int egrat ed increm ent . The Scrum Team s review t he overall Product Backlog t hat t hey will work from , select Product Backlog it em s t o m inim ize, and not e dependencies t hey m ust rem ain aware of. Sprint Planning Meet ing ( How) The second four hours of t he Sprint Planning Meet ing, during which t he Scrum Developm ent Team figures out how it will t urn t he Product Backlog select ed during Sprint Planning Meet ing ( What ) int o a " done" increm ent wit hin t he Sprint . The t eam usually st art s by designing t he work and figuring out how t o do it and who will do it . As t his design t akes shape, t asks t o t urn t he Product Backlog int o an increm ent are defined. These t asks m ake up t he Sprint Backlog. Most t eam s develop 60 percent of all t he t asks t hey will do during a Sprint during t his t im e- box. The Product Owner is present during t his m eet ing t o clarify t he Product Backlog and t o help t he t eam m ake design decisions. I f t he t eam det erm ines t hat it has t oo m uch or t oo lit t le work, it can renegot iat e t he Product Backlog it em s t hat it will work on during t he Sprint wit h t he Product Owner. Sprint Planning Meet ing ( What ) The first four hours of t he Sprint Planning Meet ing, during which t he Product Owner goes over t he highest priorit y Product Backlog it em s wit h t he Scrum Developm ent Team . From t hese high- priorit y it em s, t he t eam select s as m uch as it believes it can t urn int o an increm ent in t he upcom ing Sprint . I f t he Sprint Planning Prerequisit es are w ell form ed, t his m eet ing usually t akes less t han t he t im e- box of four hours. Sprint Planning Prerequisit es The input s t o t he Sprint Planning Meet ing. These include t he Scrum Team 's capacit y for work in t he upcom ing Sprint and a Product Backlog decom posed t o include work t hat is underst ood and can be com plet ed wit hin one Sprint . Enough Product Backlog m ust be decom posed t o t his degree of granularit y t o consum e t he Scrum Team 's capacit y.

•

•

• • • •

•

•

Sprint Review Meet ing The inspect ion at t he end of t he Sprint in which t he Product Owner and st akeholders review t he increm ent and collaborat e wit h t he Scrum Developm ent Team . This is a working session t hat leads t o t he adapt at ion of t he Product Backlog. This m eet ing is not a dem onst rat ion, and preparat ion should be m inim ized t o less t han one hour. This m eet ing is t im eboxed t o four hours. Sprint Review Meet ing ( Ent erprise) A Sprint Review Meet ing of up t o seven Scrum Team s t hat are building a com m on, int egrat ed increm ent . The Scrum Team s show t heir increm ent s and collaborat e on t he m ost appropriat e adapt at ions. st akeholders People who have a vest ed int erest in a proj ect . All st akeholders and cust om ers are represent ed by one person, t he Product Owner. t im e- box A m axim um am ount of allot t ed t im e for accom plishing a goal or t ask. All work m ust be com plet ed wit hin t his durat ion. t ransparency A degree of clarit y such t hat , upon inspect ion, everyt hing about t he it em or process in quest ion can be known. t ransparency ( Daily Scrum ) A Scrum Developm ent Team m em ber knows exact ly what he or she is inspect ing at t he Daily Scrum when anot her m em ber says, " I did t his yest erday," because t he t eam has defined what " did" ( and " done" ) m eans for t he Sprint . For inst ance, " I did x yest erday," m ight m ean t hat a part icular funct ion was coded, code reviewed, unit t est ed, checked in, built , had t he unit t est hardness run against it , and had t he accept ance t est harness run against it . t ransparency ( increm ent ) A t erm t hat indicat es t he Product Owner knows exact ly what he or she is inspect ing at t he end of t he Sprint because t he increm ent m eet s t he definit ion of " done" and t he Product Owner underst ands t he definit ion. velocit y The average am ount of work a Scrum Team rem oves from t he Product Backlog at t he end of each Sprint .

These sim ple m echanism s are bound t oget her by rules. The rules are sim ilar t o rules used in chess: a knight can m ove t wo spaces forward and one space t o t he side, but it can't land on anot her piece from t he sam e side. A Scrum rule is t hat t he t eam works only on t he Product Backlog t hat it has select ed for t he Sprint ; no new work can be added.

Scrum and Agile Books Many books have been writ t en about Agile t echniques in general and Scrum in part icular. The following list is divided int o t opics t o help you find a t it le t hat best suit s your part icular area of int erest .

Scrum Books • •

Agile Soft ware Developm ent wit h Scrum by Ken Schwaber and Mike Beedle ( Prent ice Hall, 2001) Agile Proj ect Managem ent wit h Scrum by Ken Schwaber ( Microsoft Press, 2004)

Books on Techniques Used in Scrum for Managing Product Development • • •

Agile Est im at ing and Planning by Mike Cohn ( Prent ice Hall, 2005) User St ories Applied by Mike Cohn ( Prent ice Hall, 2004) Agile Ret rospect ives by Est her Derby and Johanna Rot hm an ( Pragm at ic Bookshelf, 2006)

Books on Managing in an Agile Enterprise • •

The Five Dysfunct ions of a Team by Pat rick Lencioni ( JosseyBass, 2002) The Servant Leader by Jam es A. Aut ry ( Three Rivers Press, 2001)

Books on Related Theory • •

Lean Soft ware Developm ent by Mary Poppendieck and Tom Poppendieck ( Prent ice Hall, 2003) Process Dynam ics, Modeling, and Cont rol by Babat unde A. Ogunnaike and W. Harm on Ray ( Oxford Universit y Press, 1994)

Books that Provide Insights into Agile • •

Ext rem e Program m ing Explained by Kent Beck ( Prent ice Hall, 2004) Agile and I t erat ive Developm ent by Craig Larm an ( Prent ice Hall, 2003)

Books on Agile Software Engineering Techniques • •

Working Effect ively wit h Legacy Code by Michael Feat hers ( Prent ice Hall, 2004) Fit for Developing Soft ware by Rich Mugridge and Ward Cunningham ( Prent ice Hall, 2005)

Scrum and Agile Web Sites • • • • •

Ken Schwaber's Web sit e, www.cont rolchaos.com Mike Cohn's Web sit e, www.m ount aingoat soft ware.com Est her Derby's Web sit e, www.est herderby.com Scrum Alliance Web sit e, www.scrum alliance.org Agile Alliance Web sit e, www.agilealliance.org

Appendix C. Example Scrum Kickoff Meeting Agenda I n t his chapt er: Conduct Kickoff Meet ing 119

This appendix cont ains a Scrum Kickoff m eet ing agenda from an ent erprise t hat is in t he m iddle of adopt ing Scrum . The agenda is som ewhat rigorous, but no m ore t han m ost Scrum m eet ings.

Conduct Kickoff Meeting The Scrum im plem ent at ion begins wit h a m eet ing of senior m anagem ent t o decide whet her t o go forward wit h t he use of Scrum for product developm ent t hroughout t he ent erprise. This is a relat ively short m eet ing. Not m uch t im e is needed t o det erm ine whet her or not everyone is on board and ready t o act ively part icipat e. I f t hey are not , t his is not t he m eet ing t o use t o convince t hem . This m eet ing is m ore of a kickoff. The rules at t his m eet ing are as follows: • • • •

All cell phones m ust be t urned off. No e- m ail or inst ant m essaging can be used. No int errupt ions are allowed for any purposes. Anyone lat e for t he m eet ing or lat e com ing back from a break has t o at least pay a fine and m ight be excluded from t he m eet ing, if appropriat e.

I f everyone can't agree t o t hese rules, it is unlikely t hat t he senior m anagem ent group will have t he st am ina and det erm inat ion for t he im pending change effort . We use t he following agenda for t he kickoff m eet ing: • • •

Review how Scrum works. The basic Scrum process will be reviewed t o ensure t hat everyone has t he sam e init ial underst andings and uses t he sam e language. St at e t he goals of using Scrum and changing t he ent erprise. Every proj ect needs t o have goals. These goals set a cont ext for priorit izing proj ect work and wit hin which decisions will be m ade. Review t he Ent erprise Transit ion ( ETC) proj ect and st affing. Review how t he Scrum im plem ent at ion proj ect ( ETC) will work,

• •

•

how problem s will be det ect ed, how change will occur, and how Scrum will be used as t he process for m anaging t he proj ect . Review changes t hat are likely t o happen. Review t he t ypes of changes t hat can be ant icipat ed wit hin t he ent erprise. Make prerequisit e decisions. The following decisions should be m ade: o Decide t he dat e for t he first Sprint Planning m eet ing for ETC. I t should be wit hin one week. I t can't be lat er t han one m ont h from t he kickoff m eet ing. o Decide who will be t he Scrum Mast er for ETC. A senior m anager who is well- connect ed, det erm ined, conversant wit h change, and fearless is required. o Decide who will be t he Product Owner for ETC. This needs t o be t he m ost senior execut ive in t he ent erprise, t he person who is responsible for t he success of t he ent erprise. o Decide who will be on t he ETC t eam . Decide t o go forward. Once t he decision t o m ove forward has been m ade, t he following com m it m ent s m ust be m ade: o We, t he m em bers of t he senior m anagem ent t eam , are responsible for using Scrum t o successfully reach our goals. The senior m anagem ent t eam is called t he Ent erprise Transit ion ( ETC) proj ect t eam . o We will go forward wit h using Scrum for product developm ent and changing t he ent erprise t o opt im ize it self t o t ake advant age of Scrum . o There will be an Ent erprise Transit ion proj ect , and it will follow t he Scrum process t o reach t he st at ed goals. o The Ent erprise Transit ion proj ect will be st art ed wit hin one m ont h. o The following act ions will be com plet ed prior t o t he st art of t he Ent erprise Transit ion proj ect . The responsibilit y for com plet ing t he work belongs t o t he Ent erprise Scrum t eam of senior execut ives. They cannot delegat e t heir work t o m ore t han one level down. If these or equivalent commitments can't be made at this time, consider delaying the project, with the following considerations: o o o

What do you need t o believe t hat Scrum will help you achieve your goals? What do you need t o believe t hat Scrum is appropriat e for ETC? I f t he com pet it iveness and effect iveness of your ent erprise isn't param ount , what is?

•

Com plet e t he follow- up act ions. Once t hese decisions are m ade, t he following act ions m ust be init iat ed and com plet ed wit hin one m ont h. These are t he highest priorit y it em s on t he init ial ETC t ransit ion backlog. o The ETC t eam m ust at t end form al Cert ified Scrum Mast er t raining. o A m et hod and t he m echanism s for t racking ent erprise change will be defined. o Addit ional init ial t ransit ion backlog it em s m ust be form ulat ed. o The ETC proj ect m ust be init iat ed, as defined in t he following bullet ed it em s. o Com m unicat e t hese decisions and what is about t o happen t o everyone. And t hen com m unicat e t hem again and again. Com m unicat e any changes. Keep everyone in t he loop. Make t hese com m unicat ions face t o face. o Est ablish an ent erprise vehicle, such as a Web sit e, t hat ensures everyone knows about t he change. o Est ablish a m echanism t hat allows anyone in t he ent erprise t o give feedback or suggest ions. o Est ablish precondit ions for developm ent proj ect s t hat use Scrum . o Est ablish m et rics for t racking Scrum proj ect s. o Est ablish report ing m echanism s for Scrum proj ect s. o Est ablish a m echanism t hat enables anyone wit hin t he ent erprise t o add it em s t o t he t ransit ion backlog. o Measure m orale.

Appendix D. Initial Enterprise Transition Product Backlog I n t his chapt er: Est ablish Precondit ions a Proj ect Must Meet t o Use Scrum 123 Est ablish New Met rics

124

Change Proj ect Report ing

124

Est ablish a Scrum Cent er

125

This appendix describes a high- priorit y t ransit ion Product Backlog t hat should be addressed once an ent erprise has decided t o go forward wit h Scrum .

Establish Preconditions a Project Must Meet to Use Scrum Once senior m anagem ent has decided t o roll out Scrum , m ore people and proj ect s will want t o use it t han can be accom m odat ed. I t is wise at t his point for cert ain precondit ions t o be est ablished. A proj ect m ust m eet t hem before it can officially use Scrum . Som e of t he m ost im port ant precondit ions are t he following ones: •

•

•

•

Full- Tim e Team The core of t he Scrum t eam m ust be devot ed full t im e t o t he proj ect . Alt hough t hey som et im es m ight need t he services of expert s who aren't full t im e, t rying t o Scrum wit h part - t im e t eam m em bers only perpet uat es bad habit s and undercut s t he value t hat everyone expect s. Scrum Mast er Training The Scrum Mast er is supposed t o lead t he t eam and Product Owner t hrough t he change. Make sure t hat t he Scrum Mast er receives full Cert ified Scrum Mast er t raining prior t o t he proj ect st art ing. The Scrum Mast er should also connect wit h ot her, m ore experienced Scrum Mast ers t o m ent or him or her. Product Owner Training The Product Owner is not accust om ed t o m anaging a proj ect t hroughout it s ent iret y, Sprint by Sprint , t o m axim ize t he value of t he invest m ent . He or she needs Cert ified Product Owner t raining. Team Form at ion Act ivit ies The ent ire t eam , including t he Product Owner and Scrum Mast er, need t o form t hem selves int o a t eam . There are num erous books and consult ant s t o help you wit h t his act ivit y. I f t he Hum an Resources depart m ent is engaged in t he Scrum process, ask it t o help wit h procuring t hese resources.

•

Team Room The t eam needs a room for it s Daily Scrum , and a full- t im e room wit hin which t hey can work. This is not yet collocat ed space, which will be provided for t hem when t hey request it .

Establish New Metrics Scrum m et rics are very different from t he m et rics t hat m ost ent erprises use t o m anage t heir developm ent proj ect s. Earlier, m ore t radit ional m et rics were derived in an at t em pt t o abst ract what was happening in a proj ect t hat last ed for m ont hs and m ont hs before anyt hing was visible. I n a Scrum proj ect , t eam progress is visible every day wit hin a Sprint at t he Daily Scrum and t hrough t he Sprint burn- down graph. And proj ect progress is visible every m ont h t hrough t he Sprint Review and t he Product Backlog burn- down graph. Two prim ary m et rics are used t o t rack a Scrum proj ect : •

•

Ret urn on invest m ent ( ROI ) Prior t o a proj ect being approved, t he Product Owner m ust calculat e t he ROI . As t he proj ect progresses, Sprint by Sprint , t his helps m anagem ent and t he Product Owner evaluat e whet her t he invest m ent is wit hin bounds. Unaccept able product ivit y by t he developm ent t eam could indicat e t hat t he proj ect m ight be bet t er off being cancelled. Product ivit y The prim ary m easure of product ivit y is a t eam 's abilit y t o t urn Product Backlog it em s int o shippable product funct ionalit y. We m easure t his for som e financial value ( for exam ple, $100,000) and defect rat e ( num ber of defect s, ret rospect ively det erm ined) . Track t his m et ric across a large num ber of Sprint s and proj ect s. This m et ric will norm alize across t im e, and t hen t rends can be t racked. This m et ric is of lit t le value for m easuring a single Sprint because of local anom alies.

Suboptimal Metrics There are a large num ber of ot her t hings t hat can be m easured. Measuring any one of t hem for very long will t end t o produce skewed behavior by t he Product Owner or t eam , as t hey opt im ize t o it and subopt im ize ot her t hings of value. We t end t o im plem ent and use t hese m et rics only when a problem is det ect ed. The m et ric t hen helps us im prove t he problem unt il it is fixed. At t hat t im e, rem ove t he m et ric.

Change Project Reporting You current ly have m et hods for t racking a proj ect . Review all t he ways t hat you do so. Many of t hem m ight be appropriat e for a wat erfall developm ent process, but t hey m ight be inappropriat e or not even available when you use Scrum . Review t he m echanism s wit hin Scrum for t racking progress, such as Sprint Reviews, Product Backlogs, and burn- down graphs. Keep only t hose exist ing report s t hat add value t o Scrum 's t echniques. The added value should be great er t han t he cost of gat hering and report ing t he dat a.

Establish a Scrum Center An ent erprise needs t o est ablish how Scrum will be used, how proj ect s and t eam s using Scrum will fit int o t he organizat ion, and t he rest of t he process for using Scrum . A Scrum Cent er uses t his em erging inform at ion t o t rain, coach, m ent or, and audit proj ect t eam s. The Scrum Cent er usually consist s of t rained, experienced Scrum Mast ers who are responsible for Scrum 's effect iveness wit hin t he ent erprise. Every t eam st ruggles t o get t he m ost benefit s from Scrum . The t eam 's Scrum Mast er is responsible for leading t hem t hrough t he t ransit ion t o a point where it uses Scrum effect ively. However, t he Scrum Mast er and t eam oft en get so em broiled in t heir work t hat t hey lose perspect ive on t hem selves. For t his purpose, having an audit capabilit y is useful. Som eone who knows Scrum and is from out side t he t eam needs t o have a w ay t o m easure how well t he t eam is using Scrum . These m easurem ent s are quant ificat ions, which are always dangerous. Som e t eam s can be doing great but quant ify less well t han ot her t eam s. The feel, sm ell, and general sense an expert out sider has of how t he t eam is doing should confirm , or even drive, t he quant ificat ion. Furt her coaching or m ent oring can be provided t o t eam s t hat need t o im prove.

Appendix E. Scrum Musings I n t his chapt er: Value- Driven Developm ent

127

Realizing Proj ect Benefit s Early

129

Eat Only When Hungry

130

For Cust om ers Only

131

Bidding Work

133

Managing Work

134

A Cost - Effect ive Alt ernat ive t o Offshore Developm ent

136

How t o Use Scrum and Offshore Developm ent

138

Too Large Team s

139

Virt ual Team s I nst ead of Offshore Developm ent

140

Form ing Cross- Funct ional Team s

142

Cross- Funct ional Team s and Wat erfall

143

Here follow som e ot her t hought s on Scrum t opics.

Value-Driven Development Chapt er 9 briefly describes how t he Product Owner can use valuedriven developm ent t o change t he relat ionship bet ween herself and t he developm ent t eam while ret aining product qualit y. Let 's revisit t hat process here and see in m ore det ail how t hat value is realized. Scrum int roduces t he concept of workload m anagem ent t o syst em s developm ent . Workload m anagem ent involves cont rolling developm ent of funct ionalit y and release dat es t o opt im ize t he value t o t he organizat ion of t he syst em being developed. This is different from work m anagem ent , in which t he specific t asks involved in building a syst em are direct ed. Scrum m akes workload m anagem ent possible t hrough it erat ive, increm ent al developm ent . Developm ent occurs in a series of short it erat ions of less t han one m ont h durat ion. An increm ent of funct ionalit y is done by t he end of every it erat ion. The t erm " done" here m eans pot ent ially shippable or able t o be im plem ent ed. " Done"

m eans com plet e—t hat is, it has been fully t est ed and includes user docum ent at ion. Tradit ional developm ent m et hodologies fully analyze and design a syst em before coding it . Test ing usually follows t he coding. I t is not unt il t he very end of t he proj ect t hat t he syst em can be im plem ent ed. The opport unit ies for m anaging t his workload t o opt im ize value are lim it ed and usually not very considerable. However, Scrum m akes it possible t o perform analysis, design, t est ing, coding, and docum ent at ion in every it erat ion. This provides m anagem ent wit h m any opport unit ies t o do t he following: • • •

Arrange t he sequence in which funct ionalit y is it erat ively developed so t hat t he m ost valuable funct ionalit y is built first . Cont inue t o rearrange t he sequence of funct ionalit y developm ent as t he proj ect progresses and business priorit ies change. Group increm ent s of funct ionalit y int o m ore frequent releases, allowing t he business t o realize early and frequent benefit s.

Consider a syst em t hat will bring t he organizat ion $1,000,000 in benefit s in t he first t wo years aft er it s im plem ent at ion. Using t radit ional m et hods, t he syst em would t ake one year t o develop at a cost of $400,000. Scrum let s us develop and im plem ent t he syst em 's funct ionalit y select ively and increm ent ally by doing t he following: 1. List ing t he funct ionalit y of t he syst em , wit h m ore at t ent ion paid t o t he highest value and priorit y funct ionalit y 2. Dividing t he funct ionalit y list int o t wo releases, t he first est im at ed t o be ready six m ont hs aft er developm ent begins 3. Using it erat ive, increm ent al developm ent t o com plet e t he first release wit hin six m ont hs for $200,000 4. Allowing benefit s wort h $800,000 t o begin accruing aft er j ust six m ont hs, wit h t he funct ionalit y t hat will deliver t he rem aining value scheduled t o be developed during t he second it erat ion 5. Perm it t ing t he second im plem ent at ion t o be deferred if it is not deem ed cost effect ive and t he benefit s of t he first im plem ent at ion are deem ed sufficient —for exam ple, if t he developm ent cost of $200,000 for t he less valuable funct ionalit y would generat e only $200,000 in benefit s. I n t his case, t he cust om er had an opport unit y t o realize $200,000 in benefit s six m ont hs earlier t han would ot herwise have been possible. The cust om er also had t he opport unit y t o choose not t o spend an addit ional $200,000 for break- even funct ionalit y. The t im e and effort

t hat would have gone int o t he second it erat ion could inst ead be allocat ed t o ot her higher priorit y proj ect s. The benefit s of m ult iple releases are som ew hat offset by im plem ent at ion cost s. St rat egic and com pet it ive syst em s are able t o gain m arket place advant age t hrough such increm ent al st rat egies. I m agine t hat your com pet it ion uses t radit ional developm ent approaches t o prepare a single new release or business capabilit y, but your organizat ion uses Scrum t o produce early and repeat ed com pet it ive advant ages. I f t his is t he case, your organizat ion is able t o capt ure t he advant age m ore effect ively and t horoughly. An addit ional benefit of workload m anagem ent is invent ory reduct ion. As in m anufact uring, unfinished " raw goods" soft ware invent ory is an undesirable cost . The invent ory m ight need t o be reworked if it has defect s. I t m ight never even be used if product ion cost s are t oo high or dem and for t he soft ware evaporat es. Yet t radit ional developm ent m et hodologies am ass huge invent ories of analysis, design, and coding art ifact s even as business changes render t hem obsolet e. The Scrum approach m inim izes t he ext ent t o which an organizat ion accum ulat es such art ifact s. Only art ifact s t hat are necessary t o build each it erat ion's increm ent of funct ionalit y—t he highest priorit y funct ionalit y—are built . Workload m anagem ent is a key new role afforded by Scrum . This role is referred t o as " t he Product Owner." This role has responsibilit ies t hat enable an organizat ion t o realize t he benefit s of workload m anagem ent . The Product Owner execut es t he responsibilit ies of t his role t hrough act ive m anagem ent of an invent ory called Product Backlog. Let 's look m ore closely at Product Backlog. Product Backlog is a sim ple list of requirem ent s for t he syst em . Each it em on t he list is a single line in lengt h. Funct ional requirem ent s, such as " t he abilit y t o calculat e available credit ," are list ed along wit h nonfunct ional requirem ent s, such as " t he capacit y t o handle up t o 100,000 sim ult aneous t ransact ions wit h sub- second response t im e." Product Backlog is oft en m aint ained in spreadsheet form at so t hat it can be easily m anipulat ed and int erpret ed. The Product Backlog is a priorit ized list . I t em s at t he t op of t he list are t hose t hat will deliver t he m ost business value. Business priorit ies can change over t he course of t he proj ect , and consequent ly t he order of t he list can change as well. Dependent funct ionalit y, or funct ionalit y

t hat is required t o support t he highest priorit y backlog, is of an even higher priorit y. An est im at e of how long it will t ake developers t o t urn t he funct ionalit y int o an increm ent of pot ent ially shippable product is included in each backlog it em . The Product Owner doesn't have t o specify all t he det ails of every ent ry in t he Product Backlog. The Product Owner ext ract s requirem ent s from t he syst em s plan, focusing on t he highest priorit y Product Backlog first . At first , t he Product Owner needs t o list only as m uch Product Backlog as is needed t o drive t he first probable release. The lower priorit y funct ionalit y can be it em ized and delivered only when it is deem ed t o be t he highest priorit y available funct ionalit y. Even t hen, it s developm ent can be deferred if it cost s m ore t han it is wort h.

Realizing Project Benefits Early Keeping wit h t he t hem e of value, let 's look at a few real- world exam ples of com panies t hat used Scrum it erat ive developm ent principles t o increase a proj ect 's value. Any syst em s developm ent process t hat provides for early realizat ion of proj ect benefit s and m axim ized ret urn on invest m ent creat es value. Thought Works develops syst em s for it s cust om ers using Scrum . I n a recent st udy by Forrest er Research, Thought Works cust om ers ident ified early realizat ion of benefit s as a prim ary reason why t hey were pleased wit h t heir relat ionship wit h Thought Works ( post ed at t he Thought Works Web sit e at ht t p: / / www.t hought works.com / forrest er_t ei.pdf) . I n t he previous sect ion, I m ent ioned t hat all Scrum proj ect s use it erat ive, increm ent al t echniques. At t he end of every it erat ion, an increm ent is delivered t hat cont ains all aspect s of t he final product , including t est ed code, docum ent at ion, and user help. When t he applicat ion calls for m ore increm ent al product , t his is also included. For inst ance, FDA Life Crit ical applicat ions m ust have requirem ent s t race abilit y, dem onst rat ing how t he init ial requirem ent s are im plem ent ed in t he finished product . This t race abilit y is included in every increm ent delivered at t he end of every it erat ion. Having inspect ed an increm ent of t he syst em at t he end of an it erat ion, cust om ers can choose t o im plem ent t he funct ionalit y before t hey had planned t o. TransCanada Pipelines ( TCPL) in Calgary, Albert a, chose t o do so aft er j ust one it erat ion. The proj ect was int ended t o

aut om at e t it le change feeds from all t he provinces and st at es t hat TCPL's pipelines crossed. Aft er t he first it erat ion, t he paper feed from Albert a was aut om at ed int o an XML feed wit h a part ial dat abase and change m anagem ent screens. Because over 30 percent of all changes were from Albert a, when t he cust om er saw t his one feed working, she chose t o im plem ent it im m ediat ely. The addit ional cost of t his early im plem ent at ion and realizat ion of benefit s m ore t han offset t he cost of t he im plem ent at ion. Scrum developm ent processes creat e opport unit ies for cust om ers. They can im plem ent one or m ore increm ent s of funct ionalit y at any t im e. They can also m ake ot her invest m ent choices, such as increasing or canceling funding of t he proj ect . When t hey inspect what t he t eam has developed at t he end of every it erat ion, t hey have all t he inform at ion t hey need t o j ust ify such decisions. I f good engineering pract ices have been used t o build each increm ent of funct ionalit y, t he cost of im plem ent ing it is relat ively sm all. I f m arginal engineering pract ices have been em ployed, all defect s m ust be fixed during t he im plem ent at ion cycle. Such increased im plem ent at ion cost s discourage cust om ers from calling for im plem ent at ions. Because of t his, part of im plem ent ing a Scrum process is im proving t he engineering pract ices of t he developm ent organizat ion. As t he preceding exam ples dem onst rat e, we want t he cust om er t o be encouraged t o call for early realizat ion of benefit s.

Eat Only When Hungry Scrum soft ware developm ent : Eat only t hat for which you hunger; m aint ain only t hat which you need. When I go t o t he w indow of a fast - food rest aurant , I evaluat e what I want t o eat in light of how m uch m oney is in m y pocket . At finer rest aurant s, I usually spend what ever what I want cost s, because paym ent is flexible t hrough t he use of a credit card. But , for m e, fast food is st ill cash only, and m y choices are lim it ed by m y cash on hand. I n t radit ional syst em s developm ent , cust om ers ident ify what t hey want —t he requirem ent s of t he syst em —and are t old what t he cost will be and t he dat e on which t he syst em will be delivered. I n a fast - food scenario, t his is analogous t o driving up t o t he window, ordering, and t hen being t old t o pull over and wait for our food unt il a specified t im e. During t hat t im e, we could figure out how t o get t he m oney t o pay for t he est im at ed cost .

I m agine buying syst em s funct ionalit y for a variable cost . Scrum let s cust om ers st at e t he funct ionalit y t hey want and how m uch m oney t hey want t o spend. The funct ionalit y is delivered t o t he cust om er at t he end of every it erat ion, during which t he t eam cooks up a way of delivering t he funct ionalit y. The cust om er looks at what was delivered and decides whet her he is sat isfied. I f t he cust om er want s t he funct ionalit y in m ore dept h, he can order m ore st uff built int o t he funct ionalit y in furt her it erat ions. I f t he funct ionalit y is pret t y com plicat ed ( like a sourdough bacon burger cooked m edium well, wit h t he bacon well done and t he roll t oast ed) , t he funct ionalit y m ight t ake several it erat ions before t he first digest ible port ion is ready. However, we st ill let t he cust om er inspect t he " food in progress" t o m axim ize t he likelihood t hat it will be what t hey hunger for. Tradit ionally, we list all t he requirem ent s for cust om er funct ionalit y and deliver all of it . This is like a fixed- price dinner, where we get all t he food even if we are full and sat ed aft er only t he appet izer. Scrum let s us st at e t he desired funct ionalit y ( we are hungry) and t hen order requirem ent s a la cart e, one at a t im e, unt il we are sat isfied. Because t he requirem ent s can be priorit ized, t eam s can it erat ively deliver only increm ent s of t he requirem ent s t hat are m ost appet izing t hroughout a proj ect . Since we are sat ing t he cust om er by delivering increm ent s of funct ionalit y, t he cust om er can dict at e when she is sat ed, or when she has spent all t hat she want s t o, and t hen consum e t he funct ionalit y as delivered. Cust om ers eat what t hey hunger for—no m ore, no less. This sim ple analogy, com paring syst em s developm ent t o dining, works not only at t he consum pt ion level, but at t he m aint enance level. I f we eat in " all you can eat " rest aurant s, we get fat , have t o buy new clot hes, and our healt h suffers. I f we consum e fixed- requirem ent s syst em s, we have t o m aint ain and enhance all t he funct ionalit y, even t he st uff t hat we infrequent ly or never use.

For Customers Only Have any of your soft ware developm ent proj ect s surprised you, eit her because t hey failed ut t erly, didn't com e in on t im e, were of low qualit y, or t ook longer t o deliver t han you expect ed? You m ight want t o t ake com fort in t he knowledge t hat you weren't singled out and t hat anyone else who init iat es and funds soft ware developm ent proj ect s is not bet t er off. Most of you share a com m on experience. I n t he polit ical arena, you would have been " spun." Underlying it all is t he t hread t hat

your soft ware developm ent proj ect t eam worked, at bot h a conscious and unconscious level, t o keep you in t he dark. Even t hough t he t eam knew t here were problem s, it hoped against hope t hat everyt hing would t urn out all right . I run a class t hat t eaches proj ect m anagers t o m anage proj ect s using Scrum . Scrum soft ware developm ent requires you, t he cust om er, t o act ively collaborat e wit h t he developm ent t eam s t o opt im ize t he value you get from your invest m ent and t o get t he funct ionalit y t hat you need t o m eet your obj ect ives. I n t his course, t here are a num ber of exercises t o explore how Scrum proj ect m anagers will facilit at e t his. I n t he exercises, a difficult proj ect is init iat ed. There are m any risks in t he t echnology as well as difficult choices t o be m ade in how t o support t he business goals wit h t he t echnology. The point of t he exercises is t o creat e a scenario where t he developm ent t eam s act ively collaborat e wit h you t o help you m inim ize your risk while m axim izing your value. Many people in t hese courses have excelled. However, a dist urbing num ber of t hese proj ect m anagers are unable t o help you underst and your risks and alt ernat ives. Not because t hey aren't aware of t hem . Not because t hey don't know t hat t he proj ect m ight not succeed or m eet your expect at ions. They are unable t o help you because t hey are afraid t o t ell you t he t rut h. Even while fully underst anding t he risks, t hese people will t ell you t hat t hey are absolut ely confident t hat t hey can deliver t he proj ect on t im e wit h what you need. Words like cert ainly, posit ively, no problem , slam - dunk, and wit hout a doubt slip from t heir lips even t hough t heir m inds and experience t ell t hem ot herwise. When I ask t hem why t hey m islead you ( t he cust om er) and don't share t heir t rue opinions wit h you, t hese people t hat you will ent rust your success and m oney t o say t hat t hey don't want t o discourage you, t hat t hey want t o put a posit ive spin on t hings, and t hat you wouldn't work wit h t hem if t hey didn't have a posit ive out look. They t ell m e t hat you are so dum b t hat you would select som eone who t ells you, " No problem ," if t hey raised t he spect er of risk and doubt . I ask t hese people how t hey would feel if t hey w ere t reat ed t he sam e when buying som et hing t hem selves. Perhaps t hey ent er a rest aurant , a very expensive rest aurant , and order a st eak. The wait er and t he chef know t hat t he beef is old and t hat it com es from a herd where m ad- cow disease has been spot t ed. Yet , t hey figure t hat what you don't know won't hurt you, t hat your act ual chance of becom ing ill is pret t y low, and t hat t hey probably will be elsewhere if you do becom e

ill. All of t hem t ell m e t hat t hey would be furious! I ask t hem where t hey get t he nerve for assessing your risks for you and gam bling your m oney in t he face of uncert aint y. What I hear back is a com binat ion of fear, uncert aint y, and bad habit s. Except for t he newest proj ect m anagers, t he soft ware developm ent profession has experienced a period of 20 years when it was at least difficult and m any t im es im possible t o t ell t he cust om er if t he proj ect would succeed. The cust om er wasn't being lied t o—t he proj ect m anagers j ust didn't know. Worse, because of t he process used t o m anage syst em s developm ent , proj ect m anagers didn't have any way t o det erm ine whet her a proj ect would be successful or not unt il well int o t he proj ect and int o t he cust om er's m oney. They covered up t he appalling t rut h t hat —in light of t he low probabilit y of success—only a desperat e person w ould fund t he proj ect . This has led t o a st at e where m any vent ure capit alist s and ent erprises are t urning t o offshore developm ent . These peers of yours have t old m e a num ber of t im es t hat t hey are doing t his not t o reduce t he cost of a successful proj ect , but t o lim it t heir losses. I f t he proj ect is going t o fail anyway, it 's bet t er t o lose $500,000 t han $1,500,000. Scrum provides an opport unit y t o t urn around t his unfort unat e sit uat ion. Mont h by m ont h all t he proj ect inform at ion is available so t hat cust om ers can m axim ize t heir ret urn on invest m ent and opt im ize t heir risk st rat egies. But t his happens only if t he proj ect det ails aren't hidden from t he cust om er. Alt hough it 's happening slowly and painfully, and in t he wake of a hist ory of hiding t he t rust , we are developing proj ect m anagers who are confident of what t hey can and can't do wit h your proj ect . Look for t hem . Don't look for t he person who t ells you what you want t o hear, even t hough you know t hat what you are being prom ised is im possible. Don't list en t o t he proj ect m anager who t ells you t hat your difficult proj ect is " no problem " and t hat he is " absolut ely confident ."

Bidding Work We are oft en asked for est im at es t o build a syst em . Even t hough t he syst em is com plex, we are prodded wit h quest ions like, " What will it t ake?" And, t o our regret , t he est im at e—once out of our m out hs— becom es a cont ract . I had an experience recent ly where a professional in anot her field showed m e anot her way t o deliver an est im at e, and I was pleased wit h his approach.

The ext erior of m y house needed paint ing. I called in t hree paint ing cont ract ors, and m y experience wit h t hem m ight be of int erest t o t he Scrum com m unit y. The t hree cont ract ors all cam e t o m y house, apprised it , and provided est im at es. The high est im at e was $15,000, t he m iddle est im at e was $12,000, and t he low est im at e was $7,000. All were fixed- price est im at es good for 30 days. No est im at e t ook m ore t han one hour t o prepare, and I walked around t he house wit h each cont ract or and answered any quest ions t hey had. I was surprised at t he fixed- priced bids, since I knew m y house's ext erior had som e unique at t ribut es t hat none of t he cont ract ors had encount ered previously. My house is clad wit h DryVit , a highly insulat ing foam - board const ruct ion t echnique usually reserved for com m ercial buildings because of t he skill needed t o apply it . The DryVit is t hen covered wit h a propriet ary sealing polym er and t hen given a final color coat of acrylic paint . The paint applicat ion has t o be carefully applied since it t ends t o soak in m ore t han ot her paint . So I was perplexed and som ewhat uneasy t hat t hese cont ract ors t hought t hey could fix- bid such a com plex proj ect . Maybe t hey t hought it was sim ple? Twent y days aft er t he last bid was subm it t ed, I was driving hom e on a lim it ed- access highway. The speed lim it was 55 m ph. Suddenly, an im m aculat e, whit e panel t ruck passed m e on t he left , going at least 80 m iles per hour. As it disappeared, I was able t o m ake out t he nam e on t he side, " Noe Mont enegro, Professional Paint ing." I was im pressed. Here was a guy in a hurry who nevert heless cared about appearances. When I got hom e, I looked up his t elephone num ber and asked him t o com e over t o bid on t he j ob. Noe was a young, int elligent m an. When he cam e t o t he house, he spent t im e looking at t he ext erior before even ringing t he doorbell. When I cam e out side, he asked very penet rat ing quest ions about t he ext erior, it s const ruct ion, and it s com posit ion. I gave him all t he m at erial and inform at ion I had, and he left . The next day he st opped by and t old m e t hat he had been doing som e research. The research had led him t o underst and t he t ype of acrylic paint required for m y house, as well as t he difficult ies and com plexit ies of applying it . Noe said t hat even t hough he and his crew were great professional paint ers, t hey had no experience wit h t his t ype of ext erior and were uncom fort able subm it t ing a fixed- price bid. Noe said t hat if he t ried t o cover his uncert aint y wit h a high bid, it m ight be t oo high. Sim ilarly, if he m ade incorrect assum pt ions, he m ight underbid t he work and have t o t ake a loss.

Aft er t alking for a w hile, we reached an arrangem ent . I would pay Noe and his crew $65 per hour plus m at erials for paint ing t he front of t he house. Then he would give m e a fixed- price bid for t he rest of t he house, based on his new knowledge and experience. I felt com fort able wit h t his because if Noe's price was t oo high or his com pet ence t oo low, I was free t o not use him aft er t he front of t he house was done. Also, I would have t hat increm ent of work done and could build on it wit h any ot her cont ract or. When t he j ob was com plet e, t he t im e and m at erial and fixed- price rem ainder of t he work cost m e $8,500—and t hat was for excellent workm anship. Noe even cleaned t he windows. I added $1,000 t o t he check, as I was t horoughly im pressed wit h his work as well as his honest approach t o bidding on it . I t old him t hat I was going t o use t his experience as a st ory. He j ust shrugged and said, " Thanks."

Managing Work I previously discussed how Scrum facilit at es workload m anagem ent by allowing for frequent , it erat ive delivery of shippable funct ionalit y and by enabling cust om ers and Product Owners t o priorit ize direct developm ent of t op value funct ionalit y, it erat ion by it erat ion. Who m anages t he work during each it erat ion? The Scrum answer is: t he developm ent t eam ! I n previous chapt ers of t he book, I 've described how t his happens, but I 'll describe it in m ore det ail here, wit h a focus on work m anagem ent . The Product Owner indicat es what funct ionalit y m ost needs t o be developed. The developm ent t eam ident ifies and organizes t he t asks and work necessary t o ensure t he result of t he it erat ion is a pot ent ially shippable product . Collaborat ing wit h t he Product Owners, t he developm ent t eam det erm ines how m uch priorit y funct ionalit y it believes it can cover in t he next it erat ion. Scrum work m anagem ent is a shift from t radit ional proj ect m anagem ent pract ices. These pract ices call for a proj ect m anager t o predict and plan all t he work, as well as t o assign it t o individuals, t rack it s com plet ion, and m ake any necessary adj ust m ent s along t he way. Scrum work m anagem ent , inst ead, follows m odern lean m anufact uring pract ices and engineered process cont rols used in com plex developm ent environm ent s. Scrum t eam s have t hese charact erist ics:

• •

• •

They are cross- funct ional, cont aining all t he t echnical and business dom ain expert ise t o t ake full responsibilit y for m oving requirem ent s forw ard t o becom e working product funct ionalit y. They are lim it ed in size t o m axim ize t he speed, cont ent , accuracy, and bandwidt h of com m unicat ions. Team size is up t o nine people. When t here are m ult iple t eam s, t he t eam s get t oget her t o synchronize t heir work on a daily basis. They are aut horized t o organize t hem selves, t o divide and assign work am ong t hem selves. They are enabled t o add t asks required for t he creat ion of an increm ent of funct ionalit y as t he it erat ion progresses; t hey are not expect ed t o be able t o m ake perfect predict ions.

For t he durat ion of t he it erat ion, t he t eam has t he aut horit y t o m anage it self. I t s m ain goal is t o do t he best t hat it can. Applying t he t echnology t o t he requirem ent s, t he t eam analyzes, designs, codes, t est s, and docum ent s. At t he end of t he it erat ion, t he t eam shows t he Product Owner what it has accom plished. The t eam uses workst at ions t o show t he Product Owner t he funct ionalit y it has creat ed. Only real working funct ionalit y count s t o t he cust om er; int erim art ifact s such as m odels do not count . Som et im es t he t eam does less t han it has predict ed it would be able t o. Som et im es t he t eam im plem ent s t he select ed requirem ent s even m ore deeply t han it had expect ed it could. The im port ant t hing is t hat t he t eam does t he best t hat it can. For one it erat ion, t he t eam alone wrest les funct ionalit y from com plex, som et im es unst able, t echnology and from oft en- changing business requirem ent s. To m any, it m ight seem risky and even foolhardy t o t rust t he t eam t o plan and execut e it s own work. However, t his t ype of Scrum developm ent has been successfully used in lit erally t housands of proj ect s. Two t ypes of product ivit y occur. First , t he proj ect m anager doesn't have t o t ry t o t ell t he t eam what t o do and t hen keep t he plan up t o dat e as changes are required. Second, t he t eam works m ore effect ively wit hout having t o rely on ext ernal aut horit y for any changes. The U.S. Marine Corps uses an approach sim ilar t o Scrum for bat t le sit uat ions. I n Corps Business by David H. Freedm an ( HarperCollins Publishers, 2000) , General Charles C. Krulak, t he 31 st Com m andant of t he USMC, describes t he new " t hree block war" t hat t he corps faces t oday: " Marines m ay confront t he ent ire gam ut of t act ical challenges wit hin t he narrow confines of t hree cont inuous blocks." To prepare t he

Marines, t he act ual fight ers, for t his sit uat ion, t he USMC bot h t rains everyone ext ensively in all pot ent ial skills and sit uat ions t hat can be conceived and t hen advises t he Marines on t he cont ext , m ission, goals, and risks of every sit uat ion before t hey are sent in t o it . But , from t hen on, t he Marines are on t heir own, m aking t heir own decisions. Their officers provide as m uch t act ical inform at ion as possible, but t he ult im at e decisions com e from t he soldiers. As General Krulak says, " On t he com plex, asym m et rical bat t lefields of t he 21 st cent ury, effect ive decent ralized cont rol and execut ion will be essent ial t o m ission success." This sam e t ype of decent ralized cont rol and execut ion by Scrum t eam s is required t o successfully cope wit h t he com plex changing requirem ent s and com plex unst able t echnology required for t oday's successful syst em s. These t eam s m anage t hem selves based on t heir skills and underst anding of t he t echnical and business dom ains.

A Cost-Effective Alternative to Offshore Development More of m y cust om ers have been asking m e how t o use Scrum t o help t hem m anage offshore developm ent . Because offshore developm ent undercut s m any of t he pract ices t hat prom ot e Scrum product ivit y, I ask t hem why t hey don't j ust increase t he product ivit y of t heir t eam s by t horoughly int roducing agilit y? I t seem s t hat offshore developm ent , wit h it s pot ent ial for lower unit cost s ( dollars per program m er day) , offers m anagem ent hope t hat t heir losses can be reduced. Their at t it ude can be st at ed as follows: " Since t he proj ect is probably going t o fail anyway, let 's m inim ize our losses by using lower priced resources t o lim it our invest m ent ." A m ore opt im ist ic, Scrum , way of looking at t his problem is t o fix t he problem at hom e and increase t he probabilit y of success. The Scrum process " sweet spot " occurs wit h t eam s of seven people, give or t ake t wo. These t eam s can be ext raordinarily product ive, m easurem ent s indicat ing a pot ent ial increase of product ivit y at least 35 t im es higher t han average. I 'll describe som e of t he circum st ances t hat support a t eam of t his size in achieving t his level of product ivit y. Many inadvert ent pract ices reduce t his product ivit y, including scaling, so let 's underst and how t o be as product ive as possible before we int roduce scaling—which reduces t eam product ivit y for such goals as quicker t im e t o m arket . High- bandwidt h com m unicat ion is one of t he core pract ices of Scrum . I f a t eam has m ore t han nine people, t hey t end t o need t o revert t o

writ t en docum ent s and form al m odels t o keep everyone's act ivit ies synchronized. The best com m unicat ion is face t o face, wit h com m unicat ions occurring t hrough facial expression, body language, int onat ion, and words. When a whit e board is t hrown in and t he t eam s work out a design as a group, t he com m unicat ion bandwidt h absolut ely sizzles. Unt il t he lat e 1990s, m any engineering pract ices prom ot ed form al docum ent at ion of com m unicat ions, such as form al m odels, docum ent at ion t em plat es, and com put er- aided soft ware engineering t ools. Whenever I don't work direct ly wit h t eam m em bers using facet o- face com m unicat ions, however, I reduce t he com m unicat ion bandwidt h and int roduce t he probabilit y of m isunderst andings. As I 'm writ ing t his, I 'm t rying t o form ulat e ideas, underst andings, and experiences int o words. When you read t his, you t ry t o underst and what I 'm saying wit hin t he cont ext of your experiences and current sit uat ion. I n t he process of narrowing m y bandwidt h t o words, and you t rying t o expand t he bandwidt h from words t o your underst anding, a lot is lost . No m at t er how well I writ e and you read. And m ost of us are not superb writ ers and readers. Many Scrum pract ices are aim ed at m axim izing com m unicat ion bandwidt h. These include t he following: • • •

•

•

Using m odeling t ools and t echniques only t o guide t hought processes while on t he pat h t o code. Models are not used t o docum ent , but t o ensure t he rigor of t he t hought process. Collocat ing t eam s so t hat any t eam m em ber can readily get face t o face wit h any ot her t eam m em bers t o t alk t hrough and diagram a problem . Collocat ing t eam s in open spaces t o m axim ize t he access wit hin t he t eam . I f I want t o ask a fellow t eam m em ber som et hing and leave m y office, go down t he hall, look in t he t eam m at e's office, and find t hat t he person isn't t here, I have bot h wast ed t im e and lost t he t hread and dept h of m y t hinking. I also int errupt people who don't need t o be int errupt ed t o answer m y quest ion. More t han j ust t im e was wast ed Collocat ing t eam s in open spaces so t hat t eam m em bers can see each ot her, see how ot her t eam m at es are doing and feeling, and hear when a conversat ion is occurring in which t hey want t o part icipat e. Privacy is easily obt ained by put t ing on headphones. Keep it erat ions t o 30 days or less. Longer it erat ions require com m unicat ions persist ence t hrough such art ificial t echniques as docum ent at ion or m odeling t ools. I f t he t im e bet ween learning a

•

•

•

•

requirem ent and finishing t est ed code is kept t o under 30 days, t he problem and it s solut ion can usually be kept in t he m ind. Keep t he t eam size as close t o seven as possible. Seven m inds seem able t o at t ain and m aint ain a shared m ent al m odel of a syst em and it s represent at ion in design and code wit hout art ificial aides such as docum ent at ion. Misunderst andings and recording t im e are m inim ized. Use a shared code library and rigorous coding st andards so t hat everyone on t he t eam can readily read and underst and t he syst em . I f m odeling docum ent at ion is m inim ized, t he code lit erally is t he design. The code m ust be easy t o read and unam biguous. Variable nam ing is j ust one exam ple of t hese st andards. Use Scrum engineering pract ices so t hat t he t eam always knows t he st at us of developm ent . Test - first developm ent ensures t hat t he code reflect s t he design and t hat t he code is t est ed as soon as possible. Source code m anagem ent , cont inuous int egrat ion, and aut om at ed t est ing suit es find errors as quickly as possible. Refact oring keeps t he design sim ple, elegant , and easy t o debug. Not writ ing arcane, heroic algorit hm s keeps code easy t o underst and. All of t hese pract ices com bined m ean t hat when you t hink you have a w orking syst em , it really is a working syst em t hat is sust ainable and m aint ainable. This is known as an increm ent of pot ent ially shippable ( im plem ent able) product funct ionalit y. Hold short daily st at us m eet ings. Face t o face, t eam m em bers com m unicat e st at us and problem s wit h each ot her. At full bandwidt h, t he t eam synchronizes it self daily.

These and ot her Scrum pract ices lead t o breakt hrough product ivit y. Every scaling pract ice will reduce t he product ivit y of t hese t eam s in support of ot her goals. Our j ob will be t o underst and how t o im plem ent t hese scaling pract ices as int elligent ly as possible, so t hat we don't t hrow out t he baby wit h t he bat h wat er.

How to Use Scrum and Offshore Development These com m ent s apply t o bot h offshore developm ent and t eam s t hat are dist ribut ed by locat ion and t im e zone. Offshore developm ent benefit s from t he frequent inspect ion and adapt at ion provided by Scrum . There is an opport unit y for t his at t he end of t he it erat ion, at t he it erat ion review . There is also an opport unit y for t his at each daily st at us m eet ing, called a Daily Scrum . However, dist ances and differences in t im e zones can m ake such coordinat ion difficult .

Regardless, frequent inspect ion and adapt at ion provide t he only benefit afforded by Scrum t o offshore developm ent , so every effort should be m ade t o com ply wit h t hese Scrum pract ices. One of m y cust om ers has five developm ent sit es t hroughout t he Unit ed St at es. This is a reasonable t im e- zone difference and num ber of sit es t o synchronize t hrough Scrum . However, t he cust om er also has developm ent sit es in Finland and I ndia. They are invest igat ing opening st ill anot her developm ent sit e in Bej ing, China. Each sit e can readily have it s Daily Scrum t o synchronize it s act ivit ies wit hin a t eam . The Scrum process uses a m echanism known as a co- coordinat ing st at us m eet ing—or Scrum of Scrum s, or int egrat ion Daily Scrum — which synchronizes t he work bet ween m ult iple t eam s. I t is held im m ediat ely aft er t he t eam Daily Scrum s, is at t ended by one m em ber of each t eam , and coordinat es t he work of t he t eam s. At t hese higher level coordinat ing m eet ings, t he t eam represent at ives answer t he sam e t hree quest ions t hat you saw list ed in Appendix A. ( " What have you done on t his proj ect since t he last Daily Scrum m eet ing?" , " What do you plan t o do bet ween now and t he next Daily Scrum m eet ing?" , and " What im pedim ent s are in t he way of you m eet ing your com m it m ent s t oward t his Sprint and t his proj ect ?" ) For larger organizat ions, m ult iple levels of t his coordinat ion can be used, wit h progressively higher levels of st aff m eet ing less frequent ly t han one day. The t im e- zone differences m ake planning a daily synchronizing m eet ing ext raordinarily difficult for t his organizat ion. Offshore developm ent violat es alm ost every ot her Scrum pract ice t hat provides high product ivit y and qualit y. This isn't unique t o Scrum —it 's a problem for any developm ent process. For inst ance, Scrum uses increm ent al developm ent , wit h each it erat ion developing a com plet e slice of product funct ionalit y. Offshore developm ent can be done wit h t he developm ent of requirem ent s and archit ect ure at t he cust om er sit e, and t he det ailed design, t est ing, and coding at t he offshore sit e. Then accept ance t est ing and t he round of bug fixes and change orders t akes place. The cust om er m ust fully define all t he requirem ent s up front , building an invent ory t hat m ight go obsolet e as business requirem ent s change. While t he offshore developers design and code t he applicat ion, t he funct ionalit y also m ight go obsolet e and becom e unneeded. Anot her t enet of Scrum t hat offshore developm ent violat es is t he abilit y for t he cust om er t o st eer t he proj ect it erat ion by it erat ion, based on an inspect ion of each it erat ion's working funct ionalit y. The

cust om er ensures t hat t he t op priorit y funct ionalit y is developed first and m ight choose not t o even have lower priorit y funct ionalit y developed. Wit hout t his frequent collaborat ion bet ween developm ent t eam s and cust om ers, m uch t hat t he cust om er doesn't require m ight be built regardless and t hat which is built m ight not deliver t he t op business value. St ill anot her violat ion of Scrum product ivit y pract ices is t he absence of full- bandwidt h com m unicat ion bet ween all t eam m em bers. Fullbandwidt h com m unicat ion ensures t hat nuances t hat are difficult t o capt ure in docum ent at ion are capt ured. The m om ent com m unicat ion occurs t hrough docum ent at ion and m odels, t he chance for error occurs. The larger or m ore com plex t he proj ect , t he great er t he chance.

Too Large Teams The opt im al size of a Scrum t eam is about seven people. Wit h t his m any people, expert s can be com bined wit h non- expert s t o fost er m ent oring. Wit h t his m any people, it 's easier t o include all t he skills needed t o effect ively produce a com plet e increm ent of code at t he end of t he it erat ion. One coder, one designer, one t est er, one docum ent er is already four people, so t he num ber seven is quickly reached. Fewer people are m ore effect ive, w it h som e people even advocat ing t eam sizes of t hree. I n m y experience, sm aller t eam s are effect ive only when t he increm ent purpose is rest rict ed. For exam ple, t he increm ent m ight not include docum ent at ion or t he design work m ight be m inim al. Or perhaps t he t eam consist s of t hree t ruly out st anding individuals wit h all t he skills needed. A problem t hat occurs m ore frequent ly is an oversized t eam . I recent ly worked wit h t eam s of 14 and 17 people while im plem ent ing t he Scrum process. At first , I t hought t hat t his m ight be accept able; I felt t hat t he t eam s would self- organize t o m ake t he size work. They did! The t eam s alm ost im m ediat ely st art ed dividing t hem selves int o sm aller t eam s. I n effect , t he t eam s said, " You, m anagem ent , aren't sm art enough t o opt im ize our size, so we are going t o opt im ize it ourselves. You gave us full aut horit y on how t o work wit hin t he it erat ion, and we're going t o do it . We see t he right t hing t o do, and we're going t o do it ." I t was hard t o argue wit h t he creat ivit y t hese t eam s dem onst rat ed, especially when t hey were right . The t eam s dem onst rat ed t he beaut y of self- organizat ion and em ergence. They det erm ined a flaw in t he it erat ion set up and correct ed it t hem selves.

But what was wrong wit h an oversized t eam ? When I work wit h a t eam of seven people, I can see t hem bend forward t o st art sharing ideas. I see t hem exchange t hought s, work t hrough problem s, and learn from each ot her. When I observed t hese oversized t eam s, such an easy int erchange wasn't possible. For st art ers, t he room had t o be oversized t o hold all t he people. When som eone at t he far end of t he room would say som et hing, people at t he ot her end of t he room had t rouble hearing t hem . Because t he num ber was so great , side conversat ions t ended t o spring up; t his added t o t he difficult y of hearing what was being said. So m uch was being said and so m any ideas were present ed t hat it was im possible for t he various t eam m em bers t o keep t rack of everyt hing t hat was going on. A solut ion t o keeping t rack of everyt hing could have been docum ent at ion. We could have required agenda, t im e slot s for present ing ideas, t aking m eet ing m inut es, and providing m eet ing report s t hat everyone on t he t eam could read. But t hat would undercut t he value of face- t o- face com m unicat ions and t he im m ediacy of int im at e int eract ion. I t would also have im posed an overhead on t he ent ire process—exact ly t he opposit e of what Scrum prom ot es. The larger, 17- person t eam spot t ed t his problem it self and divided it self int o four subt eam s. These subt eam s worked on part s of t he funct ionalit y t hat were as ort hogonal as possible. Norm ally, parsing requirem ent s t his way is a Scrum Mast er and Product Owner responsibilit y, but t he t eam proved t o be equal t o t he t ask. Because a perfect ort hogonal solut ion, wit h perfect cohesion and no coupling, was im possible, t he t eam —on it s own—devised a solut ion t o keep it s work synchronized while m inim izing collisions. Each t eam had it s own Daily Scrum . The t eam t hen held a " Daily Scrum of Scrum s." Represent at ives of each t eam m et daily aft er t he individual t eam Daily Scrum s t o synchronize work bet ween t hem . They self- organized int o self- coordinat ion. The t eam s present ed t his approach t o t heir m anagem ent and m e—not for our approval ( because t hey were using Scrum and were fully aut horized t o devise t heir ow n solut ions) , but for our inform at ion. I was am azed at t heir creat ivit y. Not only had t he t eam devised a workable solut ion, but also it was t he sam e solut ion form ally docum ent ed in t he Scrum m et hodology for scaling developm ent proj ect s from t he sm all t o t he large. Except t he t eam had never seen t he Scrum m et hodology. Working on it s own, t he t eam had reached t he sam e opt im ized solut ion wit hin t hree days.

Virtual Teams Instead of Offshore Development I recent ly read t hat over 70 percent of all I T organizat ions are planning or already engaged in offshore developm ent . I see m y share of t his because m any of t hese organizat ions are t urning t o Scrum and t he Scrum process for m anaging com plex proj ect s t hat Jeff Sut herland and I developed in t he early 1990s. Through Scrum 's it erat ive, increm ent al developm ent pract ices and daily st at us m eet ings, t hese organizat ions cont rol and coordinat e t heir onshore and offshore act ivit ies. I am concerned wit h offshore developm ent from a Scrum values st andpoint . Aside from t ilt ing developm ent pract ices back t o cont ract s, docum ent at ion, and fixed plans, offshore developm ent reinforces t he t endency t oward wat erfall pract ices. The business dom ain expert s are in one count ry, while t he t echnology dom ain expert s are in anot her. Analysis and high- level design are done in one count ry, while det ailed design, coding and t est ing are done in anot her. The best use of Scrum t eam s in offshore developm ent requires t hat every t eam w orks from a com m on Product Backlog, has all t he skills t o build a com plet e increm ent , and perform s t he com plet e it erat ion of all developm ent act ivit ies. Developm ent act ivit ies are not parsed am ong t eam s; Product Backlog is parsed am ong t eam s. Cert ified Scrum Mast er sessions are used t o im prove t he skills and pract ices of Scrum pract it ioners who serve as Scrum proj ect m anagers ( ht t p: / / www.cont rolchaos.com / cert ifiedscrum ) . At a recent Cert ified Scrum Mast er session in Milan, I t aly, t he group kicked around t he idea of Scrum versus offshore developm ent . We were looking for a way t o m it igat e t he dam aging effect s of offshore developm ent t hrough Scrum pract ices. The conversat ion st rayed t o Open Source, a m ovem ent for collaborat ively developing free soft ware. Scrum has pract ices and rules for it erat ive, increm ent al developm ent of soft ware. Open Source has pract ices and rules for collaborat ive developm ent of soft ware by m any individuals who rarely see each ot her. The Scrum Mast ers wondered if m erging t he pract ices of Scrum and Open Source wouldn't lead t o a Scrum solut ion t o offshore developm ent . They wondered if t his solut ion wouldn't be m ore flexible and in line wit h Scrum values t han t he m anner in which offshore developm ent is usually pract iced t oday.

Open Source values are sim ilar t o t hose em braced by t he Scrum m ovem ent ( which you can see in det ail at ht t p: / / www.agilealliance.org) : " The basic idea behind open source is very sim ple: When program m ers can read, redist ribut e, and m odify t he source code for a piece of soft ware, t he soft ware evolves. People im prove it , people adapt it , people fix bugs. And t his can happen at a speed t hat , if one is used t o t he slow pace of convent ional soft ware developm ent , seem s ast onishing. " We in t he open source com m unit y have learned t hat t his rapid evolut ionary process produces bet t er soft ware t han t he t radit ional closed m odel, in which only a very few program m ers can see t he source and everybody else m ust blindly use an opaque block of bit s." —from Open Source I nit iat ive OSI – Welcom e, www.opensource.org One of t he largest Open Source sit es, SourceForge ( ht t p: / / www.sourceforge.net ) has over 64,000 act ive proj ect s. Each proj ect has it s proj ect adm inist rat or, w ho ensures t he int egrit y of t he proj ect work t o t he proj ect vision, ensures t he int ernal product int egrit y, and form s and guides t eam s. This role is sim ilar t o t hat of t he Scrum Mast er. St aff for each proj ect is select ed by t he proj ect adm inist rat or from his or her pool of usual suspect s—professionals who have previously successfully worked on proj ect s wit h t hem . Addit ional proj ect resources are select ed from online Open Source j ob post ing boards. On t hese boards, int erest ed individuals can express a desire t o j oin a proj ect and t he proj ect t eam can select qualified applicant s. As t eam s form and m ove forward, t he proj ect adm inist rat or serves as bot h t he Scrum Product Owner and Scrum Mast er. The Product Owner is responsible for set t ing t he proj ect vision and priorit izing t he work t o deliver it . The Scrum Mast er is responsible for adm inist ering t he process for developing t he soft ware. The t eam m akes progress based on individual com m it m ent s from t eam m em bers, who oft en hold fullt im e j obs in addit ion t o t heir Open Source proj ect responsibilit ies. We wondered if t he concept of t he Sprint Planning m eet ing and t he Sprint Review m eet ing would help organize t hese proj ect s int o regular it erat ions t hat increm ent ally deliver funct ionalit y. The Sprint Planning m eet ing would allow people t o com m it for t he next it erat ion based on availabilit y and skills. The Sprint Review m eet ing would help t he t eam

figure out it s real progress and opt im ize it s com m it m ent s and com posit ion. As a result of t hese m usings in Milan, t he Cert ified Scrum Mast ers are developing a new approach t o offshore developm ent , which t hey refer t o as " Virt ual Scrum ." This approach will im plem ent m any of t he ideas expressed above, fusing Open Source and Scrum int o a Scrum approach t o offshore developm ent . The offshore developm ent can eit her be rapid and focused, using full- t im e t eam s, or t he developm ent can be asynchronous wit h part - t im e t eam s locat ed in various places around t he world.

Forming Cross-Functional Teams A cross- funct ional t eam consist s of people from all t he disciplines necessary t o accom plish t he work. The ent ire t eam , not specific individuals, is responsible for t he success or failure of t he effort . Scrum developm ent t eam s are cross- funct ional. They are responsible for t he creat ion of an increm ent every it erat ion. I f t he increm ent isn't successful, t he t eam has failed—not individuals in t he t eam . For inst ance, if user docum ent at ion is part of an increm ent , t he t eam collect ively is responsible for t hat user docum ent at ion being com plet ed as part of t he increm ent . I f it isn't t here, it isn't t he fault of t he docum ent at ion person on t he t eam ; it is t he fault of t he ent ire t eam . As t he t eam m oves forward during an it erat ion, it s m em bers plan and work t oget her. They lay out t he t asks t hat each of t hem will perform t o successfully build t he increm ent . People wit h part icular expert ise t ake a lead role in t hat part of t he increm ent const ruct ion, such as t he people wit h design expert ise t aking a lead in how t o describe t he increm ent 's user int erface. The t echnical writ er will t ake a lead role in figuring out t he work for building t he user docum ent at ion. However, it is t he responsibilit y of t he t eam as a whole t o com plet e all t he work and for t he com plet eness of t he ent ire product . I recent ly saw a t eam where t he t echnical writ er felt he was behind and let t ing t he t eam down. He felt t his way because t he user docum ent at ion wasn't com plet e at t he end of t he it erat ion. He felt guilt y and was working overt im e and weekends t o m ake up for t his. This course of act ion was wrong and represent ed an incorrect underst anding of t he nat ure of a cross- funct ional t eam . He is only a m em ber of t he t eam , and t he t eam is responsible for building t he ent ire increm ent , docum ent at ion included. I f overt im e was needed t o build user docum ent at ion, everyone on t he t eam should have been

working it . Then everyone on t he t eam should have discussed how t o avoid t hat crunch during t he next it erat ion and how t o st art addressing t he docum ent at ion com ponent of t he product earlier in t he it erat ion t o avoid t he last - m inut e crunch. Cross- funct ional t eam s usually have t o be built . Most organizat ions don't already have t hem . Building such a t eam is difficult because it usually cut s across several em bedded underst andings. The first underst anding is t hat t here are areas of funct ional expert ise, such as analysis, design, program m ing, t est ing, and docum ent at ion. People who follow a career pat h in each funct ional area are t he expert s and are expect ed t o be t he only people who perform t his t ype of work. Ot hers are deem ed not capable of perform ing work out side t heir area of funct ional expert ise. To exacerbat e t his problem , m ost organizat ions are accust om ed t o using a wat erfall m et hodology for soft ware developm ent . The analyst s analyze t he problem and describe it ; t hen t he designers use t he analysis t o creat e a design, t he program m ers t ake t he result of t he design and creat e code, and so fort h. The consequence of t his is t hat when a cross- funct ional t eam is form ed from people wit h such a funct ional orient at ion, t hey operat e as a m iniwat erfall wit hin t he it erat ion. The analyst st art s t he process, perform ing t he analysis of t he problem . While t he analyst is analyzing, t he ot hers t ry t o find t hings t o keep busy unt il it is t heir t urn t o act . One by one, each get s a wat erfall t urn t o apply t heir expert ise. Finally, t he t echnical writ er get s t o st art t he docum ent at ion, usually wit h no t im e left . I help t eam s becom e cross funct ional by asking t he analyst how t he ot her t eam m em bers can help. The analyst is surely t he expert , but how can t he analyst direct t he ot hers. By direct ing t he ot hers t o do analysis, t he whole process is sped up, everyone is aware of t he result s of t he analysis, and t he need for analysis art ifact s is m inim ized. I f t his shared work occurs t hroughout t he it erat ion, t he progress is m ore rapid and cross- funct ional t raining occurs. Everyone pit ches in. The t im e- box of t he it erat ion helps t he t eam realize t he benefit s of t his approach, since a st rict ly part it ioned funct ional and wat erfall approach usually fails t o deliver a com plet ed increm ent wit hin t he t im e- box.

Cross-Functional Teams and Waterfall I was t eaching a class on how t o be a Scrum proj ect m anager recent ly. These classes are called " Cert ified Scrum Mast er" classes. At t endees discuss how t o im plem ent Scrum int o t heir environm ent . Most of t he

t im e is spent discussing t he unique difficult ies t hat are expect ed in t he at t endee's organizat ions. The t opic of great est int erest at t his class was cross- funct ional t eam s. Scrum is it erat ive, producing an increm ent of product funct ionalit y t hat is pot ent ially shippable at t he end of each it erat ion. The people who do t he work t o creat e t his increm ent are t he people who m ake up t he Scrum t eam . These t eam s are sm all, consist ing of no m ore t han nine people. This t eam is considered t he heart of t he Scrum process, and t hey are orders of m agnit ude m ore product ive t han t radit ional soft ware developm ent t eam s. Drawing from t he principles of lean m anufact uring, t he t eam s are em powered t o figure out how t o do t heir work t hem selves, and t hen t hey proceed t o do it . That is, t hey rely on creat ivit y t o generat e product ivit y. Aft er all, who knows bet t er how t o do t he work t han t he people doing it ? Scrum t eam s are cross- funct ional. This m eans t hat t he t eam consist s of people wit h all t he skills necessary t o creat e an increm ent of funct ionalit y every it erat ion. I n m any inst ances, t his m eans t hat people wit h analysis, design, t est ing, coding, and t echnical writ ing skills are put t oget her int o t he t eam . The t eam select s how m uch work it can handle for t he it erat ion, and t hen proceeds t o build t hat funct ionalit y. The great est im pedim ent t o t eam s working t oget her is t he legacy of t he wat erfall process. A t eam t hat is used t o wat erfall developm ent works in fit s and st art s. The analyst does t he analysis and creat es a requirem ent s docum ent . The designers t hen t ake over and writ e up t he specificat ions docum ent . The coder t hen writ es t he code. The t est er t est s t he code. And, when everyone else is done, t he t echnical writ er st art s on t he online help and docum ent at ion. While each person does his or her work, t he rest of t he t eam sit s around, wait ing, doing busy work, or cleaning up previous increm ent s. The proj ect m anagers t ell t he t eam m em bers t hat t hey should act cross- funct ionally—t hat t hey should forgo t he t radit ion of wat erfall. The t eam m ight t ry t o work t oget her in t his way, but t radit ion undercut s t heir effort s. The analyst t hinks, " I 'm really t he only qualified person t o do t his, and if I don't clearly docum ent t he requirem ent s, everyone else on t he t eam will m ake m ist akes! " Not only t hat , but t he analyst has a funct ional m anager and a career pat h t hat rewards how well she does t his analysis. Even t he m odeling processes and t ools reinforce wat erfall, st art ing at t he high level and gradually decom posing int o code.

How do w e get t he t eam s t o operat e cross- funct ionally, as a t eam rat her t han as a group of individuals working in a sequent ial wat erfall? What can m anagem ent do? The answer is hard t o accept : do not hing. We oft en t hink t hat t eam s consist of prim it ive individuals wit hout t he int elligence t o figure t hings out on t heir own, t hat t hey m ust be t old what t o do. I f we flip t his belief and rely on t he nat ive int elligence and m at urit y of t he individuals t hat m ake up t he t eam s, t hey alm ost always com e t hrough. I t is hard t o wait for t his self- organizat ion t o occur, but pat ience has it s rewards. The t eam st art s t he first it erat ion in wat erfall m ode and is disappoint ed at how lit t le it can accom plish. Usually, at t he end of t he it erat ion t he coding is incom plet e and no t est ing or docum ent at ion has been done. The t eam t hinks about t his and realizes t hat it would be m ore efficient if t he analyst were responsible for analysis but used everyone on t he t eam as his or her " legs" t o get it done. By doing so, t he t est er is aware of what m ust be t est ed early in t he it erat ion as well as helping wit h t he act ual analysis. Also, since everyone is doing t he work, no docum ent at ion is needed because t hey are already aware of t he requirem ent s. And t his proceeds from analysis t o design, from design t o coding, and so fort h. The ent ire t eam is responsible for t he result s of t he it erat ion; funct ional specialist s t each everyone how t o help wit h t heir area of expert ise, m agnifying t he product ivit y of t he t eam . Consequent ly, everyone on t he t eam becom es cross- t rained and can fill in for one anot her. Most proj ect m anagers are used t o t elling people what t o do. I f a problem exist s, t hey st udy it and direct people t o fix it . Selforganizat ion is m uch m ore difficult . We m ust wait for it t o occur, and it can't be hurried. Som et im es we can help t eam m em bers have insight s t hrough anecdot es, m et aphors, or j ust conversat ion, but we can't m ake a t eam do som et hing as com plicat ed as cross- funct ional work by direct ing it t o do so. The proj ect m anager can help t he t eam get t o t his point by quest ioning it : " Gee, would you be able t o do t he analysis fast er if everyone on t he t eam helped, wit h you direct ing?" But t he proj ect m anager can't t ell t he t eam t o be cross- funct ional; t he t eam m ust realize how t o do t his and do it t hem selves.

About the Author

Ken Schwaber co- developed Scrum wit h Jeff Sut herland sixt een years ago. Since t hen he has run his own soft ware com pany using Scrum and helped m any ot hers use Scrum . He is a signat ory of t he Agile Manifest o, and founder of t he Agile Alliance and Scrum Alliance. Ken has been in t he soft ware business for over 35 years. He lives in Lexingt on, Massachuset t s.

Quotes " Scrum is changing our int ernal currency, t he act ual words we use t o assess engineering invest m ent s—inst ead of t alking about hours worked, act ual hours vs. planned hours, num ber of com m it m ent s achieved, proj ect FTE, et c., we're t alking about business value delivered. The m ost st art ling consequence, as Ken point s out , is t hat Product Managem ent is now report ing t he st at us of proj ect s, rat her t han engineering. Adopt ing Scrum cont inues t o be a painful, im pedim ent - exposing process—but we're delivering m ore business value at a fast er rat e t han ever before." Pat McDevit t VP, Global Engineering Tele At las " This is t he book I wish I 'd had at m y side when Yahoo! was first st art ing t o use Scrum . I t 's t he insider's guide t o t he profound t ransform at ion t hat Scrum can help an ent erprise achieve. Anyone considering Scrum for t he organizat ion t hey work in should consider t his book." Pet e Deem er Chief Product Officer, Yahoo! Research and Developm ent I ndia