From 94e0dd712d1d1f429392b3762f145dcd8d75892c Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Fri, 18 Jan 2019 16:31:24 -0500 Subject: [PATCH 01/30] starting book proposal --- book/proposal/proposal.md | 85 ++++++++++++++++++ .../design thinking for developers.key | Bin 23987139 -> 23990041 bytes 2 files changed, 85 insertions(+) create mode 100644 book/proposal/proposal.md diff --git a/book/proposal/proposal.md b/book/proposal/proposal.md new file mode 100644 index 0000000..ee0f5bc --- /dev/null +++ b/book/proposal/proposal.md @@ -0,0 +1,85 @@ +# Proposal for Design Think for Developers +### By: Cory Gwin + +## Overview +The agile manifesto states we should prefer customer collaboration over contract negotiation. As developers we often leave the customer collaboration to others in our organization, leaving only short user stories or issues to gather context. This leads to a number of problems including: + +- Downstream communication issues. +- Misunderstood requirements. +- Incorrect implementations. +- Developer frustration. +- Scope change or creep. +- Lost context over time. +- Code that does not properly convey intent. +- Unintended consequence of poorly modeled data. +- Incorrect prioritization. + +Our workflows and structures create communication barriers we must break down in order to move our implementations closer to their domains. As developers, our goals should include moving code closer to the vocabulary of the domain. This requires understanding not only the problem being solved by a feature but also, more broadly an understanding of the field we are working in. + +Design thinking offers a toolset for gathering insight into the domain that can not only help engineers understand a user's problem more fundamentally, it can also offer byproducts such as: + +- Providing a better understanding of the entire domain. +- A clearer path to a domain language. +- Understanding problem nuance. +- Gaining lessons learned of the user. +- Clear prioritization of tasks. +- Indetifying focused solutions. +- Providing insight into how an implementation may evolve. + +Following the path of a team replacing a legacy application with a new application this book will explore tools that can be utilized to break down a domain and better communicate with domain experts. The book will introduce a number of design thinking exercises and explain how they can be applied in different scenarios to help agile developers craft clearer implementations. + +## What this book will cover: + +- Introduce the concept of design thinking. +- Introduce the following design thinking methodologies from the perspective of the developer: + - Stakeholder mapping. + - Interviewing. + - Job shadowing. + - Rose Bud Thorn. + - Affinity Mapping. + - Experience diagramming. + - Importance/Difficulty matrix. + - Feature Voting. + - Creative matrixes. + - Technical prototyping. + - Story boarding UI's + - Stakeholder validation. +- Introduce domain driven design concepts: + - Ubiquitous language. + - Context bounding. + - Domain events. +- Outline effective tools for using design thinking to create ubiqoutous language, bounded contexts and domain events. +- Outline rules for effective design thinking on agile teams. +- Discuss ideas for bringing these methods into teams that are not familiar with design thinking. + +## Audience: +This book is suitable for developers, managers, product manager, project managers, designers and anyone looking for methods to bring implementation closer to a domain. + +## Why is your book different? + +Design thinking books are often aimed at hard D design. This book will focus instead on using design thinking tools to create a different sort of outcome then is + + +## Why we should get excited about your topic: + +In the Cathedral and the Bazaar a number of important ideas where set forth related to working closer with our stakeholder: + +1. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. +1. Release early. Release often. And listen to your customers. +1. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. +1. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. +1. The next best thing to having good ideas is recognizing good ideas from your users. +1. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. +1. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry) +1. To solve an interesting problem, start by finding a problem that is interesting to you. +1. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one. + +Interestingly it contridicts itself pointing out a major issue with the way we develop software: + +1. Every good work of software starts by scratching a developer's personal itch. + +The implication here is that we do not know how to collaborate with our users in the same way as when we develop to solve our own problems. + +This book makes a case that in order to solve problems we need to move the solution architects closer to the domain space. I believe in order to replicate the success of the open source movement in a broader way, we need to find ways to bring domain experts together with solution architects to create a new way of interacting. If one is to believe "We are as gods and might as well get good at it" then we need to focus on creating tools for others in a manner we ourselves would accept. + + \ No newline at end of file diff --git a/workshop presentation/design thinking for developers.key b/workshop presentation/design thinking for developers.key index 90c8248c3eb68938c4ab17123b079d1067651a44..bcd8f6e4109c541ddc2f1093224ee97437a64d1f 100755 GIT binary patch delta 13156 zcma)ic{r89-~KblkwY93vL1xUe(VxLNRnt(LfIWl+E6$xgO-D6SD92uk~V}miAW2P zC6cw0vX_1P&GCM(?{&Suzh2k%%ze-O`OG}?%zU1iXT~Xyd$II->Wif(Ab=#u1<8;b zE`dCd0(l`HTnhQ20Hi`eC5VYnQMKv5_LS3q$n0VSanl!h{p24$ffl!q&!0#t-b za1~UBDsVMag=$b8YCuh>1+^g^>Oftn2lb%=G=xUb7_NaPa4j^2X3!k2gBH*dTEX?u z8rncxxB=S1jnE!$f(~#qbc9==6Lf}K;WoG(?tnYtF6aVx!#&Uy?uBm99eTiha6j~f zUeFu*Kwszw{b2xPz(5!TgJB3f07KzHcnBVbN8nKy2E$I2lHV8d;tq#5iEu;VF@gSZ1@V6 z!Pl@HR=_u~5>~;tuo}LD@8Jjd5!S$3_zBj*diWVOz(&{vo8cGO0$br%*apABcGv+s zVHfO%J@7mH0e`|?_zU*I-|!FYhXZgB4#8nK0!QIr_z#Z3aX0}d;S`*PGjJBp!FjlF z2Cx8NkpPPeu*iVL4OmM6iwCeMfW-?~e1NqSu=oK>0I;ZlB?wqTfVB*;gaKh zC}4>J)(XH92P_G|k_0R%z>)?m8Ni|emMmb&0hT;qtpqFuz)}P(CBRw*SjvE<0$8g7 zOBJxx081UPGyqEzu(SY68?fkrr2|;HfTagm`haBsScZUQ1X#v^wFa zV3`BfI>533EK9($0<86bWer$1fMp9<8vx4=ur>mgJz#ADEC;~a3|NkUwFR)80LvM$ zwgT2Rz}gO2I{<4ZVC@1d7r@#LSbG4=6|nY#mu`R*LFF}3*}TnjJd$Bc5DZ%+6yXN+ zN&32MddqI0#mzn%?FRDXnI+3znqLZr4L4g2k6*v{+)VD-i{j)Nr;eCZ-i_DfN2iz5 z#D|R54wQ-Jsczip@UCg+SfiR&=>nl3ndj>2d_L^xzq(?!hQ{x@-XZ?F*9F1~>LC{% zTJU{6*7?t<)~L_vl;Fnc>@LR&6ze8C+#Z)1{!T68NByIp#d8BUHvg_?x_;H>`=Yv~ zO!`%(<%hz)%YVkSmPgm7uw!cOX0`1q>3$<~^|IKdPj9=`4B}lj3hi4Glst9P1ulOzxX!gWtdYx@Dwxj&mz}%s5e=AGcH!sRKH$1MhV)yr=1>#h0&(q66=f1A& z8(sgz^=0(d4G)X2tyI%png3IV_|Thkm>#}BbbjoJRT>`83x8(e8*2PG=ApOGF0+r^ zCHXD$J5JVh{q<_id6`^TrcbY4{jGBQ-RP9;Xy)+Iwk+QxK@v9b;Y8iH$eg|(%+k!N zk+M*|cz*h`qFD6@ymBhSE1?4o{m5F24}BR*#UQ5`!DK+PX_$Hbx#F zPF*10TxnlbA95!q?Q!YnriL$T{gqo|>MQ@gGmcg|vtgI7)V$}(tG{>GzUmMRFP~ZQ zdb+J>N3!PUfvdX%olDBCgmnXBT~&gZpEvfg56rcNKCTwmpNny121&VneN=2Z7ZP=5 zzCF9($>o74Wc%Q2UJj#e3JeS?_}D3U`+a4QD5~vopN7Nrz5I7)?~OMN@-gJsSvmSO zLcHc^k5QGWT7S#DTBK}hl}p{2R9}dB!6V7Rp92~{;=HcRn7tBP;^I{=14^R_O(Hfl=q;>I7h-u~&YnkJ_)64B*)yspm6z)nGy?Yt8)h#;OE^_E;VNq?U@Tp6F_H`M>5l4fV zvpL02MsA6mHu`y`G;rGE&N&qVUtBY9a2Re{Aj(wcmxK?E(~%Vuxud=r4)A1tsZyxUkufug zOfkhc+U{KGczYz{>|F$*K39P^lokqs2TFT+cs0PqLcqYjNzHPgEhPJ zlQ$3TxY77*qPMJ7w)|+*Bh3MQyCV(`m+a^-qlRDKHQ83kL8exZ| zV@`ToAe|qH9~J1o?u~9HL}yEISJ|3(rnj$|%P!S%b?OmogGOMIDE|)8wRa83kCCmF!?Rq>&=c7L?5YM$@I_!rX+Kyh` zDyS)Sym_5;Qe*IzYtMc?UVeO+VSOHdA-ADKTn}?pBtl#nHXQH zJG>;DR?w+7b-1tWL(*MYjbY~5W6@?~(;Cq{ue-BsjNvUiTi@gQ)APz@&2Q@Bcdk`Z zB2RptP3&*((RwXlScSyKWS35U-DrP}w&KXnnr|$lBcX}KH^0*wXEP!l^9twiY~imZ z9PZQP^kcW%dqS166R%XUjIpY5<|_OM`EMSy`?pI@cC1!gZo4A&i+Wbl<^9LfehCIo z4vkjLifVOMp66jn_4JnSiO3wT%sQe}Sn_Vb{>BNf1ns-1@Y6qKx#j1k`L0K)ZoA88 zZ*^5I+gUgCM*YNkS*n>%RhUn3h>WEr>&>BNu7q#X%`uT%C&!|?Z^YH93tnaV74jcA z_)0o-;M^3?>r%6e<<4iWpTBqh`_qfBoGwI_s9wpsU!C!L`M1`#;J=>_dp>H{VS={i z^U?~v#b$#MtXoPVwVqFheGPr$$Wmc!fEB8G7nE*YI)v~*2JpXCE*86^IHX; zf@DMAqfv7Yrj(R@YHc;M;i;b$3bvNRJg?pPt4y!N_!^{Zlzm86G3tHn)4FCtl(B8t z`uouy=g-geo)=gYdZjvEd)!aBG1rXd&t>ahvuyJ}nt!D(>XkxFwDShFTGt-aKg`Fc zdv+9d-xA1Z4Bm8m(AjbOcaQlaFNgd5ecY6F%4(#adrt0|txcMB89&`^^6ZHCIfn&8 z=kx_Ck5!du?T(JKnkf^mg+;-Srpzxq+&CdGWv%d+->SsUTz8>q-s;yKyu3TcmUlgh zTa_@O{AN{mf51lDY3=-XbJw!gPO*>6Go$yusMXI?UHf};pNqR&QMz|;&YY&_jsk^q z&%%y=&WQguzI#vO-I`I|b83GCW6*F`NTk~BJ(J^0?cClCM*PrqjqtkL)|z`+G2oqx zq^$AZ22sM(C^*+?GHQ6M({SO)k^$A~D=GsnL3zAk5hE>6e9pQ)eI9>MNd_=(?oIj1b8h{^nv=X16!0X(+U@`*MDELL}EXXAhw-`?=x9_y2O-)CI5{(KYm)H{W{!JwwY;I(VX<1cuh@GhRM zo??5tl&de_u+=J{=*XMWbaiLLTVX4&<e{BOyMvRy7k|_5JR|O# zY+H0aWu>c~WQ0@IPaq~*{ry~(JI{RW__3(`wDb-TT{k~&tl8rgpKK)q5 z?5m!^pZTuzJ(nG7R-2oBT_AQgl+Q8JYWnWm<+X%;{XF<-^5?nfuTH~`WlIzDOHb=x z(y_T{8^n}px-)MNukzBplxBO+{MdSC)XZZIjahMJUbFy@_U-UB8X6uBK21ILI<@3y z_Cdm%6TDJvI`Y^@KT4<;ddBo59J|innY%i(FRZS#-TmAef8XKMq|4{ez~6;x@|b#{_M6XjN4UuHvg-hs(eALqEP}wePwxj=8+0^#k*6~6q{tCqdicPcao z_dz?l)D5Gg@jItePb`sY$Q6>H=JEL z@hp7#Yv#Pb@LaNSLX&Zbrlxqcr0SDbUk;qO_&Q55Y-LI9riQi3-42%SqQB|+nOT(d z4JY585_-3Va#Hbx?yJg!RC>zf)ho{Nb{oGIOd%KPsLdO)|0&Jgjb8KHO@BDhod2a- z(PwKD?-xOD_#g19Dn-wJhdsPFMEVCpPm7n8-w6K{@Jz4_U=z58jT z`bGI&@|6aw#eG|K6U?^DtgCU{_|GxcTu`n)a?M1|jZJjIPUdZO?wxo3pEF8sipAY< zyZO7i=B^q4NG@#R9m-ErqBxDMDm~b!*ZZXK;Jf1^sC=rqFPPm~o~8KrMeEt32*F?- zp`Gt+Uv2%vEE>yu7%Haw?!oys)@W6WZLb@8z9%Dety+*`c+=^OfZDZ`s9-#ov(I>So1 z^-)ve<*J-;x10>~xV%aI;%#)+Y}sam$1~+-ZS$h<-Iy71t_LJ<%D(A{ZI_$e)3Y>J zfUzOk*{k3NnOC8j?@NF9RNNLum2cCa;>&MRLfbsq8G^m;jk5hc!xuZ_1`21)+a?{m zw=K`l4e_eEdZsS(s(vBY!CS@Wuhneswvg!2pH!Z4n}5Sz#`Ml*P1lxxw2S^4;_*kL zN4LfhN|>`(P$%F>vKX>bXHmR zW*pE7pC0*_Yg3|TQc)$~Hs7DP@AFHIwD*DXiVF0dt;d)rjC%gg2E_lHjy`wQfZSDA zO-|St)x;xn#(38B&#A%@mUF<;h@}xhpOQX>p5QT0UJ!i<}Fj8dn!> zcXlYf`mg7E%zcnvMRNGbWsg#1<)RX-3N@9^iMu2$5SOmrGSo8JMz4M) zaEmcxz*y=pmYeH-UQJ@Zi!<|?o$|FDne6#~@30fi`*kc{d4=2_9-6d|+_^wl*w@Z1 z5XuXLsKrRwc_yW-QOjt7$QWggY!8vT%APtnKQZ}dYFEsu4_C&T=Sge-$m<;czRPWxlrY?4f904m9|>aDMm)&+~toqANMJ2O=eX87)`M$ z2=9a&n#}C!{2zY?7Atj|e>3tdK-YNA&+gWZ-|;t<&A!N7AkN*MWWUKYZVWN*or^@X z+x?zQ1vpM<&SxBa|JR^-sF7Vh$8--JJlgRrI_^~pZ&JltvPl<;X~wN&?(x1CRn zzEJyVU_?W=o0(e?FXd2FfB0j-Zxt<@me|=RH#}bzw-SW!Y@pR|Yp-lJB&z=m#&#ZAbK%rr@48`Mn z4yOd}uKuz9qhCRc&()&}&MaX=1!4P3gs1+eJ<-*rn#`#6ePI(pXS#W{$Dh!)UIA8+j{kyDU+#eJ~?(+Qu$5DSu+`XSeIA)BD&#* zV$hGT#In(6gI-38-juatcM`PJf6o0-4#C6BGbR&BW4sSIa(T9Af#CY*n;u@(8J|;{ zo2eC(M`7+SXpp2xXf3t+zPV{U*@#*(b=uJ6DN!lz$+ha&T*{HcyVtu*u5`S=m9}L1 z-JWd@@qEioo@v9vYvS8_KW=(2Xc&TlpxA1~rQDQ@#D z{&T`m5{e!h_l=2MmNR*7^u23-O#4#59r_-+SG@`FJK|$x^s0x24~w7u(Y|)Lo}HA@ zE`_&WXLeQ?-g~cJxA7e17q9rMzE`6ED$}~o$D6E++sHg+@K*r=$~kNq|~HL zR^Ne)^lqc7>yiWKbWhnts7IGx{ui9qm0sYev&*ph(=ox#jAGu?5BmzMTYJ;}4jp{s zR@KXsFv}ZyH#~gTK!<)8_a$oRm*~Cz(R`77e(mn!j8EM=xIM^+Wok@K_@=Yp?3@;j z|NSusl<3@E$&?T@-&mX;-n+hNdwyR0ICY7qDt%y2mXZC=OsitSE0qp*cgrK)heul( zM=#iDpJ?uFu9RJ3l`(WvYw(A(?D*B$b#rQCGj6dfKHn?k;(O<)AUfPpkx1<;l`B47 zzEjtBMeC!L))5rGcm-}UvPg}35Gr~j{!_O1Y|h=W_wy8{@{Hc3AP&sav$hW+ZIfbe z-ECW6xAL~9UK%qz?Mv6jN3Wxu53~%p9a$i_*~3+*^--eOvE~!|HmGapWivL(tGn!P z6TN=piW0qHu5IT4>UW>f_<}d%#?jpE;URAf54bu$wD#A3zlWvfwoJA9@x_a!tKu!H zOb)fO#TSTRrt-zAQhIU2&`$F}A9-esP53$!ZgEnntx2tdMcwQ4A^Y~IflvR84#lM^ zf8GCe!qe|j^KYgxZRMmz*W9sRn{8WusNJm8-fXhWHEvc{EL$P2K9Ae)$xWRL<)$_! zGqkaZ!L&|F&RB%UXoG0rsU_yqmBj-~%Py`j-s97)%`469DXe6^E}7m{J(?*NF{bk% z@}r&Xjia(p#j^Ff@?@MM@7z00I_PLgbrjD%G#NHy5Wdy2#PI5{-O*31xNCne8!5;v zVGMkURA%^`{1QEuu#@YD`+Uh!u~b^Yaj_KFVAF&pT|3pc+dTZ@{9Yv|Fj{Mtk(W^0 zedP&5IB;7M;iU2=Mi5;kpZvk;{fj=2 zRZcELdp!Mtk!ex_jgL&hsXXB37nY)M@k&MB1ge6`3ABp|v`Y!J%L%kA2{a{w5VBC^ z6Cm)PDB#xHO{QQ2`h@GSQ%mN)NnGS!vJQJs0uVzY2s5h-B;pncglxD?A|8;)6kLT6 z1=oqJy!?Tl_$FZr5F*5Z3ZV^*h;_sUVhgbhc=0D*z-IOZuK;i$On~z=Z%u8|zH<}A zcjQqQ07L{04UBd4H2uT&5uMybwFq0gEdV%k$;tv=varNur?piiRsJ7l8I}uXi6>}R z6KH354E&>AhR{r-nF10%F_EG(Tu40my4?iK33{)hdJ?AP=R z3DWWvSa(3nDkLcANU*=>zQg{(z8Z)94u%}@_0#YS@$yy`ji1*0Va7+ISmA3ozCt%H z;a;0zX(@?0!N)_{EzCt(0NO$aFc0Mx;NJpvOLH@6yC~Q~rr@SwzXN;}N+{0ZR%))} zCdAYBr>)}-rYxZx5a1_5OSTX~z=~g(k20L|;{H0mReXxZbbV_BJ?r%vHu^UD8hS>$ z)*8m^bqzJNE!J!68tUsAYwKAGi_v*0`0-5TaPe3fC&B|bT{FnXG=o)&uR@yq&`r5|2mKMSWej1_qy8$8JRpKVbMY&^fevKHHv~O?NdQpO) zypgK@!A}t4M6A@3vI63cK_K~u0+}EJ#JGsJS=j{N$PsQK;_aG1GWo4#Fc!~yi*YV8 zkN~{=!pkXj8iu)w4yru&EbdywC&>5<@pBEaUtabn-?P~0P7=Rsv5^mVNEe$Q8@J4b z>WGnmGlh>bBjAfhe)|KFb<`;er#pH-A~`~Y5}P0+Or;3uXfILaVkOAn7{;j>;4YDu zGgBqEnl+nI$lT9GbBWf?;@m{DjtB)UBL@I6_H1VWcz$CsxNh0nZxX2^2oY2g$pDhu z556K!oFET-%27zd(vFQ|c>Dbt47+YEDYFKM)>#esjwlucVw`8kFF~Cz%P{i&?W&mg5ZS{+<|Qj&Vgt{0_$0YcAfV^dyMetGNt z7d^#3Y67#o(tXz&?k&8n`zgN({l;3c#3mw^d&jzN_Vby>ihpLCqx|Mz(2%SBDx;o{~>$G9& zG8Bc2OD-{2#!g4jEu66j&ru&n12BT*?lZtzaeJ~5UEf%ru4zx6p8)L>fO5Z`m&&yQ zg=4dppriUV!u+iBrYG>NT8 z1s+OCvwH5Fd|UeCb(bwVp2YxW%gR-Rj16>*SFRG5ou39x(*V80x|+s#H8?FwDJK1_=5?=!l(_jPzgro z)sy0sw`;r5n@tzf>LhLR^%Tqu?oWWRgaq(6lK(_4y+uDM&e+0b~J0witDQ zG&+V+5)a2^jC$Y=dWX?L=9(t?QYrYgVIs9Vf9%Egv;`n^^KAP0l=#c3!iq@mA#OLA zLLL|;*WNMLG2tVwuNoE*-o(_|t^(HR3dTKn za7Hnz^Jyt-^7761tN8RIl_v~9!=q=5(EymB=tb;Bc^DbO_Z5g%ZkpV$?_F7UuK!7I zq`pQvPZ>ZLL?R!IEL`9(#?!zTg*{_{Oq=846gpjBb6zsNL)DM6>V?shey1?nHjzO) zKBAF|lO{1cKJweA)U~>-q3{7XfCr-F7gu#2T>tB^fO%4__YL=@CSASE+Yy+FZx}8Uq@=(N~P&l zYAff9SKTRI<%$?D7~rL}j3e=k`{IW2;;Ei1r9W?L3O)Gq=h@BbPc!1w?Z~Q-0hB>M zVqjDNM^GY0eJR@8Wwct=&=H!6z{o?|I4|wfGN-knBgDPS#;5~(I4>!u6A!7g$gl`M z3kj$pKTNKI4XMQp;0L^rKgKYbp;bgZ_fF}O$G7V~OkYc<&KXI!e95h44OBYe@tDIt z4ARI&6!4M(dPrOj$gzY0#01h-Nyoo=@Uil4$3gs=x{#m+&%4s9sKZ={5u8n^WN$t#&(-p0q>qY0fp znR@l(TvG$}4!Vf#Mqmhiz$gy1(GQHp8TNgS{^$1Uuo&fL;spBB@_Ls;R51yR6IQO)EI8m_KGv` z?r3Eh11N#_Xahzkz=u*WTH_Ay#At>)T=q2s$gR7znmm2mMvcU;t8c7lc2SVFcPY_K zB`7opHM4ajCv7*{k|esB0*RIJ(@dlq8`fiqkr`RZGa<&BP8-Y0L1cN6pltnTenk zb)0wK2iaoG0rKoIjQfD}&k(s=XFoRlj(OYI4QRv^H%**VO!u>>C5f zaM6q?NEcLpNib$5!rP4Zii8BI1W^Ft~kEFgZeVAs%MiJR@>e~NrM z8NdRVv+rYE2f$a<*Tn$cB%Ubrv6}%3*9Ytqu@3h25B6>;Qrtp#WC6)yyw5uNmueHd zkM@U3o1xOGglNq|b@&t{iCx#6)R9y>B1qE}{2wE6k#j2Oj1FL2 z4|>^o7`FgCZ7dmJfMop4*D-zo-pFT=0cOBow10>JPT(4QFb0Bk>@CB1Sto&XbYPV8 zQS$_~Vw?do?54jA004pz5LAG4b{9r|Zjgco`2+DXYKB${1cEf&)C!Cjf#l(wEm_$o z{#2b9?{5Jfi6qHqWJ;@r@KV)i6e<{qS88MS1&l|@pr6en5(r)_!5@vUBm?nsagx1S zDiG`kh9bivc>0_GhloZXNWQ{Nm01R&2pn3(cj_{05h#GIc|eC?18(9Ga3?yzcA@}> zRh4ugP_#WoWMTa~NGE@h!qMhW{Kh-j23)~?U@!7Q3{P=hpbn@L;~)jsAVXXMfVe+Btq>_^d{>#U^n zA$`L@V9x8ZA4@0go|vL2oL|So@t|r@P&v+7^M~&EpNi>**g?byI|!7^|60^^4CrDA z?ZcWQ_=KKdR3TMwLS@RXKm-lpEQLe}qbW`q^(=mH3>Ttk=om@5FZBwe#E^tVg!Wdc zty)_2`*`1mvJ`sWQNFp7GjFobpriL)fr38ov9fGjME=)D`mSzKVUd{msru<@bC2Zm zcLf6{(i-pYKGv72ZDC=fZ?)dQQbU`rt4Do-N{j=6Bq>Z3wP0d{BVKMzAg~Zvzf7qY zSJs7SvAnLR1Z(D88!Yyr1w7S zTo;t@IDT1dT2p0=Kc<|ze;Hwvmg9jwHU$9*Vaed76z!nH$($DI=o*T>p`b=w6P;An ziYTUmVC!;~_4*bD7M8}=8b(G$iV!iW^B9@G@c{;5JUH{uP#Zo z6t!TokF;VGt;OZ`arG&AqT85RE*|yKc)eUa|5HxRA`s8#7jd1sB>(g1EhhWO)DlmC zYM*)neYF1@ZZv7_AYSq~HExqdBbeBdjJKdQ?HuLY33O|b9L!Da;1u4_?gbEUgBLEG zf(2DlFF&fp#ED#M>?6HNMje>gk?G(ud*~N&Ip& z%pv52wLSnj>iFQ&=ejwi_j{v!O!kpT2}q)c)1$HZ=r|_(NP6w4okO_dxP8&r*Fj(v z3Yzf&f+*}eE=l%Q_XTLxN?$xEEsKKsRxAu`;0Pu^ICZa&K)#r4BG08@OX&q)eAoU( zOWI2${*!Z$f8Wq?Og567=TQ|VPNY-PNV1n>iZDV^m^hQRIiosETu91+Nc|VbWE+DL zG4UXA-9jTAh0J>H2av-9KcIr5`#7!J`0hV~B$`nP1WS?jD?dO*9ULR6?;BeB8qIZdEij)m(W;g8D7g1~ZQ{RgN2J-0<3I4i~#z~hf1Ff%0yE2Q>g z1=Zl3Hff16Cuc*dR{I~-4d=8;)mrGnqD?fD=5 zgo{5|f-116N}~9p;YF)Y05Td50xRV>$GMz?=R<%XIM;H{S@M7XGJ?=C>}F2d7=ns1 zSw}j27|mf~L6SU<){S67UKit!zip2D15uQM1yxekIaJB9kh(4)-cb(ua|vx)Bt!~I zTqF&tsD6>8r6bY593P%1XxAd?%11XANk$QBUnD19A^Cs!B_tVCAn!%uSA((^Nl6_V zSR}#Ch(5;g+5Z(C;SjQ52X5D=27lc3by!d(J^F>_7G28vk;OR2MPL-W)bw&(Zec-{ zbaxC@b1bA=vq)fqLoybS6Nhk7$N}gIW)@tlc>_=@hmnp^k<28=tA82Vw@6-#q4Y)4 zAc^`G$su{9F~#v|RYIYQBzXXljw{wnC=U9G~|a&`C^8Nc$X6DMukkI|Tq_ zZi~-Ik>m_+B6(db7C(8@WEX=^U>StM4^(St=&SBM4|$;(otGtco^R)LOk2-&k&XRnn#pXnxTnwia0~a6D@2aT^lfa$Hieph{9{Lhm>hQpVR?)L@MMUALTrf#PBW z{`VgW_@4@5|BXHl+4}R=73@uB^yB)3x&naIt%+dV4PORuKB_wa$RiuP6H_JY4r1X8 z7NpSyjzIbphhB2_Xeyi#|L>tPK3Eq1UpJ6F!vJ={Uf$ta=mT~aU&(Rjtf`jxZQxuI z|I6LeB@iGryo5?1cM|6|!@JRWOl-;f_F&8EErDPqnq0KhxFSWaU|>i}x{vl^VoExZ QgKlCXzr>&_2-p1o0LBnWd;kCd delta 10362 zcma)hc|285-2eGpSFY{4T}#$0lDI{#okS>7DcY4n+PEm~X`ydZS`LzyZz@x=L zXgo4R6Oa)yMnW_ZO+qHf6ir5ENQBIh1+qj|$Qs!oTV#jq(G=u>rXok=gr*^94_bznBVV)vtwesv9|fRQ zC=jhiYtUM>4y{K)C>V)R2nt1EXam}a!qFzQ8ErvZ(KfUl?La$G1lommqdjOZibPRp zANmLFM+hB22T?RSgbt%4=qRF542nf@=opGe$58@0fli`R=rsBlok5A{EINnIqa=jU z1#}T5qf00SrJ^*HjxM7Nl!>mOt0)UyL)j@5>$%H&=d3&JwwmY3-l6|qgSW`y+&_PC3=hAp(^wqeL&UdBl?6s zqc5li)uK97j~Y-TYC>O8Gx~OwzJH|jyZ&~Ma>`cOamg9gwb z`iq9p@FAc9Xco{?K(m3C26`0GGC*^HmIYc4XnCL&fK~*W3$zl@JfKGd%?DZ;XceGU zfmQ>04AAO8YXGeYv=-3XK6~v>nj)Ku-bM0qChfI|A(l^faKIfp!7f z73k?e&j8vDXm_Az0__3xETCrtJqKt{pyvWT4`?r-y@8$&^a7w40=)?6#Xv6sdMVI8 zKraJ&Incg9uYmh2fwhyXczMFybhVI&+^H1Bor-xoSArGG+*%^~unZIBO1uBt4U6Hj3PMx!y_9adEOYha*``StK)|%N<1ET8U8z(~c9X@B?BA}A$75=8 zs~+jX<1L*_zuQmuVm}HAy;j_y`?%wkLc%`3?Vbb9-+znBeu^XA=f&2rJl^!a5#~Ai z8igOU9q8yYZt*)5K2LS+=3;x#2`be$@;`j*b?iRSCndb-S#LCO<5X5kLjK#dUm<_{ zJGVu5e!g|(XujwC6$=)u;m_HiyW8yY%eP*i+|KX$C^%WRqvau140SMeim@8_>{#-; z+HH1*74WN{+OBd>G+Pq+Dpo1L?`Xu5w)oCr>QSQN%Yw`~@2b^K%dhxUs^{~Rtr^o!+cF`m)DsX1j&4KM_yxa;jj;VM(7bWbk ze7Ae*sa3h%jp2=X)l2-YWna76V^QY)aHy;NjAP7%$k#RF{`B-c8wiMuEV3KoypZlK z-Xk-^rgOH|@=xEpO6AvVe4_6m>-$^iBfe4LRGVCL!>LWaZu{#&}yVwp+J;C5|iDd(>}VWaphs@7RC|^SwWOd9hb=xN~dQmcT{jvL4P;dxoiT z16F;{I`?~aH9szJe>i0Q`uJCw1D_Xl=LK?gd;{B??PP968e`?Qu*h|i>eoNmdstGNl^dLwxcy+E&C^-M6_1;5%L`YpS(U-(a&->j2H50AfU zditZ1{Y$@!>|rv&_1&cXK%vukJ(V=|`gSH5YweWXvXAc7$u!s&PBE;PJAz4x@MK z+^M|Trf6dFD$Hj>!q-Vts4@8E{VYlFi?zHw%@tXxH~ltp>ikX|m+P*wEstm&+xPa` zj&#?cTgwxSrkqH4yHnli{00a6Wj?15KhN3h5N)D9q&7@hG)AiJxzHEe`q@oCA@cc! zMyY+Tx*l(Sn^!+Ot)R*@?Ch1od5shK1!Zm(GY22>I_A%NKKu@M=`04r$f20M?4egS zNxFYeIw;o8lagAqRqZG*|L(!j2E}0^_3qV2xDg5o9Sg*mZ~Aq4V7=$!DJG*v-}AaE z{i3qAr#N`~MzF12(wzPEAJZEg3tiigE_cJFm5PsY#(P>c+@z3ZsPBa%LJhjo3Bi;r~52Q3YC{mD6B>&^xP{G`=2d*lT_05%($Z@ zQmNT5_1-YGpPQ2KvLV>;d*jqQWzK%ax-jor%e!~E#Y@YDnUgnJJkwpHdp=@sMcA3* z&a9j94a>M^t`wPndH+u~?~_yYgT}~Tkym;eesAm>rcwu8`?hB8eIBWPbY7ZRj%}eF zeQ>qzony+MwKh1O+hTY>+OKb(;TeV5!THM^mk4gvMcn>(NKjS#uFb2&qFdUw`ca3% zz~;UsCJ~7`;SYj0MvmF5wPSzX2HNz#RhC}A$MG*AJcBrciGjHdUv-?bb@1{#$Gf+L zL^^xN4*lzNK5}8?jkt&N{?WbN+&WBcu5&uZyJUp7B|SeyH#*>38d zJA*C72C?hct?C`|DW`gs#sdm>|4Y@bcnkR^pPF{TR zOm&y;Il+|9@g*^Jb%A-itB{(PU1>o7*3>@ZPUB0FJ9h_UyB=Pu8a4XWcH5rTi9fPc z{k|=>xng~DRL|3>L#rMB3foUMoacXET>Z}Gy{!g)x%5_8N}b8d^W0X)bo_#XA3t<@=t7xtoG}Y>dCHZi%|EQd%RI$qOk+Ltm+kj>wC>iL(4!kZ$0X`Cjhp86Lj+>K5dGgyr&mMYUusOC_W0;cb{T?{s z={cX~%BLCKRt9@R-|sD3cJe&@Hlt=0kG+(nu<0%lK2 zzLnc2>ALoAiqny0kFR><&YuqM0ZpkpLwBuf)6$&Lb)$H+o7ojhf2DyyogL@*nCR|{ z&`oNHjB#4hk8x4LS}=-xb!#P%lOJ>P2g$2j0Wj`@#PY~0urHT%FIol8mT_S|fj~~H znbR8Pw3a!o14)?AdKh($6J>8SS1-ttE7>g*1SwLAC0cwoXD~)5Y$ZkByG-PRVE?KS z(+zf@C%zLJ1h!K@Ht5K)IpnMd(h7Vnj+Cs{?sFhi`qZHFxk2YkgHBC@PHltEc#7gV z3*{6k@}~;Ymdn^262K;5LEs_$Bz=zhEIn!(arXfnU{RE#>oFE}o&_6>F0iOf7Mnwg z;DLz(zDP1yYJ~7Pz@yZ`h%y6PY8o|@@}fpFp13v=m$Zci!^Z83>g4;N-QCluj7?Ex zII1ofRPf%f!5}AH%%;AKmc$S~UrKEZ$g=sPPkL*ofsozgnC5bLey6Vw9{L^(K9NF2 zxx<%KnjGa=9M@UtY)+bs*FWiOO0Q`C$}7N0c0OuPU|sX}i#ZhMKu$)40!67)2XojL z=TOPkAeDND)E#^UsItS;tjXgoM$Zn^-IpP7c(p248Xjb)O} zS(a={rS3Hco3#>AbI`4IvjHFjrayGB3m0*GwbOl<})m8O)N#O)+Tm#);1=twk|dnW|poqoLxndR8q=y zRk$r#nk0t#e9xyN&zXH6@GNbt?aWv90d*-fSzyfx@9^dc+&JOG@nZyq+<2w%VX7%+ z43(z1luF^!D%3?qMgCC(ZHbn>6z74K7q`$1vhYxj7{=&;|It_-z8YsZF}|Vb%)Qk2 zz`I#~F!6rL`?57H*gRJZ6BT=8wZH#cnKE2f@l|g+4klW@#&qhS^x|ptlA8l>i+e6D z=beeWbtkjwBKI10yeQ z4sh{l;xn~XRG_{~YtJlgyxRCP2c;|UP9NxwuWK$S*>Ew7l5qREa~huyoW=Nj>Sf>^ zKDz%&V)Da_om^S`mt@x*Wix@8Lb1*bG0cXmIEbJ%e8(3EI%vDHc_J%2E73|ZWk0Tk2Z3)RxKuWxfjMRr&j`#W9DHEqVEmlivz}<~2 zNp^E>m2vEZLeQE1X875!H^)=bjd_xmf{s^hHxl?Wv3{NyETI4|A?T@d%#?ki5Wdaq zO{%~B>rUgvVc?xRoO(1d=429I8y6AJMCih81U086IvJKI3a?KR*vSb%PM{$th!Id& zlgAY}%L&GEsX9$#If1tv`>b=!as~3R{p4QbQ(fdldOK=AHx;|yA&s=D5W+hzRnBng zjgvp`UPzz9yE#zuHs#-jvPQj7cH2wtCjRuI18=%6O8%r+^Ag`Qls#|h-^Z=MnIyL^ z%*Rg&UbPsso?6F$p(gqyx+%I!4RGJe3&Qx+9nH`3qB^SAq)Tv<@2x>SQ#2B=#tB;a z)F0s+oOV|Xi$H`22_h)Q`|gP$7!q+S!Huqa$D4aA%-HE2?!Aw??77f!4$FIsfU6;h z<$5FPoT4rJq-)Fy{x&W<(UluuG`%cm|Gl)z)R(}E%c%YE?gd@NUyGCSnHrwr9)gB2 z6>HrW!*bHC+X+sRn=rvtR&J=#Xl*0TB7%VQ`*VWUV1cCy7_7ne1jYOd?jn&e(=MC1k;6^)j1-OmFaKI)EeP>j$w{%Zmak9 zArCpOhaB~mIlWW!kYkr!=UUU_JP^ZD$j2uM&VXe6k>EHs-&pV# zvx>;*fP>haU!=uJfgb)r(8c7bkY{dfYi%ohG1@IwipthBmkp0CELC(Ylw#*P zd#dutBQPMvJ>Wn|@rxxs56Of8q=g$Ekx^Pir7fgAX zEiE_BJ$W^t&h^9>ip4Mi8gUuHaS)1I30i4UXH1#}rNZzoQEAszQM2IHXm1B^UGK^4 zOU~HgF}V|?@_#Xcy#MsCfS8 z-&F1|TkQ|;v&-qW5^vH;%SuV_v2xGgQbHQW56n^jb@tEetS>9M)8wU>sDFEK;o8T0 zzqw}&wPPMU*R@}OHK=_;ok{DpIN14# z7(&4rXA?Bn@SiBHJ-zQ#`unn&=oA5O|GuQtFaEx(&3ML8@NVz&QmcgRMrtSdFznj8YSy3ZR)H+wQ?s&a!F)4SXs>(KjipD zDz{0nR5`po_q`xM{;@RshqLUA@Q;F2+I49JcUGQGd$+zovM|#zfC#faCOa0u{)O)l4&qwfo z4cwE)>^~RWCbASPtn4fu6O;ri65f%t`Dv!MFuHq zPt-o$B{`h_>DEQA244D74ClZH{~~BKF1Lxg9NHVN9o`$>ytiL7eoOp9Dq0|`rESmR z1dwADe-@rrE`|#bgX;)t@fJ=3?XkJ_Y1yCNyu47!eT)@eiNOix;yDb;njfC{cua*% zYO^Gkq&-1(e2wU7_-oPY+y=)QS#PDT3enG1Z*hAC^Wb@7{%gjRiTw$x!#cc^V2tWr zceb^q`5x(^BK1>6>I&MNd(XJ%vDOJ!OJ|K$;}k~^B}jTca^0QB=GW8>^V2MrA6y_WjS|I=VpsqMy{=@m>g##)D#i(l zIq|%Bj`y^chNGxPPg}ucP5$mFf+{_H=o2%oti*Q+W`Txe?PoCrfcBRSW6vLcQTgLQ z+1q*$Q2o*Zb;;SbM+dWp$=crVg)F+PCw$5B8ZjucSmhINa2@l|S>hamh9JaM1n+Cj zxqc(7@^N}=dM5A=#osK>tg3Fa;QINh^h)8ZdNI5sD+p>3!)1q1FY64oHC>{cf>GL3 znx}%mT3Zk^Lp12EAnKuxzgXfu$=g8?uMqD*^?53Jucj`&jiy+_EMF>>tBQRZ$*ckh z#}S+dXK)R{@o-Hd-6V!}ELe_1o5k=C*x^osbIFR}^ot1{;ZNs~DyMyuq{D#8A%~-i=M$#c_f}bElGOtq%dI0s3@GddP0!+rceu|+K_F~s=X3)stc!C&ov8YE3fv`?;lHfal z+c@MmGcwBYYl73EMlz;X3|>Iyob`QTI8NFP`ad%69P}!5H879 z3;}BvT$X%Q3V}laS0x)phX5C#8SmwXKrx(`xGIN$f;1e*Ug{xa#kR(X;6-w!h8iJ| z0Cpi+UKv-ST1umSw|)TsIF{xOHmBN|FE8AN*_u2ZMFkUEOOcCokf6_4P-`s6v={o% zV~^qpMUtPIA+U`NjglbU5V$i6j$nPm5VAJylpH0v3LK0&RmhZF!o2AB!Vc;!sIX5- zbM;5VKh!_qMm2KPW~d-V61@dBlmw)yYp|NCfn`)4Sz8Q@Lcm~pG?hX0M#!YzlM>n? zi26Z3AuC}Ibs1)>+)*R*=4#Rrlc?X2NQ%&*PJt2?4G*bgJuB)t$WfnQmL!f86%TM4 z>j^_Z8<{_|74(3SSJA}X{X?)rx z1WW`)17;!__}|Z=Fiu`JqDVxt=zYt|!_G58Kx4FlnX|K-mFskC7ZWow__>Z)Omt1wUlklp zh#OfmUJ`URddeH$OtRLE7bwX3k{t$>5$1M?>}=KMDEjZ??~Mk4$+}sPN(2skH}h=k{MwGX6Hn#nRf$&31;l ziO9mvdDTn|b)ldvACxrGDMd|(0nc)0I=lz3BWM5^(*)~O_R^39pmXHN76UUePgR%^j$fG*Vb8sb5$79EaP>_}UA$*+@=Qe9T zoB5KK1T75#HjM1HtV#<>!&`kqApQUJagC=fBiHqRvc}yeR>|#Up>P2G@1IjWYC^%4 z{G5to2{C2)+{T531h78*#Co-au)QYx0e(hqv=z=Lf{=}aiJ-Za5d`Gs3E9@EM99r% zgnf*_+F66M2nk>XYhYeIQ;1}~Kj56QP;wvqR``Pw&LFao{pTo=_XW>^F}R%wb}aI~ zVodInzf|vEe@rusm1m9H2?=0{H(>8Zrmzd?0f4ox2ax(&h#+LS*WfWtOk|tdD!^T1 zSCL3+S19nXE!i03kQ*|r++<*3!fBK*PJ2-Q>~9Lr{e7)D^Vyuo(~31A&zVeOVs z@MdkAj5iPxz;^Uq1NiRRHN-31%6Qiw!d8TMuuN{^C_)0*yK9K0_d8?JY-7qdlU)n= zit<__>=_Y6=0v#azzDS?g7k7CM6F>2*LJ4V)ctq^A^t4mtGI%Y09Mr-Y}rAGlyG1z z7QGAwLtIGGb}WuQ?kB{bRX!6h?_@}G7%m`W4(q}(EKhnOfHnO(4jUn--{1;DX0d;D zuLHbsXdQVbrvGGW9M8ua2?=0po300Z+IBsuV1S9Rd){(6Tyu}2!FA9Nicw@+VvQFM*!mJ+=xQP&dcG_{0UGMyQ(zd-lOk{Fq(yvg^ z#w8?W%W9J_DL)qd1_u!0&wkTD{BzsalXsYYA_&<%twh++%LvPVGlJ^x^>F@J5NMcq z%?6eur84q>{pZH&4lRme4rX`lzyB2fuE*sh_f*y`b;@8h)<1>h6wy& zgv^P;+JBi4I*9#7NbC`uJVGwT;ieI?{RB1|A|Ceiv!tz()F4pB{}4gQ%1p!8mvxy*N5#sR+ zr!z$AN`DY;CCpjs`A`rxlOl|z!^WElabd;D;5>$~*C+%7u2m!3wpf|X6uq5?od|JZ ztBoO%cs(X^b|kV#3zv>WtjtIx$DWCdlVw>$S_rR(aX(m$?5rnL`czl(Ku-=}) zog*awEVkq@-fiS_3U_5P-eW`%vVW%#Av~KADj9+GH6uxuac&_R?zqbYe2E}r`Q5~a zMj|(fh$j~_k;aioeIe$_G4*v6;e{i__%Z%>goKyjPb1{nGdxzF@px3=)gwfq3STC~ zK>vUIN Date: Fri, 18 Jan 2019 16:36:57 -0500 Subject: [PATCH 02/30] addintional excitement --- book/proposal/proposal.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/book/proposal/proposal.md b/book/proposal/proposal.md index ee0f5bc..19d394f 100644 --- a/book/proposal/proposal.md +++ b/book/proposal/proposal.md @@ -82,4 +82,6 @@ The implication here is that we do not know how to collaborate with our users in This book makes a case that in order to solve problems we need to move the solution architects closer to the domain space. I believe in order to replicate the success of the open source movement in a broader way, we need to find ways to bring domain experts together with solution architects to create a new way of interacting. If one is to believe "We are as gods and might as well get good at it" then we need to focus on creating tools for others in a manner we ourselves would accept. +It then sets forward a set of tools to help developers take action on this premise equipping them to discuss complex problems with their user base in new and collaborative ways. + \ No newline at end of file From 4d2387bf93fdba546f3c3ffcb0a0d9d9d3ae058a Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Tue, 22 Jan 2019 12:11:46 -0500 Subject: [PATCH 03/30] starting chapter outline --- book/proposal/outline.md | 59 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 book/proposal/outline.md diff --git a/book/proposal/outline.md b/book/proposal/outline.md new file mode 100644 index 0000000..7bf0b87 --- /dev/null +++ b/book/proposal/outline.md @@ -0,0 +1,59 @@ +# Outline for Design Thinking for Developers + +## Chapter 1: What is Design Thinking + +A programmers primary output is the solution to a problem. The process can largely be summarized as understanding the problem well enough that you can create a program that teaches a computer how to complete the task or aid a user in completing the task. One of the best practices wrapped up in this is the program should communicate to the future programmers first and the computer second. + +In its simplest form solving a problem is going through a series of steps to identify the issue, understand the problem, come up with a solution and implement the solution. In reality there are millions of factors involved along the way from identifying to solving and all of these steps impact the quality of the solution. + +Often times as software developers we are tempted to limit ourselves to a list of requirements that we drone into a solution with little perspective offered as to the domain we are working in. Ironically we would never accept tools to use ourselves created in the fashion, in fact we rebelled against it in the forming of open source movement. We captured the importance of collaborating with users of software in the Agile Manifesto but often lack tooling to follow through. + +Design thinking offers a collaboration toolset to help engage domain experts in your process of development. It can help you understand a problem, domain, potential solution and can create a safe space for experimenting with new technologies. + +In this first chapter we will take a look at what design thinking is, outline the commonly referred to process and pick apart whether it needs to be done in totality. + +## Chapter 2: A brief intro to Domain Driven Design + +Design thinking process can offer an excellent way to engage domain experts in the creation of a product. This brief chapter will offer a overview of three domain driven design ideas, ubiquitous language, domain events and context bounding. + +These tools are helpful to programmers working within any organization regardless of wether a full fledged domain language is being used or not. + +## Chapter 3: Discovery +The first step to working on any problem is learning everything you can about the problem. In this book we will be outlining steps a development team is taking to implement a new warranty tool for a bike company. + +They first set about exploring the potential domain experts they will need to consult to understand the current process occurring with warranty issues. To approach this step we outline a tool for outlining the problem space called stakeholder mapping and experience diagramming. + +First in the experience diagram we introduce the tool as a way to explore the current flow of a warranty issue through the warranty process. This lifecycle exploration helps us to understand exactly how a the process is working today. + +Next the development team will create a stakeholder mapping. This is a outline of all the stakeholders involved in the warranty process, how they are involved and what they want out of the system. We will use this stakeholder mapping to introduce all the users types involved in the warranty process. + +From this stakeholder mapping and experience diagram we also will be able to create a bounded context for our domain driven language. We will explore how to gain this valuable asset from these exercises and how it can be used in the future. + +## Chapter 4: Interviewing and Job Shadowing + +Now that we have identified all the stakeholders and processes we will be impacting, we can reach out to gain context on their pain points. Job shadowing and interviewing are two valuable tools for exploring the problem space and the domain. + +In this chapter we will outline how to conduct a successful interview and how to do job shadowing. This includes + +- Using our stakeholder map and context bounding to identify interviewees. +- Getting permission. +- how to run a successful process. +- Finding in roads for future collaboration. +- Capturing ubiquitous language. +- Diagramming process flows and updating our experience diagrams with new context. +- Identifying domain events. +- Looking for hacks and other contextual clues. + +## Chapter 5: Gaining Context +We have collected a lot of output from our interviews and job shadowing time to make all that data make sense. There are a few different ways we can make sense out of this data, the first is understanding the language we are working with, the second is qualifying the process we are looking at. In order to do this we will look at 2 design thinking exercises, affinity clustering and rose bud thorn. + +Affinity clustering is a method which helps to sort our notes into contextually similar groups, as we sort the findings new groups start to emerge and we can find numerous groupings inside a problem area. We will use the output of this exercise in two ways, first to redefine our contextual boundaries of the domain and second to find related sets of problems we explore solutions too in our prototyping period. + +The second set of sorting we will do on our findings is, rose bud thorn this tool helps identify the positive, negative and items with potential for improvement in our dataset. We will explain how to take the finding from our interviews and job shadowing exercises and group them accordingly. We will then use this as a way to discuss identifying potential areas for improvement. + + +## Chapter 6: Defining our ubiquitous language +We now have a collection of language and + + +## Chapter x: Going remote. \ No newline at end of file From 537f3b954348f5f111c8c478b865067e0cfcf0bb Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Fri, 25 Jan 2019 16:48:45 -0500 Subject: [PATCH 04/30] more work on chapter outlines --- book/proposal/outline.md | 52 +++++++++++++++++++++++++--------------- 1 file changed, 33 insertions(+), 19 deletions(-) diff --git a/book/proposal/outline.md b/book/proposal/outline.md index 7bf0b87..877e9e0 100644 --- a/book/proposal/outline.md +++ b/book/proposal/outline.md @@ -2,13 +2,13 @@ ## Chapter 1: What is Design Thinking -A programmers primary output is the solution to a problem. The process can largely be summarized as understanding the problem well enough that you can create a program that teaches a computer how to complete the task or aid a user in completing the task. One of the best practices wrapped up in this is the program should communicate to the future programmers first and the computer second. +Solving hard problems is challenging, solving hard problems without first exposing yourself to the situation is impossible. But this is consistently how we approach software development. A product manager tries to understand a feature someone needs to solve their problem, they then condense this down into an issue that can fit into our software project management process of choice and hand it to a developer to implement. -In its simplest form solving a problem is going through a series of steps to identify the issue, understand the problem, come up with a solution and implement the solution. In reality there are millions of factors involved along the way from identifying to solving and all of these steps impact the quality of the solution. +This leads to a series of problems with the solution, a lack of domain knowledge throughout the organization, mis-leading code, poor data structures, un-maintainable codebases, in-sufficient or incorrect solutions and more. -Often times as software developers we are tempted to limit ourselves to a list of requirements that we drone into a solution with little perspective offered as to the domain we are working in. Ironically we would never accept tools to use ourselves created in the fashion, in fact we rebelled against it in the forming of open source movement. We captured the importance of collaborating with users of software in the Agile Manifesto but often lack tooling to follow through. +We need a better toolset, I would never expect a doctor to attempt surgery on a patient without ever meeting the patient. Why do we accept this in our work? We lack a process, one interesting observation I have noticed is that software developers can create amazing solutions to software problems, this is because the domain is tightly coupled to the developers work. We intuitively understand how to write software for the problems we face every day because we are continuously exposed to them. The solution we build for other problems facing the world tend to not be as good. We need a process that exposes developers to the domains they are working in. This process needs to also improve upon out other processes that we have found to work well. -Design thinking offers a collaboration toolset to help engage domain experts in your process of development. It can help you understand a problem, domain, potential solution and can create a safe space for experimenting with new technologies. +Design thinking is just such a process, it breaks down the process of learning about a domain and a problem into a series of methods we can reproduce. It does so by augmenting our domain learning and decision processes, many of which we currently do but in an informal way. In its simplest form solving a problem is going through a series of steps to identify the issue, understand the problem, come up with a solution and implement the solution. In reality there are millions of factors involved along the way from identifying to solving and all of these steps impact the quality of the solution. In this first chapter we will take a look at what design thinking is, outline the commonly referred to process and pick apart whether it needs to be done in totality. @@ -16,28 +16,26 @@ In this first chapter we will take a look at what design thinking is, outline th Design thinking process can offer an excellent way to engage domain experts in the creation of a product. This brief chapter will offer a overview of three domain driven design ideas, ubiquitous language, domain events and context bounding. -These tools are helpful to programmers working within any organization regardless of wether a full fledged domain language is being used or not. +These tools are helpful to programmers working within any organization regardless of wether a full fledged domain language is being used or not. In this chapter I will outline the final products we hope to gain through the book including a glossary, context boundaries for primary and supporting domains, domain events and org personas. ## Chapter 3: Discovery -The first step to working on any problem is learning everything you can about the problem. In this book we will be outlining steps a development team is taking to implement a new warranty tool for a bike company. +In this book we will be outlining the steps a development team is taking to implement a new warranty tool for a bike company. The first step to working on any problem is learning everything you can about the problem. This phase is often one that software developers are left out of. We will explore why this is and why it should not be the case. -They first set about exploring the potential domain experts they will need to consult to understand the current process occurring with warranty issues. To approach this step we outline a tool for outlining the problem space called stakeholder mapping and experience diagramming. +The first exercise introduced is a Stake Holder Mapping. This is a method for identifying potential domain experts to consult regarding the current process in place for warranty issues. The StakeHolder mapping also serves as a nice first pass at a bounded context diagram. -First in the experience diagram we introduce the tool as a way to explore the current flow of a warranty issue through the warranty process. This lifecycle exploration helps us to understand exactly how a the process is working today. +Next we will introduce how to develop buy in from domain experts and bring them into the process. This includes setting expectations, motivating participation and introducing the problem. -Next the development team will create a stakeholder mapping. This is a outline of all the stakeholders involved in the warranty process, how they are involved and what they want out of the system. We will use this stakeholder mapping to introduce all the users types involved in the warranty process. - -From this stakeholder mapping and experience diagram we also will be able to create a bounded context for our domain driven language. We will explore how to gain this valuable asset from these exercises and how it can be used in the future. +The final method introduced in this chapter is Experience Diagraming. This is a method for exploring the current process and visualizing it. Each of our identified stakeholders will be utilized to help outline all the steps a warranty takes from creation to completion from their perspective. This lifecycle exploration helps us to see potential areas of improvement. It also provides a collection point to work on our context boundaries and ubiquitous language. ## Chapter 4: Interviewing and Job Shadowing -Now that we have identified all the stakeholders and processes we will be impacting, we can reach out to gain context on their pain points. Job shadowing and interviewing are two valuable tools for exploring the problem space and the domain. +Now that we have identified all the stakeholders and processes we will be impacting, we can develop a picture of day to day operations. Job shadowing and interviewing are two valuable tools for exploring how the user does the task you are looking to augment everyday. In this chapter we will outline how to conduct a successful interview and how to do job shadowing. This includes - Using our stakeholder map and context bounding to identify interviewees. - Getting permission. -- how to run a successful process. +- How to run a successful interview process. - Finding in roads for future collaboration. - Capturing ubiquitous language. - Diagramming process flows and updating our experience diagrams with new context. @@ -45,15 +43,31 @@ In this chapter we will outline how to conduct a successful interview and how to - Looking for hacks and other contextual clues. ## Chapter 5: Gaining Context -We have collected a lot of output from our interviews and job shadowing time to make all that data make sense. There are a few different ways we can make sense out of this data, the first is understanding the language we are working with, the second is qualifying the process we are looking at. In order to do this we will look at 2 design thinking exercises, affinity clustering and rose bud thorn. -Affinity clustering is a method which helps to sort our notes into contextually similar groups, as we sort the findings new groups start to emerge and we can find numerous groupings inside a problem area. We will use the output of this exercise in two ways, first to redefine our contextual boundaries of the domain and second to find related sets of problems we explore solutions too in our prototyping period. +In this chapter we introduce two methods for contextualizing information we gained in the prior exercises affinity clustering and rose bud thorn. + +Affinity clustering is a method which helps to sort our notes into contextually similar groups. Through this process we sort the findings and observe groups that naturally start to emerge. Often we find numerous groupings inside a problem area that may map to or expand upon our contextual boundaries. We will use the output of this exercise in three ways, first to redefine our contextual boundaries. Next we will seek related sets of problems we can later prioritize. Finally we will introduce ways to utilize affinity mapping to organize our collected language, processes and domain events. + +The second method introduced is Rose Bud Thorn this tool helps categorize findings into positive (Rose), negative (Thorn) and items with potential for improvement (Bud). We will then use this as a way to discuss identifying potential areas for improvement. + + +## Chapter 6: Creating our Ubiquitous Language Glossary +We now have a collection of language and bounded context that will allow us to create a glossary. We will explore what a glossary is and how to create one from your findings. The book will also show some psuedo code examples of how this language and context bound idea can be implemented to lead to cleaner implementation and separation of concerns. + +## Chapter 7: Defining a problem statement + +Often times our problem statement is handed to us due to business needs, however the process by which we choose the problem to work on and state the problem are often difficult tasks that can be aided by process. There are also situations in which we maybe using design thinking to explore a new process inside our development processes. + +Defining a problem statement can be political and difficult to word. Our Rose, Bud, Thorn and Affinity Clustering activities have exposed a number of areas which we can focus on but picking one to hone in on is a matter of aligning people. When we do define it we need to ensure the language we use is open enough to encourage our creative process, yet bounded enough to keep us focused on our problem area. + +We will utilize explore proper language for phrasing problem statements and why language matters. Once we have a identified problem statements we will look at two methods of choosing the problem to work on, bracketing and star voting. -The second set of sorting we will do on our findings is, rose bud thorn this tool helps identify the positive, negative and items with potential for improvement in our dataset. We will explain how to take the finding from our interviews and job shadowing exercises and group them accordingly. We will then use this as a way to discuss identifying potential areas for improvement. +## Chapter 8: Ideation +## Chapter 9: Ranking competing ideas -## Chapter 6: Defining our ubiquitous language -We now have a collection of language and +## Chapter 10: Prototyping +## Chapter 11: Validating Prototypes -## Chapter x: Going remote. \ No newline at end of file +## Chapter x: Going remote.x` \ No newline at end of file From bd23f78b6ddec7a453e4dd78b4e5e7efe5dc8d02 Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Sat, 26 Jan 2019 16:10:09 -0500 Subject: [PATCH 05/30] more proposal --- book/proposal/outline.md | 12 +++++++++++- book/proposal/proposal.md | 26 +++++++++++++++++++------- 2 files changed, 30 insertions(+), 8 deletions(-) diff --git a/book/proposal/outline.md b/book/proposal/outline.md index 877e9e0..08867cc 100644 --- a/book/proposal/outline.md +++ b/book/proposal/outline.md @@ -52,7 +52,11 @@ The second method introduced is Rose Bud Thorn this tool helps categorize findin ## Chapter 6: Creating our Ubiquitous Language Glossary -We now have a collection of language and bounded context that will allow us to create a glossary. We will explore what a glossary is and how to create one from your findings. The book will also show some psuedo code examples of how this language and context bound idea can be implemented to lead to cleaner implementation and separation of concerns. +We now have a collection of language and bounded context that will allow us to create a glossary. We will explore what a glossary is and how to create one from your findings. + +The book will also show some pseudo code examples of how this language and context bound idea can be implemented to lead to cleaner implementation and separation of concerns. We will explore techniques for name-spacing code, organizing files, naming methods vs. objects and separating concerns. + +We will also explore how to keep these glossaries up to date and useful in your projects. ## Chapter 7: Defining a problem statement @@ -64,10 +68,16 @@ We will utilize explore proper language for phrasing problem statements and why ## Chapter 8: Ideation +Now that we have a problem statement to work on we need to start thinking about how to approach our problem. Ideation is a process of generating as many ideas as possible. These techniques are useful in a number of scenarios where you need to generate potential solutions to a well understood problem. + +We will introduce a few exercises to help with the brainstorming process + ## Chapter 9: Ranking competing ideas ## Chapter 10: Prototyping ## Chapter 11: Validating Prototypes +## Chapter 12: Cooking with ingredients + ## Chapter x: Going remote.x` \ No newline at end of file diff --git a/book/proposal/proposal.md b/book/proposal/proposal.md index 19d394f..52099d0 100644 --- a/book/proposal/proposal.md +++ b/book/proposal/proposal.md @@ -2,7 +2,9 @@ ### By: Cory Gwin ## Overview -The agile manifesto states we should prefer customer collaboration over contract negotiation. As developers we often leave the customer collaboration to others in our organization, leaving only short user stories or issues to gather context. This leads to a number of problems including: +Technology is simply a tool for solving a problem. Arguably the most valuable tool any developer has in their tool chest is the ability to understand, communicate about, break down a problem and provide a proven solution. Most organization find this incredibly difficult to do and often organization focus on how fast they can ship instead of how well their solutions are received. Oddly, as terrible as we are at this part of our jobs, our problem solving tools get no where near the attention as our text editor skills, scripting language of choice or deployment skills and other tools in our development war chest. Instead we hand it off to other parts of the organization and later complain about them throwing requirements over the wall without asking if we should break down the wall. + +It is time to break down these artificial boundaries and take responsibility for the solutions we build. The agile manifesto states we should prefer customer collaboration over contract negotiation. As developers we often leave the customer collaboration to others in our organization, leaving only short user stories or issues to gather context. This leads to a number of problems including: - Downstream communication issues. - Misunderstood requirements. @@ -14,16 +16,16 @@ The agile manifesto states we should prefer customer collaboration over contract - Unintended consequence of poorly modeled data. - Incorrect prioritization. -Our workflows and structures create communication barriers we must break down in order to move our implementations closer to their domains. As developers, our goals should include moving code closer to the vocabulary of the domain. This requires understanding not only the problem being solved by a feature but also, more broadly an understanding of the field we are working in. +Our workflows and structures create communication barriers we must break down in order to move our implementations closer to their domains. As developers, our goals should include moving ourselves and our code closer to the domain. This requires understanding not only the problem being solved by a feature but also, more broadly an understanding of the field we are working in. -Design thinking offers a toolset for gathering insight into the domain that can not only help engineers understand a user's problem more fundamentally, it can also offer byproducts such as: +Design thinking offers a toolset for gathering insight into the domain that can help engineers understand a user's problem more fundamentally and offer a number of useful byproducts such as: - Providing a better understanding of the entire domain. - A clearer path to a domain language. - Understanding problem nuance. - Gaining lessons learned of the user. - Clear prioritization of tasks. -- Indetifying focused solutions. +- Identifying focused solutions. - Providing insight into how an implementation may evolve. Following the path of a team replacing a legacy application with a new application this book will explore tools that can be utilized to break down a domain and better communicate with domain experts. The book will introduce a number of design thinking exercises and explain how they can be applied in different scenarios to help agile developers craft clearer implementations. @@ -44,6 +46,7 @@ Following the path of a team replacing a legacy application with a new applicati - Technical prototyping. - Story boarding UI's - Stakeholder validation. + - More?? - Introduce domain driven design concepts: - Ubiquitous language. - Context bounding. @@ -57,7 +60,16 @@ This book is suitable for developers, managers, product manager, project manager ## Why is your book different? -Design thinking books are often aimed at hard D design. This book will focus instead on using design thinking tools to create a different sort of outcome then is +This book will offer a design thinking tools set aimed at software development, with a minor focus on domain driven design. It will introduce software developers to all the phases of design thinking and teach them skills to help solve problems in more creative ways, skills emphasized include: + +- Communicating effectively with stakeholders. +- Identifying when to utilize design thinking methods and when not to. +- The discover, ideate, prototype phases of design thinking. +- Individual design thinking methodologies and when to use them in the software development lifecycle. +- How to run better retros. +- How to evaluate what to build given competing priorities. +- Understanding the business domain they work in day to day. +- Building long lived communication tools that impact internal/external communication and code design. ## Why we should get excited about your topic: @@ -74,9 +86,9 @@ In the Cathedral and the Bazaar a number of important ideas where set forth rela 1. To solve an interesting problem, start by finding a problem that is interesting to you. 1. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one. -Interestingly it contridicts itself pointing out a major issue with the way we develop software: +Interestingly it contradicts itself pointing out a major issue with the way we develop software: -1. Every good work of software starts by scratching a developer's personal itch. +> Every good work of software starts by scratching a developer's personal itch. The implication here is that we do not know how to collaborate with our users in the same way as when we develop to solve our own problems. From 9f2a1e0ebce75353600368dd46cc8c9c53a4bd33 Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Mon, 28 Jan 2019 21:10:19 -0500 Subject: [PATCH 06/30] chapter outline --- book/proposal/outline.md | 36 +++++++++++++++++++++++++++++++++--- 1 file changed, 33 insertions(+), 3 deletions(-) diff --git a/book/proposal/outline.md b/book/proposal/outline.md index 08867cc..6d725a4 100644 --- a/book/proposal/outline.md +++ b/book/proposal/outline.md @@ -70,14 +70,44 @@ We will utilize explore proper language for phrasing problem statements and why Now that we have a problem statement to work on we need to start thinking about how to approach our problem. Ideation is a process of generating as many ideas as possible. These techniques are useful in a number of scenarios where you need to generate potential solutions to a well understood problem. -We will introduce a few exercises to help with the brainstorming process +We will introduce a few exercises to help with the brainstorming process. + +First we will try redefining the opportunity by changing our statement starter by turning it into a question in the phrases of who, what, when, where, why and how. We will use each of these prompts to define as many answers as possible. + +Next we will look at creating a creative matrix, in this process we define 5 assets we have at our dispense to solve the problem and we align those with our domain areas to brainstorm how the statement starter could be solved, approached etc in different combinations of tools and subdomains. ## Chapter 9: Ranking competing ideas +At this point we have created a number of competing solutions, deciding which one's to pursue is often politically charged. We need tools to remove the personal attachment we hold to ideas and look at them subjectively. We will look at three exercises for doing this work. These tools are exceptionally valuable for going through backlogs, ranking company alignment goals like OKRs or getting stakeholders to express their needs accurately. + +First we will look at importance difficulty mapping. In this exercise we create a x,y graph that shows the importance and difficulty of every item we came up with during ideation in a quadrant. This visualization shows us the low hanging fruit, high-importance difficult items, low importance low difficulty items and low important high difficulty items; assisting us in choosing what to work on. + +Buy a feature is a game in which each player is given a budget and can choose which features they would pay for. This show which features are most valuable to which stakeholders. + +Brackets are a fun way to have features compete against each other for votes. As you work through the bracket people voting are allowed to change what they are routing for so everyones voice is heard to completion. + ## Chapter 10: Prototyping -## Chapter 11: Validating Prototypes +Now that we have the ranked ideas we wish to implement, it is time to validate our ideas and experiment with competing implementation details. + +There are two types of prototyping that make sense for software developers that I have experienced. + +The first is a user facing prototype that shows off a feature that they will be working with, this is an invaluable alignment tool for working with stakeholder. + +The second is a technology prototype, often when we set out to build a new feature, app, etc... much of our architecture decision is based on the strongest political position in the room or the most familiar tech. Technology prototypes allow us to break out of this and offer a space to experiment and validate different ideas. We will outline how to run a successful technical prototyping session. + +## Chapter 11: Validating and learning from Prototypes + +We prototype in order ensure we are choosing the right direction, but learning from prototypes is an art. We need to separate our preference and bias and see what the prototype is really telling us. We will look at user testing our stakeholder facing prototypes and how to iterate. + +We will also look at tools for qualifying technical prototypes, setting criteria, validating new tech and outlining how to assess risk. ## Chapter 12: Cooking with ingredients -## Chapter x: Going remote.x` \ No newline at end of file +Throughout this book we have followed a very defined line of discover, ideate, prototype and validate. This recipe is common in design thinking, however the dogma of this process is misleading. Much like a great chef starts by following a recipe, they soon learn to break the ingredients apart and use them appropriately in different scenarios. We can utilize any one of these different methods in a number of scenarios and add a dash of ideation here and a prototyping session there without following the entire process. + +In this chapter we will look at running better retros, aligning a backlog, blameless incident response, prototyping competing implementation details, and how to run partial or full design thinking process in short periods of time. + +## Chapter x: Going remote + +Many of the tools in this book are possible to do remotely as well. Let's take some of the common methods in this book and discuss how we can bring them to remote teams.:w From dd4a2d2cc4f2dabf49049b3b0d5c762e90a1c918 Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Mon, 28 Jan 2019 21:10:52 -0500 Subject: [PATCH 07/30] chapter # --- book/proposal/outline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/proposal/outline.md b/book/proposal/outline.md index 6d725a4..5a83491 100644 --- a/book/proposal/outline.md +++ b/book/proposal/outline.md @@ -108,6 +108,6 @@ Throughout this book we have followed a very defined line of discover, ideate, p In this chapter we will look at running better retros, aligning a backlog, blameless incident response, prototyping competing implementation details, and how to run partial or full design thinking process in short periods of time. -## Chapter x: Going remote +## Chapter 13: Going remote Many of the tools in this book are possible to do remotely as well. Let's take some of the common methods in this book and discuss how we can bring them to remote teams.:w From 88d028b3454c3c01b38430c3a9053dd66d504dc4 Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Thu, 31 Jan 2019 10:52:19 -0500 Subject: [PATCH 08/30] combine first 2 chapters --- book/proposal/outline.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/book/proposal/outline.md b/book/proposal/outline.md index 5a83491..0c02a00 100644 --- a/book/proposal/outline.md +++ b/book/proposal/outline.md @@ -1,22 +1,24 @@ # Outline for Design Thinking for Developers -## Chapter 1: What is Design Thinking +## Chapter 1: Exploring the hard problems with Design Thinking and Domain Driven Development -Solving hard problems is challenging, solving hard problems without first exposing yourself to the situation is impossible. But this is consistently how we approach software development. A product manager tries to understand a feature someone needs to solve their problem, they then condense this down into an issue that can fit into our software project management process of choice and hand it to a developer to implement. +Solving hard problems is challenging, solving hard problems without first exposing yourself to the situation is impossible. But this is consistently how we approach software development. A product manager tries to understand a feature someone thinks they need, the product manager then condense this down into an issue that can fit into our software project management process of choice and a developer to implements. This leads to a series of problems with the solution, a lack of domain knowledge throughout the organization, mis-leading code, poor data structures, un-maintainable codebases, in-sufficient or incorrect solutions and more. -We need a better toolset, I would never expect a doctor to attempt surgery on a patient without ever meeting the patient. Why do we accept this in our work? We lack a process, one interesting observation I have noticed is that software developers can create amazing solutions to software problems, this is because the domain is tightly coupled to the developers work. We intuitively understand how to write software for the problems we face every day because we are continuously exposed to them. The solution we build for other problems facing the world tend to not be as good. We need a process that exposes developers to the domains they are working in. This process needs to also improve upon out other processes that we have found to work well. - -Design thinking is just such a process, it breaks down the process of learning about a domain and a problem into a series of methods we can reproduce. It does so by augmenting our domain learning and decision processes, many of which we currently do but in an informal way. In its simplest form solving a problem is going through a series of steps to identify the issue, understand the problem, come up with a solution and implement the solution. In reality there are millions of factors involved along the way from identifying to solving and all of these steps impact the quality of the solution. +We will explore the intersection of the fields of design thinking, agile and domain driven design as a better way to build products. In this first chapter we will take a look at what design thinking is, outline the commonly referred to process and pick apart whether it needs to be done in totality. -## Chapter 2: A brief intro to Domain Driven Design +Design thinking process can offer an excellent way to engage domain experts in the creation of a product. Domain driven design offers a set of tools for taking these findings and creating software implementations that more concisely capture the knowledge we have learned. -Design thinking process can offer an excellent way to engage domain experts in the creation of a product. This brief chapter will offer a overview of three domain driven design ideas, ubiquitous language, domain events and context bounding. +In this chapter we will introduce domain driven design ideas we will be covering in this book: -These tools are helpful to programmers working within any organization regardless of wether a full fledged domain language is being used or not. In this chapter I will outline the final products we hope to gain through the book including a glossary, context boundaries for primary and supporting domains, domain events and org personas. +- Ubiquitous languages +- Glossaries +- Context boundaries for primary and supporting domains +- Domain events +- Org personas ## Chapter 3: Discovery In this book we will be outlining the steps a development team is taking to implement a new warranty tool for a bike company. The first step to working on any problem is learning everything you can about the problem. This phase is often one that software developers are left out of. We will explore why this is and why it should not be the case. From 845ebc3cf9602510f4c447baff608eebcb7dd641 Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Fri, 1 Feb 2019 21:49:27 -0500 Subject: [PATCH 09/30] sample chapter started --- book/proposal/sample chapter.md | 62 +++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 book/proposal/sample chapter.md diff --git a/book/proposal/sample chapter.md b/book/proposal/sample chapter.md new file mode 100644 index 0000000..b217aa6 --- /dev/null +++ b/book/proposal/sample chapter.md @@ -0,0 +1,62 @@ +# Interviewing and Job Shadowing + +What better way to learn about a topic then spend time with an expert. In our stakeholder mapping exercise we began to identify different types of users we should communicate with to better understand their working context and challenges. + +By working with these experts we can continue to develop our domain knowledge documents and better frame the experience of the work environment. The intuitive knowledge we learn from this experience can inform the decisions we make in the future about the product but also inform architecture choices and aid in low level implementation choices like variable naming via our context bounds and associated ubiquitous language. + +## What should I talk about? + +Creating interviewing questions or preparing for a job shadowing exercise can be a bit of a trap. As developers we have strong thoughts and opinions about our users and our products direction. These thoughts and opinions will impact the people we choose to talk to, the questions we ask and how we listen. Acknowledging our biases before starting any sort of interviewing process is a good first step. + +## Identifying biases + +There are a number of common biases to examine prior to entering any period of interviewing. Identifying these biases in ourselves and our team are not just useful for interviewing and job shadowing but can also help us to understand our team dynamics, inter-team communications and product decision influencers. + +The three main biases I have seen on my teams include confirmation bias, survivorship bias and social desirability. + +### Confirmation biases +Confirmation bias is the tendency to interpret new evidence as a confirmation of one's exiting beliefs. + +This seems to be the most common bias amongst solution seeking +### Survivorship biases + +### Social Desirability biases + +## Who should I talk to? + +Deciding who are the proper domain experts to talk to is difficult, often we have a limited amount of time we can dedicate to this sort of research and we feel like there is no way we can fit it in. It's important to remember that one person is better then none, two better then one and usually twenty is about all that is consumable. + +Picking the number of domain experts to talk to and which domain experts to talk to should start as a consideration of a combination of the stakeholder groups involved + + + + + + + +## Asking for permission. + +## Interviewing + +### The shape of an interview + +### Avoid yes no questions + +### Seeking stories + +### The followup + +## Capturing language + +## Job shadowing + +### Shadows are silent + +### How you actually work not how your supposed to work + +### Look for the hacks + +### You should build traps + +### Capturing processes + From d84c92dfd7aa2d56944e0110894e3f057657eacc Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Sat, 2 Feb 2019 16:39:42 -0500 Subject: [PATCH 10/30] organic --- book/proposal/outline.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/book/proposal/outline.md b/book/proposal/outline.md index 0c02a00..3311261 100644 --- a/book/proposal/outline.md +++ b/book/proposal/outline.md @@ -1,10 +1,20 @@ # Outline for Design Thinking for Developers -## Chapter 1: Exploring the hard problems with Design Thinking and Domain Driven Development +## Chapter 1: Organic Software with Design Thinking and Domain Driven Development -Solving hard problems is challenging, solving hard problems without first exposing yourself to the situation is impossible. But this is consistently how we approach software development. A product manager tries to understand a feature someone thinks they need, the product manager then condense this down into an issue that can fit into our software project management process of choice and a developer to implements. +Organic software is the modern ideal and a quality needed if we seek to perpetuate the success and social responsibility of open source to a wider set of problems. We seek to serve the whole of life, seeking solutions which effortlessly enhance our environments in a informed, thoughtful and responsible manner. -This leads to a series of problems with the solution, a lack of domain knowledge throughout the organization, mis-leading code, poor data structures, un-maintainable codebases, in-sufficient or incorrect solutions and more. +Organic software: + +- Seeks a natural progression of its environment. +- Flows and changes effortlessly with its domain. +- Satisfy social needs responsibly. +- Focuses on the communicating consistently across the implementation and domain. +- Seek empowering solutions over narrowly targeted solutions. + +Crafting organic software is challenging! Solving problems in a appropriate way without first exposing yourself to the situation is impossible! But this is consistently how we approach software development. A product manager tries to understand a feature someone thinks they need, the product manager then condense this down into an issue that can fit into our software project management process of choice and a developer to implements. + +This leads to a series of problems with the solution, a lack of domain knowledge throughout the organization, mis-leading code, poor data structures, un-maintainable codebases, in-sufficient or incorrect solutions and worse. We will explore the intersection of the fields of design thinking, agile and domain driven design as a better way to build products. From 2dc7dfe368a882eebc2cf6b372053436230de29d Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Sun, 3 Feb 2019 16:09:52 -0500 Subject: [PATCH 11/30] chapter work --- book/proposal/sample chapter.md | 65 +++++++++++++++++++++++++++------ 1 file changed, 53 insertions(+), 12 deletions(-) diff --git a/book/proposal/sample chapter.md b/book/proposal/sample chapter.md index b217aa6..9612de9 100644 --- a/book/proposal/sample chapter.md +++ b/book/proposal/sample chapter.md @@ -4,39 +4,65 @@ What better way to learn about a topic then spend time with an expert. In our st By working with these experts we can continue to develop our domain knowledge documents and better frame the experience of the work environment. The intuitive knowledge we learn from this experience can inform the decisions we make in the future about the product but also inform architecture choices and aid in low level implementation choices like variable naming via our context bounds and associated ubiquitous language. -## What should I talk about? +The first step in interviewing or job shadowing is to pick a topic. Picking a topic will often steer us toward job shadowing or interviewing. I finding interviewing to be a good method for getting insights into general experiences or broad stroke conversations. I often find job shadowing to be a better tool for augmenting and optimizing existing processes. -Creating interviewing questions or preparing for a job shadowing exercise can be a bit of a trap. As developers we have strong thoughts and opinions about our users and our products direction. These thoughts and opinions will impact the people we choose to talk to, the questions we ask and how we listen. Acknowledging our biases before starting any sort of interviewing process is a good first step. +## Biases -## Identifying biases +Creating interviewing questions or preparing for a job shadowing exercise can be a bit of a trap. As developers we have strong thoughts and opinions about our users and our products direction. These thoughts and opinions will impact the people we choose to talk to, the topics we lean towards, the questions we ask and how we listen. Acknowledging our biases before starting any sort of interviewing process is a good first step. There are a number of common biases to examine prior to entering any period of interviewing. Identifying these biases in ourselves and our team are not just useful for interviewing and job shadowing but can also help us to understand our team dynamics, inter-team communications and product decision influencers. -The three main biases I have seen on my teams include confirmation bias, survivorship bias and social desirability. +The three main biases I have seen include confirmation bias, survivorship bias, availability bias and social desirability. -### Confirmation biases -Confirmation bias is the tendency to interpret new evidence as a confirmation of one's exiting beliefs. +#### Confirmation biases +Confirmation bias is the tendency to interpret new evidence as a confirmation of one's exiting beliefs. An example of confirmation bias is someone who holds the belief that left handed people are more creative than right handed people. In confirmation bias this individual would place greater importance on this correlation confirming their bias in their mind every time they met a left handed person who was creative, they would ignore the right handed people who are creative. -This seems to be the most common bias amongst solution seeking -### Survivorship biases +If you start to see questions that can be thought of as confirming an idea or seeking evidence of a belief you are probably in the middle of confirmation bias. Also be cognizant of the tendency humans have to ignore disconfirming information, this is how stereotypes perpetuate. -### Social Desirability biases +#### Survivorship biases +During WW2 the US Military was attempting to strengthen the armor on planes. In order to do this they took stock of where the bullet holes on the planes where located and placed more armor in those locations. The problem with this approach was text book survivorship bias. -## Who should I talk to? +The planes hit in the spot where the engineers where putting more armor was pointless because a plane could survive a hit in that location. They later realized they needed to put armor where they were not seeing holes because those planes where not surviving. -Deciding who are the proper domain experts to talk to is difficult, often we have a limited amount of time we can dedicate to this sort of research and we feel like there is no way we can fit it in. It's important to remember that one person is better then none, two better then one and usually twenty is about all that is consumable. +We often see similar scenarios in our own interviews, we tend to interview our best customers or heaviest users. This may be helpful from a relationship perspective, but those users needs are mostly being met. Instead we should try to interview the users that abandon our product for another product. -Picking the number of domain experts to talk to and which domain experts to talk to should start as a consideration of a combination of the stakeholder groups involved +#### Availability Biases + +As we go through our day we are bombarded with the current events of our work. Support needs, issues you have been working on, parts of the codebase you wrote etc... Anything that is top of mind can influence how you see or think about a situation. +For example if your company just released a shiny new feature you are more likely to suggest it as a possible solution over something that maybe more appropriate that came out 5 years ago simply because it is top of mind. +#### Social Desirability biases +Anyone being interviewed will be bias toward answering questions in a way that is socially acceptable. When was the last time someone asked you if you test all your code, how did you answer? If you are like most people you don't test all your code, but you said yes regardless because you want them to think of you in certain way. +This is social desirability bias it is a bit like peer pressure, we have a reason to lie or color the truth because we are trying to align our practices with what we perceive as the socially accepted values. +### How do we interview people without these biases? +Interviewing people is hard, we have to navigate both our biases and the interviewees. Really great interviewers are hard to come by, but not everyone needs to be Terry Gross to get value out of an interview. +You can learn to follow a pretty formulaic interview process and get good at it. I often am reminded of a statement a friend of mine told me about interviewing, you have 2 ears and 1 mouth try to use them in that proportion. It really is all about listening. + +Most people love to tell stories, if you can get a person into a story telling mode they will usually become fairly honest and straightforward as opposed to people answering questions survey style. + +So how do we conduct such an interview? ## Asking for permission. +The first thing we need to do in conducting an interview is to seek permission from the participant. Seeking permission often takes setup, this is a good time to set expectations. Why are you interviewing people, how will the interviewee be compensated, how many people are you interviewing, where will the interview take place, what will you talk about with them, will you be recoding, who else will be at the interview and any other relevant information is nice. When setting expectations you want to be clear about what you are doing, but don't get to specific. You can start to color response even before you have an interview. + +Expectations are also dependent on whom you are talking to. Internal users may have insight into what you are working on, while external users may not. Be sure to consider what is appropriate to share or expose in an interviewing process before releasing your companies hot new feature months before it comes out. + ## Interviewing +Now the fun part, the interview. I like to make sure a few things are in place before I conduct an interview. + +1. A comfortable location with snacks is always nice to have. +2. At least one note taker. +3. An outline of the questions you want to ask. +4. Post it notes and pens. +5. If desired and ok with the interviewee a recording device. + +Next I like to think about what I am going to ask in the interview. When writing out your questions it is easy to fall into our above biases. ### The shape of an interview @@ -46,6 +72,21 @@ Picking the number of domain experts to talk to and which domain experts to talk ### The followup + + +## Who should I talk to? + +Deciding who are the proper domain experts to talk to is difficult, often we have a limited amount of time we can dedicate to this sort of research and we feel like there is no way we can fit it in. It's important to remember that one person is better then none, two better then one and usually twenty is about all that is consumable. + +Picking the number of domain experts to talk to and which domain experts to talk to should start as a consideration of a combination of the stakeholder groups involved + + + + + + + + ## Capturing language ## Job shadowing From 195070c0333bb192d61d7525c738218b6696af28 Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Sun, 3 Feb 2019 20:58:41 -0500 Subject: [PATCH 12/30] more interviewing --- book/proposal/sample chapter.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/book/proposal/sample chapter.md b/book/proposal/sample chapter.md index 9612de9..1ea0ff1 100644 --- a/book/proposal/sample chapter.md +++ b/book/proposal/sample chapter.md @@ -62,10 +62,24 @@ Now the fun part, the interview. I like to make sure a few things are in place b 4. Post it notes and pens. 5. If desired and ok with the interviewee a recording device. -Next I like to think about what I am going to ask in the interview. When writing out your questions it is easy to fall into our above biases. +Next we need to write our questions, an easy way to do this is to use a question starter that encourages story telling. Story telling is the preferred method for interview responses as stories tend to be more organic. Survey style questions tend to impart an answer shaped by bias. + +A great question starter is tell me about, this encourages dialog. Other good questions to ask can include: + +- If you had to change one things what would it be? Why? +- Have you done x differently in the past? +- What do you tell new co-workers when they start? + +Once you have a dialog going, clarifying questions can be used to shed light on the conversation and add priority. + +- If you had x how frequently would you have used it in the past 6 months? +- Just be be sure I am clear if you had x, what would it allow you to do that you cannot do now? +- Tell me more about why you prefer the competitors feature over ours. +- If a genie granted you 2 wishes about the current situation what 2 things would you fix? ### The shape of an interview + ### Avoid yes no questions ### Seeking stories From c2d8bf3ece6237a44a742a384dc2aea7901b2c7a Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Mon, 4 Feb 2019 11:55:50 -0500 Subject: [PATCH 13/30] sample chapter --- book/proposal/sample chapter.md | 35 +++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 13 deletions(-) diff --git a/book/proposal/sample chapter.md b/book/proposal/sample chapter.md index 1ea0ff1..ad9663c 100644 --- a/book/proposal/sample chapter.md +++ b/book/proposal/sample chapter.md @@ -79,39 +79,48 @@ Once you have a dialog going, clarifying questions can be used to shed light on ### The shape of an interview +There is a common pattern to an interview you can follow to make things more natural, I even put this into a template to remind myself of the steps to take. -### Avoid yes no questions +The first step in the process is an introduction. In this portion of the interview we need to cover the following three items: -### Seeking stories +1. Introduce yourself. +2. State your purpose. +3. Obtain consent to continue with the interview. -### The followup +Once we have done the introduction, I like to ask the interviewee something personal sort of like an ice breaker to ease any tension. Ask them about their day, comment on a unique article of clothing or any personal question that is friendly and easy to discuss. I try to avoid cliche question or topics like the weather as they have grown to lack any depth and don't let the person talk about themselves. If you let the person talk about themselves they will be much more at ease. +On to the questions, at this point we ask the pre-planned questions. I usually have 3-4 these should be open ended, don't feel like you need to stay on script. Often the best interview veers in an unexpected direction naturally as you explore reasons and ideas that are unique to the interviewee and potentially introduce topics or ideas you had not considered. +Once the conversation starts to dwindle I often will ask the users a straightforward question that prompts them to solve their own problem. Questions like how would you fix the situation or how have you dealt with this in another role often prompt the user to offer a solution. This may have value or not, but often is insightful in a different way. -## Who should I talk to? +Finally we conclude our interview, at this point you can thank the participant and exchange pleasantries. Before the interviewee leaves I always like to ask permission to collaborate again in the future. This sets up the user for future interviews but also gives us a pool of domain experts to tap when it come time to test prototypes of validate ideas. -Deciding who are the proper domain experts to talk to is difficult, often we have a limited amount of time we can dedicate to this sort of research and we feel like there is no way we can fit it in. It's important to remember that one person is better then none, two better then one and usually twenty is about all that is consumable. -Picking the number of domain experts to talk to and which domain experts to talk to should start as a consideration of a combination of the stakeholder groups involved +### Avoid yes no questions +It is always tempting to ask a question that the interviewee can answer yes or no to, however these are often the most bias answers and do not really offer any unique insight. If you are tempted to ask a yes/no question see if you can re-phrase the question in such a way that the answer ends up telling a story, explaining a process or exploring the reason a choice is made. +## Capturing language, process and events +Often times we think we need to define the domain language, however the domain language is currently being spoken everyday. Our job is rather to extract, contextualize and define it in such a way that it is easy to reference and share. +As we interview domain experts we have an opportune time to work on extracting their language and better understand it. When conducting an interview I recommend having the note taker write down any specific vocabulary that is discussed. Note any terms that are vague or overloaded and ask the interviewee to explain what they mean when they say x. Capture each of these terms so can later add them to our context boundaries and define them in the glossary. +## Job shadowing +Job shadowing is a tool to reach for when we are working on a very well defined process that we are looking to augment or change. I have approached this in two distinct ways with success. The first is silent observation, the second is engaging directly with the task and discussing it with the domain expert. -## Capturing language +Silent observation of someone doing a task can show you how they do a task day to day in a pure way. In this scenario you want to limit your exposure to the participant as much as possible. Don't ask questions, don't get in there way, maybe even consider spying on them when they don't know you are watching. The purer the experience the less bias you impose on their performance. -## Job shadowing +When engaging in the activity, you get a different outcome. I like to approach this as if someone was training me to start a new job. Go through the actions of learning how to do the task. Ask questions, why do we do this, where does this go, how did this come to be? You are trying to clearly understand an entire workflow and get to know intimately why the decisions where made that lead to the current process. -### Shadows are silent - -### How you actually work not how your supposed to work +In either of these approaches you need to take extensive notes on workflows, conversations that occur between stakeholders, the materials being passed around or used, tools available and flow of information between contexts. ### Look for the hacks - -### You should build traps +One thing to pay particular attention to are the hacks around the workspace. Sticky notes of keyboard shortcut, codes or steps are a good hint that a process is hard or confusing. Taking documents into and out of multiple programs can show formatting errors. I have even seen upc hacking to fix problems with upc numbers between factories. These are often low hanging fruit with a large impact. ### Capturing processes +There are a lot of ways to capture processes as you work through the job. Workflow process diagrams can show how different entities flow through the system and can capture language used to describe each step. We can also capture domain events that occur between each step of the workflow. + From b224e3ff6263fd33261565f5f54581ecbb57e788 Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Mon, 4 Feb 2019 16:09:14 -0500 Subject: [PATCH 14/30] editing --- book/proposal/outline.md | 22 ++++++------ book/proposal/sample chapter.md | 61 +++++++++++++++++++++------------ 2 files changed, 50 insertions(+), 33 deletions(-) diff --git a/book/proposal/outline.md b/book/proposal/outline.md index 3311261..ec1ce8b 100644 --- a/book/proposal/outline.md +++ b/book/proposal/outline.md @@ -30,7 +30,7 @@ In this chapter we will introduce domain driven design ideas we will be covering - Domain events - Org personas -## Chapter 3: Discovery +## Chapter 2: Discovery In this book we will be outlining the steps a development team is taking to implement a new warranty tool for a bike company. The first step to working on any problem is learning everything you can about the problem. This phase is often one that software developers are left out of. We will explore why this is and why it should not be the case. The first exercise introduced is a Stake Holder Mapping. This is a method for identifying potential domain experts to consult regarding the current process in place for warranty issues. The StakeHolder mapping also serves as a nice first pass at a bounded context diagram. @@ -39,7 +39,7 @@ Next we will introduce how to develop buy in from domain experts and bring them The final method introduced in this chapter is Experience Diagraming. This is a method for exploring the current process and visualizing it. Each of our identified stakeholders will be utilized to help outline all the steps a warranty takes from creation to completion from their perspective. This lifecycle exploration helps us to see potential areas of improvement. It also provides a collection point to work on our context boundaries and ubiquitous language. -## Chapter 4: Interviewing and Job Shadowing +## Chapter 3: Interviewing and Job Shadowing Now that we have identified all the stakeholders and processes we will be impacting, we can develop a picture of day to day operations. Job shadowing and interviewing are two valuable tools for exploring how the user does the task you are looking to augment everyday. @@ -54,7 +54,7 @@ In this chapter we will outline how to conduct a successful interview and how to - Identifying domain events. - Looking for hacks and other contextual clues. -## Chapter 5: Gaining Context +## Chapter 4: Gaining Context In this chapter we introduce two methods for contextualizing information we gained in the prior exercises affinity clustering and rose bud thorn. @@ -63,14 +63,14 @@ Affinity clustering is a method which helps to sort our notes into contextually The second method introduced is Rose Bud Thorn this tool helps categorize findings into positive (Rose), negative (Thorn) and items with potential for improvement (Bud). We will then use this as a way to discuss identifying potential areas for improvement. -## Chapter 6: Creating our Ubiquitous Language Glossary +## Chapter 5: Creating our Ubiquitous Language Glossary We now have a collection of language and bounded context that will allow us to create a glossary. We will explore what a glossary is and how to create one from your findings. The book will also show some pseudo code examples of how this language and context bound idea can be implemented to lead to cleaner implementation and separation of concerns. We will explore techniques for name-spacing code, organizing files, naming methods vs. objects and separating concerns. We will also explore how to keep these glossaries up to date and useful in your projects. -## Chapter 7: Defining a problem statement +## Chapter 6: Defining a problem statement Often times our problem statement is handed to us due to business needs, however the process by which we choose the problem to work on and state the problem are often difficult tasks that can be aided by process. There are also situations in which we maybe using design thinking to explore a new process inside our development processes. @@ -78,7 +78,7 @@ Defining a problem statement can be political and difficult to word. Our Rose, B We will utilize explore proper language for phrasing problem statements and why language matters. Once we have a identified problem statements we will look at two methods of choosing the problem to work on, bracketing and star voting. -## Chapter 8: Ideation +## Chapter 7: Ideation Now that we have a problem statement to work on we need to start thinking about how to approach our problem. Ideation is a process of generating as many ideas as possible. These techniques are useful in a number of scenarios where you need to generate potential solutions to a well understood problem. @@ -88,7 +88,7 @@ First we will try redefining the opportunity by changing our statement starter b Next we will look at creating a creative matrix, in this process we define 5 assets we have at our dispense to solve the problem and we align those with our domain areas to brainstorm how the statement starter could be solved, approached etc in different combinations of tools and subdomains. -## Chapter 9: Ranking competing ideas +## Chapter 8: Ranking competing ideas At this point we have created a number of competing solutions, deciding which one's to pursue is often politically charged. We need tools to remove the personal attachment we hold to ideas and look at them subjectively. We will look at three exercises for doing this work. These tools are exceptionally valuable for going through backlogs, ranking company alignment goals like OKRs or getting stakeholders to express their needs accurately. @@ -98,7 +98,7 @@ Buy a feature is a game in which each player is given a budget and can choose wh Brackets are a fun way to have features compete against each other for votes. As you work through the bracket people voting are allowed to change what they are routing for so everyones voice is heard to completion. -## Chapter 10: Prototyping +## Chapter 9: Prototyping Now that we have the ranked ideas we wish to implement, it is time to validate our ideas and experiment with competing implementation details. @@ -108,18 +108,18 @@ The first is a user facing prototype that shows off a feature that they will be The second is a technology prototype, often when we set out to build a new feature, app, etc... much of our architecture decision is based on the strongest political position in the room or the most familiar tech. Technology prototypes allow us to break out of this and offer a space to experiment and validate different ideas. We will outline how to run a successful technical prototyping session. -## Chapter 11: Validating and learning from Prototypes +## Chapter 10: Validating and learning from Prototypes We prototype in order ensure we are choosing the right direction, but learning from prototypes is an art. We need to separate our preference and bias and see what the prototype is really telling us. We will look at user testing our stakeholder facing prototypes and how to iterate. We will also look at tools for qualifying technical prototypes, setting criteria, validating new tech and outlining how to assess risk. -## Chapter 12: Cooking with ingredients +## Chapter 11: Cooking with ingredients Throughout this book we have followed a very defined line of discover, ideate, prototype and validate. This recipe is common in design thinking, however the dogma of this process is misleading. Much like a great chef starts by following a recipe, they soon learn to break the ingredients apart and use them appropriately in different scenarios. We can utilize any one of these different methods in a number of scenarios and add a dash of ideation here and a prototyping session there without following the entire process. In this chapter we will look at running better retros, aligning a backlog, blameless incident response, prototyping competing implementation details, and how to run partial or full design thinking process in short periods of time. -## Chapter 13: Going remote +## Chapter 12: Going remote Many of the tools in this book are possible to do remotely as well. Let's take some of the common methods in this book and discuss how we can bring them to remote teams.:w diff --git a/book/proposal/sample chapter.md b/book/proposal/sample chapter.md index ad9663c..f4441cc 100644 --- a/book/proposal/sample chapter.md +++ b/book/proposal/sample chapter.md @@ -1,18 +1,31 @@ # Interviewing and Job Shadowing -What better way to learn about a topic then spend time with an expert. In our stakeholder mapping exercise we began to identify different types of users we should communicate with to better understand their working context and challenges. +What better way to learn about a topic then spend time with an expert. In our stakeholder mapping exercise we began to identify different types of users we should communicate with to better understand their working context and challenges. Now we will explore some methods for engaging these domain experts to increase our awareness of their language, workflows, entities and problems. -By working with these experts we can continue to develop our domain knowledge documents and better frame the experience of the work environment. The intuitive knowledge we learn from this experience can inform the decisions we make in the future about the product but also inform architecture choices and aid in low level implementation choices like variable naming via our context bounds and associated ubiquitous language. +After working through these exercise with our domain experts we will look to develop internal documents that can be leveraged for current implementation, future on-boarding and to guide conversations and decisions in the future. We will examine interviewing and job shadowing as our two main methods. + +## Aside on note taking +Each of these will provide notes and insights we can capture simply. I like to collect these notes on post it's sometimes I color code them for context but this is up to you. Note taking can be simple scratches of words, crude drawings or complex long form notes. + +I tend to prefer post it notes in most situations as they force me to compress ideas down. In this world I try to create hundreds of notes if possible. It is always ideal to go into any creative process with as much information as possible. + +## Getting Started The first step in interviewing or job shadowing is to pick a topic. Picking a topic will often steer us toward job shadowing or interviewing. I finding interviewing to be a good method for getting insights into general experiences or broad stroke conversations. I often find job shadowing to be a better tool for augmenting and optimizing existing processes. -## Biases +Often times our topic is chosen by business alignment tools like OKR's, issues in the queue etc. The type of work and the amount of time you have to dedicate to the work will also steer you towards one direction or the other. + +Don't be afraid to shove this process into a short timeframe. Talking to 1 or 2 domain experts is usually better then talking to none. If you are good about time boxing and prep you can get through a couple interviews in 2-3 hours. You can also opt to interview people without adhering to the rest of what this book lays out as process. Just the act of talking with someone can inspire you to take a different more informed direction then you would without that conversation. + +That being said, interviewing properly is important for the output of the interview. + +## Your bias, So am I Creating interviewing questions or preparing for a job shadowing exercise can be a bit of a trap. As developers we have strong thoughts and opinions about our users and our products direction. These thoughts and opinions will impact the people we choose to talk to, the topics we lean towards, the questions we ask and how we listen. Acknowledging our biases before starting any sort of interviewing process is a good first step. There are a number of common biases to examine prior to entering any period of interviewing. Identifying these biases in ourselves and our team are not just useful for interviewing and job shadowing but can also help us to understand our team dynamics, inter-team communications and product decision influencers. -The three main biases I have seen include confirmation bias, survivorship bias, availability bias and social desirability. +The main biases I have seen include confirmation bias, survivorship bias, availability bias and social desirability. #### Confirmation biases Confirmation bias is the tendency to interpret new evidence as a confirmation of one's exiting beliefs. An example of confirmation bias is someone who holds the belief that left handed people are more creative than right handed people. In confirmation bias this individual would place greater importance on this correlation confirming their bias in their mind every time they met a left handed person who was creative, they would ignore the right handed people who are creative. @@ -20,7 +33,7 @@ Confirmation bias is the tendency to interpret new evidence as a confirmation of If you start to see questions that can be thought of as confirming an idea or seeking evidence of a belief you are probably in the middle of confirmation bias. Also be cognizant of the tendency humans have to ignore disconfirming information, this is how stereotypes perpetuate. #### Survivorship biases -During WW2 the US Military was attempting to strengthen the armor on planes. In order to do this they took stock of where the bullet holes on the planes where located and placed more armor in those locations. The problem with this approach was text book survivorship bias. +During WW2 the US Military was attempting to strengthen the armor on planes. In order to do this they took stock of where the bullet holes on the planes where located and placed more armor in those locations. This is a great example of the problem with survivorship bias. The planes hit in the spot where the engineers where putting more armor was pointless because a plane could survive a hit in that location. They later realized they needed to put armor where they were not seeing holes because those planes where not surviving. @@ -28,31 +41,25 @@ We often see similar scenarios in our own interviews, we tend to interview our b #### Availability Biases -As we go through our day we are bombarded with the current events of our work. Support needs, issues you have been working on, parts of the codebase you wrote etc... Anything that is top of mind can influence how you see or think about a situation. +As we go through our day we are bombarded with the current events of our work; support's needs, issues you have been working on, parts of the codebase you wrote etc... Anything that is top of mind can influence how you see or think about a situation. -For example if your company just released a shiny new feature you are more likely to suggest it as a possible solution over something that maybe more appropriate that came out 5 years ago simply because it is top of mind. +This is why if your company just released a shiny new feature you are more likely to suggest it as a possible solution over something that maybe more appropriate that came out 5 years ago simply because it is top of mind. #### Social Desirability biases -Anyone being interviewed will be bias toward answering questions in a way that is socially acceptable. When was the last time someone asked you if you test all your code, how did you answer? If you are like most people you don't test all your code, but you said yes regardless because you want them to think of you in certain way. +Anyone being interviewed will be bias toward answering questions in a way that is socially acceptable. When was the last time someone asked you if you test all your code, how did you answer? If you are like most people you don't test all your code, but you said yes, or shaped some story to make it sound like you do most of the time, because you want them to think of you in desirable way. -This is social desirability bias it is a bit like peer pressure, we have a reason to lie or color the truth because we are trying to align our practices with what we perceive as the socially accepted values. +This is social desirability bias it is a bit like peer pressure, we have a reason to lie or color the truth because we are trying to align our practices with what we perceive as the socially desired values. ### How do we interview people without these biases? Interviewing people is hard, we have to navigate both our biases and the interviewees. Really great interviewers are hard to come by, but not everyone needs to be Terry Gross to get value out of an interview. -You can learn to follow a pretty formulaic interview process and get good at it. I often am reminded of a statement a friend of mine told me about interviewing, you have 2 ears and 1 mouth try to use them in that proportion. It really is all about listening. +You can learn to follow a mostly formulaic interview process and get good at it. I am often reminded of a statement a friend of mine told me about interviewing, you have 2 ears and 1 mouth try to use them in that proportion. It really is all about listening. Most people love to tell stories, if you can get a person into a story telling mode they will usually become fairly honest and straightforward as opposed to people answering questions survey style. So how do we conduct such an interview? -## Asking for permission. - -The first thing we need to do in conducting an interview is to seek permission from the participant. Seeking permission often takes setup, this is a good time to set expectations. Why are you interviewing people, how will the interviewee be compensated, how many people are you interviewing, where will the interview take place, what will you talk about with them, will you be recoding, who else will be at the interview and any other relevant information is nice. When setting expectations you want to be clear about what you are doing, but don't get to specific. You can start to color response even before you have an interview. - -Expectations are also dependent on whom you are talking to. Internal users may have insight into what you are working on, while external users may not. Be sure to consider what is appropriate to share or expose in an interviewing process before releasing your companies hot new feature months before it comes out. - ## Interviewing Now the fun part, the interview. I like to make sure a few things are in place before I conduct an interview. @@ -77,7 +84,13 @@ Once you have a dialog going, clarifying questions can be used to shed light on - Tell me more about why you prefer the competitors feature over ours. - If a genie granted you 2 wishes about the current situation what 2 things would you fix? -### The shape of an interview +## Asking for permission. + +We always need the participants permission when conducting an interview. Seeking permission often takes setup, this is a good time to set expectations. Why are you interviewing people, how will the interviewee be compensated, how many people are you interviewing, where will the interview take place, what will you talk about with them, will you be recoding, who else will be at the interview and any other relevant information is nice. When setting expectations you want to be clear about what you are doing, but don't get to specific. You can start to color response even before you have an interview. + +Expectations are also dependent on whom you are talking to. Internal users may have insight into what you are working on, while external users may not. Be sure to consider what is appropriate to share or expose in an interviewing process before releasing your companies hot new feature months before it comes out. + +### Template of an interview There is a common pattern to an interview you can follow to make things more natural, I even put this into a template to remind myself of the steps to take. @@ -87,22 +100,24 @@ The first step in the process is an introduction. In this portion of the intervi 2. State your purpose. 3. Obtain consent to continue with the interview. -Once we have done the introduction, I like to ask the interviewee something personal sort of like an ice breaker to ease any tension. Ask them about their day, comment on a unique article of clothing or any personal question that is friendly and easy to discuss. I try to avoid cliche question or topics like the weather as they have grown to lack any depth and don't let the person talk about themselves. If you let the person talk about themselves they will be much more at ease. +Once we have done the introduction, I like to ask the interviewee something personal, to ease any tension. Ask them about their day, comment on a unique article of clothing or any personal question that is friendly and easy to discuss. I try to avoid cliche question or topics like the weather as they have grown to lack any depth and don't let the person talk about themselves. If you let the person talk about themselves they will be much more at ease. -On to the questions, at this point we ask the pre-planned questions. I usually have 3-4 these should be open ended, don't feel like you need to stay on script. Often the best interview veers in an unexpected direction naturally as you explore reasons and ideas that are unique to the interviewee and potentially introduce topics or ideas you had not considered. +On to the questions, at this point we ask the pre-planned questions. I usually have 3-4, ideally these questions should be open ended. When getting answers don't feel like you need to stay on script and make sure to let silence hang a little longer then normal. Often the best interview veers in an unexpected direction naturally as you explore reasons and ideas that are unique to the interviewee and potentially introduce topics or ideas you had not considered. Once the conversation starts to dwindle I often will ask the users a straightforward question that prompts them to solve their own problem. Questions like how would you fix the situation or how have you dealt with this in another role often prompt the user to offer a solution. This may have value or not, but often is insightful in a different way. -Finally we conclude our interview, at this point you can thank the participant and exchange pleasantries. Before the interviewee leaves I always like to ask permission to collaborate again in the future. This sets up the user for future interviews but also gives us a pool of domain experts to tap when it come time to test prototypes of validate ideas. - +The time has come to conclude our interview, at this point you can thank the participant and exchange pleasantries. Before the interviewee leaves I always like to ask for permission to collaborate in the future. This helps build a pool of domain experts to tap when it come time to test prototypes, validate ideas or collect more information. ### Avoid yes no questions -It is always tempting to ask a question that the interviewee can answer yes or no to, however these are often the most bias answers and do not really offer any unique insight. If you are tempted to ask a yes/no question see if you can re-phrase the question in such a way that the answer ends up telling a story, explaining a process or exploring the reason a choice is made. +It is always tempting to ask a question that the interviewee can answer yes or no to. I find that these are often the most bias answers and do not really offer any unique insight. If you are tempted to ask a yes/no question see if you can re-phrase the question in such a way that the answer ends up telling a story, explaining a process or exploring the reason a choice is made. +Instead of do you test you code, consider how do you test your code? Another example could be have you used x feature, instead ask what has been your experience with x feature? These re-phrases encourage more information exchange that you can act upon. ## Capturing language, process and events +Domain driven design offers a number of great ideas about using the language, entities, workflows and events of the domain in our code. In the interviewing and job shadowing methods a number of these items should have became evident. + Often times we think we need to define the domain language, however the domain language is currently being spoken everyday. Our job is rather to extract, contextualize and define it in such a way that it is easy to reference and share. As we interview domain experts we have an opportune time to work on extracting their language and better understand it. When conducting an interview I recommend having the note taker write down any specific vocabulary that is discussed. Note any terms that are vague or overloaded and ask the interviewee to explain what they mean when they say x. Capture each of these terms so can later add them to our context boundaries and define them in the glossary. @@ -123,4 +138,6 @@ One thing to pay particular attention to are the hacks around the workspace. Sti ### Capturing processes There are a lot of ways to capture processes as you work through the job. Workflow process diagrams can show how different entities flow through the system and can capture language used to describe each step. We can also capture domain events that occur between each step of the workflow. +There are a number of ways you can capture workflow processes, the first thing to figure out is what spatial dimension is important. For example, do you need to represent the process flowing between teams, over time or across physical locations? This can help us decide how to represent the workflow as it changes state. + From 16194b10b5d17850727b32a6a67772250055ae81 Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Mon, 4 Feb 2019 16:29:29 -0500 Subject: [PATCH 15/30] more editing --- book/proposal/sample chapter.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/book/proposal/sample chapter.md b/book/proposal/sample chapter.md index f4441cc..faee2e6 100644 --- a/book/proposal/sample chapter.md +++ b/book/proposal/sample chapter.md @@ -114,14 +114,6 @@ It is always tempting to ask a question that the interviewee can answer yes or n Instead of do you test you code, consider how do you test your code? Another example could be have you used x feature, instead ask what has been your experience with x feature? These re-phrases encourage more information exchange that you can act upon. -## Capturing language, process and events - -Domain driven design offers a number of great ideas about using the language, entities, workflows and events of the domain in our code. In the interviewing and job shadowing methods a number of these items should have became evident. - -Often times we think we need to define the domain language, however the domain language is currently being spoken everyday. Our job is rather to extract, contextualize and define it in such a way that it is easy to reference and share. - -As we interview domain experts we have an opportune time to work on extracting their language and better understand it. When conducting an interview I recommend having the note taker write down any specific vocabulary that is discussed. Note any terms that are vague or overloaded and ask the interviewee to explain what they mean when they say x. Capture each of these terms so can later add them to our context boundaries and define them in the glossary. - ## Job shadowing Job shadowing is a tool to reach for when we are working on a very well defined process that we are looking to augment or change. I have approached this in two distinct ways with success. The first is silent observation, the second is engaging directly with the task and discussing it with the domain expert. @@ -135,6 +127,15 @@ In either of these approaches you need to take extensive notes on workflows, con ### Look for the hacks One thing to pay particular attention to are the hacks around the workspace. Sticky notes of keyboard shortcut, codes or steps are a good hint that a process is hard or confusing. Taking documents into and out of multiple programs can show formatting errors. I have even seen upc hacking to fix problems with upc numbers between factories. These are often low hanging fruit with a large impact. + +## Capturing language, process and events + +Domain driven design offers a number of great ideas about using the language, entities, workflows and events of the domain in our code. In the interviewing and job shadowing methods a number of these items should have became evident. + +Often times we think we need to define the domain language, however the domain language is currently being spoken everyday. Our job is rather to extract, contextualize and define it in such a way that it is easy to reference and share. + +As we interview domain experts we have an opportune time to work on extracting their language and better understand it. When conducting an interview I recommend having the note taker write down any specific vocabulary that is discussed. Note any terms that are vague or overloaded and ask the interviewee to explain what they mean when they say x. Capture each of these terms so can later add them to our context boundaries and define them in the glossary. + ### Capturing processes There are a lot of ways to capture processes as you work through the job. Workflow process diagrams can show how different entities flow through the system and can capture language used to describe each step. We can also capture domain events that occur between each step of the workflow. From 37a7a437ea2a780fea0b05b124b18257b317dd34 Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Tue, 5 Feb 2019 20:07:56 -0500 Subject: [PATCH 16/30] language capture --- book/proposal/sample chapter.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/book/proposal/sample chapter.md b/book/proposal/sample chapter.md index faee2e6..f928854 100644 --- a/book/proposal/sample chapter.md +++ b/book/proposal/sample chapter.md @@ -136,6 +136,8 @@ Often times we think we need to define the domain language, however the domain l As we interview domain experts we have an opportune time to work on extracting their language and better understand it. When conducting an interview I recommend having the note taker write down any specific vocabulary that is discussed. Note any terms that are vague or overloaded and ask the interviewee to explain what they mean when they say x. Capture each of these terms so can later add them to our context boundaries and define them in the glossary. +There are some patterns to look for when capturing domain languages. Try to pay attention to nouns, verbs, other stakeholders and processes. Often times nouns can relate to entities that are stored as some sort of document or can help us find context boundaries if they relate to other parts of the organization. Verbs often point to actions taking place, try to understand the context in which these actions happen and the verbs they occur upon. Stakeholders can show us new bounded contexts or help to re-inforce existing context boundaries. Finally process can show us places for further investigation. Another useful method for finding out about processes is event storming. + ### Capturing processes There are a lot of ways to capture processes as you work through the job. Workflow process diagrams can show how different entities flow through the system and can capture language used to describe each step. We can also capture domain events that occur between each step of the workflow. From 1bfb972001b49be93589ff4d37cb8daa19d7aac2 Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Wed, 13 Feb 2019 13:15:29 -0500 Subject: [PATCH 17/30] second attempt at sample chapter --- book/proposal/sample chapter2.md | 295 +++++++++++++++++++++++++++++++ 1 file changed, 295 insertions(+) create mode 100644 book/proposal/sample chapter2.md diff --git a/book/proposal/sample chapter2.md b/book/proposal/sample chapter2.md new file mode 100644 index 0000000..94a6494 --- /dev/null +++ b/book/proposal/sample chapter2.md @@ -0,0 +1,295 @@ +# Interviewing and Job Shadowing + +What better way to learn about a topic then spend time with an expert. In our stakeholder mapping exercise we began to identify different types of users we should communicate with to better understand their working context and challenges. Now we will explore some methods for engaging these domain experts to increase our awareness of their language, workflows, entities and problems. + +In this chapter we will introduce interviewing and job shadowing. We will use these methods to dig deep into the warranty workflow that exists today in order to understand the domain we are working within. We will be looking to gain as many key insights as we can to aid our implementation choices in the future. + +We will explore how to conduct better interviews, get stakeholder buy in, common pitfalls that could bias you implementation and how to collect common language, domain events, identify entities and processes. + +# Identifying an interviewing topic + +Our warranty process has been flagged for replacement because it is built in a legacy system that we believe is leading to tracking issues and slowing down communications. We have been implementing a new customer support portal in sales and management wants to tie the two systems together for a variety of reasons. The top down pressure is revolving around tracking costs in warranty, but warranty is expressing concerns about customer interactions and fearing a changing process. + +Our interview could go in a number of directions based on what we know. It would be easy to focus on what management wants out of the transition as hierarchies lead to this kind of approach. In our case we choose to seek the topic which is the most domain centric. What does that mean? Glad you asked, we want to get at the most common workflows, entities, processes in the central workflows. In our case what is the common lifecycle of a warranty. This will ensure our solution first focuses on the primary work that needs to be completed, primary domain. We want to avoid getting into the weeds of how are cost being tracked at this point, although it is a motivating force in the org, once we have a solid core domain modeled we can move to cost tracking as a separate subdomain and explore that problem independently. It maybe a driver for why we are making the switch, but the important thing to tackle first is the core domain. + +# Determining who to interview + +Different domain experts will work with our system in different ways and have differing needs of the system. If we refer to our bounded contexts we can gain some insight into different entities that may need to access this system, we can also do a separate stakeholder mapping exercise just for this project, it may show new bounded contexts to account for. + +We want to ensure we interview a few people from each context to get some different perspectives, when possible these people should have very different backgrounds. For our warranty system we have identified the following domain experts to discuss this system with: + +- The warranty dept. +- Inventory and purchasing. +- Internal sales reps. +- Outside sale reps. +- Small bike shop mechanic. +- Large outdoor sporting goods store shop manager. +- Product management. + +This represents the core group of domain experts that touch the warranty system on a daily basis today. Each of them have very different roles in the company and need very different things out of the system. This should give us a broad view of the domain space and how the different context view things. + +We have a pretty long list here, generally speaking it maybe hard to talk to this many stakeholders. Trying to talk to 2-3 is better then talking to none, + +# Getting permission from stakeholders + +We need to reach out to each of our domain experts and get their permission to do the interviews. The way we speak to each group maybe different in tone based on who they are, our relationship with them, and their relationship to the project. + +Warranty should hopefully be aware of the project, getting permission from the core domain experts who you are directly affecting their workflow should be easy. Some times you need to deal with push back about changing processes, but this is an opportunity to ease tensions and express you ambitions to improve their day to day work. Try building enthusiasm in the project by showing a willingness to work together and project often go from dreaded to exciting as the domain experts see the ability to change their day to day workflows in a positive way. + +Outside collaborators such as bike shops are often trickier, in this case I will often leverage the relationship a sales rep has with a shop or find a shop warranty particularly enjoys. Often times your domain experts can grease the wheels and even get outside collaborators excited about contributing back toward improving systems they dislike. + +Internal collaborators like sales may often state they don't have time to do an interview. These interviews can sometimes be the trickiest in some ways, however I have had success with drop in conversation or offering to take some one out to lunch. + +# Writing questions + +Now it is time to write interview questions. Interviewing people is a bit like hanging out at the bar with a friend asking them about their last great adventure. We want to go into it curious and with a beginners mindset. It is tempting to approach interview questions in a similar way to writing survey questions, by this I mean questions with yes/no multiple choice answers, try to avoid this. + +We will be using some question starters to help us create good interviewing starters, thinking about interview questions as conversation starters is a good approach. Our starters are: + +- Tell me about the last time you did x. +- Have you done x differently in the past? Maybe at a different company. +- What do you tell new co-workers on their first day? +- What does a typical x process look like? + +Filling in our topic `common warranty lifecycle` we end up with the following questions: + +- Tell me about the last warranty you processed. +- Have you processed warranties differently in the past? +- What do you tell new warranty employees on their first day about the process? +- What is the process for a typical warranty? + +These question will spark conversation and have plenty of room to breath. The goal is to remove yourself from the conversation as much as possible and let the domain expert explain their process. It is common to interject bias into questions and we want to avoid that as much as possible. + +It is important to mostly let the interviewee talk, we want to be an active listener. From time to time something will come up in the interview that you think it would be nice to expand upon. Having some potential lines in your questions to help you frame a question in a way the qualifies the statement or expands upon it is helpful. + +- If you had x how frequently would you have used it in the past 6 months? +- Just be be sure I am clear if you had x, what would it allow you to do that you cannot do now? +- Tell me more about why you prefer the competitors feature over ours. +- If you had to choose between x and y which would you choose? + +At some point in the interview the conversation will wind down. I like to offer the domain expert the ability to solution at this point. Often they have stewed over a potential solution or better workflow but don't posses the skills required to implement it. Have some questions ready for this time: + +- How would you solve x? +- If you could change one thing today what would it be? +- If you had a magic wand what would you change? + +I will add all these questions to a question outline so they are ready for interview day. + +## Identifying bias + +Creating interviewing questions or preparing for a job shadowing exercise can be a bit of a trap. As developers we have strong thoughts and opinions about our users and our products direction. These thoughts and opinions will impact the people we choose to talk to, the topics we lean towards, the questions we ask and how we listen. Acknowledging our biases before starting any sort of interviewing process is a good first step. + +There are a number of common biases to examine prior to entering any period of interviewing. Identifying these biases in ourselves and our team are not just useful for interviewing and job shadowing but can also help us to understand our team dynamics, inter-team communications and product decision influencers. + +The main biases I have seen include confirmation bias, survivorship bias, availability bias and social desirability. + +#### Confirmation biases +Confirmation bias is the tendency to interpret new evidence as a confirmation of one's exiting beliefs. An example of confirmation bias is someone who holds the belief that left handed people are more creative than right handed people. In confirmation bias this individual would place greater importance on this correlation confirming their bias in their mind every time they met a left handed person who was creative, they would ignore the right handed people who are creative. + +If you start to see questions that can be thought of as confirming an idea or seeking evidence of a belief you are probably in the middle of confirmation bias. Also be cognizant of the tendency humans have to ignore disconfirming information, this is how stereotypes perpetuate. + +#### Survivorship biases +During WW2 the US Military was attempting to strengthen the armor on planes. In order to do this they took stock of where the bullet holes on the planes where located and placed more armor in those locations. This is a great example of the problem with survivorship bias. + +The planes hit in the spot where the engineers where putting more armor was pointless because a plane could survive a hit in that location. They later realized they needed to put armor where they were not seeing holes because those planes where not surviving. + +We often see similar scenarios in our own interviews, we tend to interview our best customers or heaviest users. This may be helpful from a relationship perspective, but those users needs are mostly being met. Instead we should try to interview the users that abandon our product for another product. + +#### Availability Biases + +As we go through our day we are bombarded with the current events of our work; support's needs, issues you have been working on, parts of the codebase you wrote etc... Anything that is top of mind can influence how you see or think about a situation. + +This is why if your company just released a shiny new feature you are more likely to suggest it as a possible solution over something that maybe more appropriate that came out 5 years ago simply because it is top of mind. + +#### Social Desirability biases +Anyone being interviewed will be bias toward answering questions in a way that is socially acceptable. When was the last time someone asked you if you test all your code, how did you answer? If you are like most people you don't test all your code, but you said yes, or shaped some story to make it sound like you do most of the time, because you want them to think of you in desirable way. + +This is social desirability bias it is a bit like peer pressure, we have a reason to lie or color the truth because we are trying to align our practices with what we perceive as the socially desired values. + + +### How do we interview people without these biases? + +Interviewing people is hard, we have to navigate both our biases and the interviewees. Really great interviewers are hard to come by, but not everyone needs to be Terry Gross to get value out of an interview. + +You can learn to follow a mostly formulaic interview process and get good at it. I am often reminded of a statement a friend of mine told me about interviewing, you have 2 ears and 1 mouth try to use them in that proportion. It really is all about listening. + +Most people love to tell stories, if you can get a person into a story telling mode they will usually become fairly honest and straightforward as opposed to people answering questions survey style. + +So how do we conduct such an interview? + + +# Interviewing + +## Location + +I tend to prefer comfortable informal interviews, I feel people can be more authentic. You may also choose to simply meet people where they are, sometimes other people in the room can be good as it becomes a case of interviewing a group as people often chime in, other times social pressures can keep people from saying what they really think. In our case, the warranty system is ok to interview in an open context as there are not really pressing feelings involved or social pressure. + +To prepare our interviewing space I go through this checklist: + +- [ ] At least one note taker. +- [ ] Question we are going to ask. +- [ ] Post it notes and pens. +- [ ] If desired a recording device, make sure this is ok with the interviewee. + +## Conducting the interview + +There is a common pattern to an interview you can follow to make things more natural, I even put this into a template to remind myself of the steps to take. + +The first step in the process is an introduction. In this portion of the interview we need to cover the following three items: + +1. Introduce yourself. +2. State your purpose. +3. Obtain consent to continue with the interview. + +Once we have done the introduction, I like to ask the interviewee something personal, to ease any tension. Ask them about their day, comment on a unique article of clothing or any personal question that is friendly and easy to discuss. I try to avoid cliche question or topics like the weather as they have grown to lack any depth and don't let the person talk about themselves. If you let the person talk about themselves they will be much more at ease. + +On to the questions, at this point we ask the pre-planned questions. I usually have 3-4, ideally these questions should be open ended. When getting answers don't feel like you need to stay on script and make sure to let silence hang a little longer then normal. Often the best interview veers in an unexpected direction naturally as you explore reasons and ideas that are unique to the interviewee and potentially introduce topics or ideas you had not considered. + +Once the conversation starts to dwindle I often will ask the users a straightforward question that prompts them to solve their own problem. Questions like how would you fix the situation or how have you dealt with this in another role often prompt the user to offer a solution. This may have value or not, but often is insightful in a different way. + +The time has come to conclude our interview, at this point you can thank the participant and exchange pleasantries. Before the interviewee leaves I always like to ask for permission to collaborate in the future. This helps build a pool of domain experts to tap when it come time to test prototypes, validate ideas or collect more information. + +## The warranty domain expert interview + +It is time to interview our warranty domain expert, Nevin, we walk through our introductions and purpose statement, obtain consent one last time then jump into our questions. + +You: Can you tell me about the last warranty you processed? + +Nevin: This xl Vision mountain bike has a broken frame, Harrie's bike shop contacted me via email to notify me about the issue. We sent out a new frame once we identified it was a manufacturing defect. I found the frame in a warehouse close to the shop and placed a shipping order with the distribution center. + +There is a lot to unpack in that brief overview. From a note takers perspective we can identify: + +- A high level process: notification of issue -> assessment -> decision of action to take -> shipping arrangement + - Domain events in this process + - Warranty issue received. + - Warranty issue acknowledged by employee. + - Warranty issue assessed. + - Warranty issue resolution proposed + - Warranty issue resolution in progress + - Warranty issue resolved. + - Replacement product shipment received at warehouse + - Replacement product shipped + - Replacement product delivered +- A number of potential bounded contexts: + - Bike shop. + - Manufacturer. + - External Warehouse. + - Shipping +- Domain entities + - Bike, + - size: xl + - category: Mountain Bike + - Product name: Vision + - Bike Shop: + - Name: Harrie's + - Shipping address? + - Warranty notification: + +These things could feed our ubiquitous language, expand our bounded contexts, add to our domain events and ultimately inform our implementation. + +From the interviewer perspective we can now take this interview in a lot of directions. Since we are looking to rebuild the warranty system from the ground up, the first thing we want to focus on is the warranty notification data. + +You: Can you tell me more about how you were notified of the issue and what information you needed to assess this incident? + +Nevin: Sure, Harries emailed us about the issue. We require pictures of the bike, pictures of the broken part, the serial number, and a bit of info about how the break occurred. We have an email template we send them to fill in and ask any follow up questions over email. We also ask for a single point of contact with whom to work through the issue with on the shop end to simplify communications. Based on the type of break we assign a category to the issue. + +You: This is great would you mind emailing us that template? Can you forward us a few example customer interactions? + +Once again we have information that we can use to fill out our domain knowledge even more. It is great to try to collect any assets that may already exist to assist a process, often these organically grown processes built in a low fidelity way our early prototypes of what is really desired. We can also further develop our domain knowledge assets with this small question and answer cycle. + +- Domain entities + - Bike, + - size: xl + - category: Mountain Bike + - Product name: Vision + - Serial number + - Bike Shop: + - Name: Harrie's + - Shipping address? + - Email address + - Employees + - Warranty notification: + - Image of the bike + - serial number + - Image of the break + - How the break occurred + - Point of contact for warranty submitor + - Break type category + + + This process could go on to investigate shipping workflows, warehouse interactions, manufacturer needs etc... + + You: Thanks for all this information Nevin this is amazing. Would you mind if I reach out to you in the future for follow up information or to share ideas with you and get your feedback? + + Nevin: That would be great I am really excited to fix this. + + You: I am also wondering if you would let me shadow you for an hour or so while you work on some warranties to see what you workflow looks like? + +## Note taking + +It is tempting to try to model our database or layout our objects in our notes. Ideally notes will quickly capture ideas and not model things for us. Ultimately we are trying to understand our domain, not figure out implementation details. + +Try to keep your notes short, using post it notes for note taking will encourage this as space is limited. We want to capture just enough information to understand the domain. Notes like: + +- Bike, + - size: xl + - category: Mountain Bike + - Product name: Vision + - Serial number + +Are preferred to: + +> A bike has a size, category, product name and serial number. Each warranty has a bike and the warranty belongs to a bike shop. + +This is the start of a db model, you will get there eventually but it is far to early in the process to know if what you are doing enforces the domain properly. + + +## Developing your ubiquitous language +At this point we should think of things as developing an encyclopedia of institutional knowledge. In fact I would recommend taking on this task at this point. Every interview you undertake should be approached as an opportunity to collect and share very useful domain knowledge that may currently exist in a silo. + +If you can build a wiki or some other communication tool that can state what all the domain language is in different parts of you institution then you have a communication standard you can reference for new hires, naming things in the future and understanding what user means in the context of sales. + +# Job Shadowing + +Nevin has invited us back to do some job shadowing. In this process we are looking to gain on the ground experience to see all the parts of the process that are often not discussed in an interview because they are so ingrained in day to day activity they seem obvious to the domain expert. + +As an outside party we need to steep ourselves in the world of the domain expert a bit, as what they take for granted maybe completely foreign to us. We may also see extremely inefficient practices that computers could automate, that the domain expert may never recognize as a problem. + +## Setup +In a job shadowing exercise we are entering into the workspace of the domain expert. We need to try to set ourselves up to be as un-obtrusive as possible. Often times this means preparing ourselves as humans to be stealth. Have you pens and paper ready, get your coffee in hand or snack and prepare to sit back and be as quite as a mouse, what ever that means for you. + +You likely also want to arrange a time when the domain expert is actively undertaking the work you want to observe. Find a time that works well for this observation, ideally they should be moderately busy, meaning not to overwhelmed to answer your questions but busy enough to show some variety. + +When you come into their workspace expect there to be a bit of friendly interaction at the beginning and perhaps a bit of awkwardness as they start their day. Starting work is hard enough, doing it while being watched can definitely impact performance. You can try to ease tension by bringing donuts, telling jokes and then slowly receding back. + +## Observation + +While observing try to ask as few questions of the observant as possible. I like to take notes of any questions I had and save them for the end. It is normal to have a follow up short interview after the shadowing session. It may also be helpful to have the domain expert explain out loud what they are doing as they undertake their work almost like a stream of consciousness. I tend to reserve this to particularly complex tasks as it can influence their workflow. + +There are a few key areas I tend to hone in on when observing a domain expert doing their work. The main 3 are tools, processes and interactions. I find these high level categories I can hone in on and organize my thinking and notes around. + +### Tools + +Any tooling the domain expert interacts with is helpful to note. Often we are integrating with, replacing or augmenting tools. Having an understanding of what tools are in place, what they are used for, why they where chosen, where they fit in the process and what features are used is often handy to note for later use. + +It can also help us to understand were our tooling fits in the broader picture, are these outside system interacting with ours, could they? Should they? Are their patterns or language familiar to the domain expert from these tools that we can co-opt to simplify the environment of the domain expert? Tools in the environment are important to any domain expert, thus they should be important to us as augmenters of the environment. + +### Processes + +How are entities moving through the environments, what tools are taking inputs, creating outputs. What do these inputs and outputs look like? Is most of the process happening on a computer? Is there physical workspace to consider? + +Most of the workflow we are examining is process, whether or not it is recognized as such or any good. Looking for patterns in the workflow and things that could potentially become patterns is a good thing to note. + +This is a great time to outline domain entities, domain events and states that entities could exist in. You may want to actually draw timelines, comics, physical maps or process diagrams to show how things move through the process. + +### Interactions + +Interactions between different domain experts, processes or tools are all helpful to capture. Is there a point in time where a certain entity transfer to another group in you organization? Does the domain expert need to reach out to other places for information? Does information transfer from one system to another? How are the domain experts entering data into different places? + +All these interactions likely point to some piece of tooling you will need to be aware of or consider implementing. Try to map out how entities are moving around in the context bounds and what action is required to move them in an out of these interactions. + +### Looking for hacks + +This is not one of my top 3 areas for focus, but hacks are really valuable for finding confusing or troublesome parts of a system. If a domain expert has take the time to implement a hack to get around a situation it is likely that they understand something the implementors did not and got frustrated to a point that they fixed it themselves. + +Hacks can take many forms, post it notes with directions, macros in excel, browser plugins, copy and past patterns and more. Any thing where the user created a one off custom solution to a problem is worth exploring. \ No newline at end of file From 182d7011cae8defd4d9e3389cc923584b6c29a12 Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Wed, 13 Feb 2019 13:18:49 -0500 Subject: [PATCH 18/30] blocks --- book/proposal/sample chapter2.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/book/proposal/sample chapter2.md b/book/proposal/sample chapter2.md index 94a6494..68513ce 100644 --- a/book/proposal/sample chapter2.md +++ b/book/proposal/sample chapter2.md @@ -153,9 +153,9 @@ The time has come to conclude our interview, at this point you can thank the par It is time to interview our warranty domain expert, Nevin, we walk through our introductions and purpose statement, obtain consent one last time then jump into our questions. -You: Can you tell me about the last warranty you processed? +> You: Can you tell me about the last warranty you processed? -Nevin: This xl Vision mountain bike has a broken frame, Harrie's bike shop contacted me via email to notify me about the issue. We sent out a new frame once we identified it was a manufacturing defect. I found the frame in a warehouse close to the shop and placed a shipping order with the distribution center. +> Nevin: This xl Vision mountain bike has a broken frame, Harrie's bike shop contacted me via email to notify me about the issue. We sent out a new frame once we identified it was a manufacturing defect. I found the frame in a warehouse close to the shop and placed a shipping order with the distribution center. There is a lot to unpack in that brief overview. From a note takers perspective we can identify: @@ -189,11 +189,11 @@ These things could feed our ubiquitous language, expand our bounded contexts, ad From the interviewer perspective we can now take this interview in a lot of directions. Since we are looking to rebuild the warranty system from the ground up, the first thing we want to focus on is the warranty notification data. -You: Can you tell me more about how you were notified of the issue and what information you needed to assess this incident? +> You: Can you tell me more about how you were notified of the issue and what information you needed to assess this incident? -Nevin: Sure, Harries emailed us about the issue. We require pictures of the bike, pictures of the broken part, the serial number, and a bit of info about how the break occurred. We have an email template we send them to fill in and ask any follow up questions over email. We also ask for a single point of contact with whom to work through the issue with on the shop end to simplify communications. Based on the type of break we assign a category to the issue. +> Nevin: Sure, Harries emailed us about the issue. We require pictures of the bike, pictures of the broken part, the serial number, and a bit of info about how the break occurred. We have an email template we send them to fill in and ask any follow up questions over email. We also ask for a single point of contact with whom to work through the issue with on the shop end to simplify communications. Based on the type of break we assign a category to the issue. -You: This is great would you mind emailing us that template? Can you forward us a few example customer interactions? +> You: This is great would you mind emailing us that template? Can you forward us a few example customer interactions? Once again we have information that we can use to fill out our domain knowledge even more. It is great to try to collect any assets that may already exist to assist a process, often these organically grown processes built in a low fidelity way our early prototypes of what is really desired. We can also further develop our domain knowledge assets with this small question and answer cycle. @@ -219,11 +219,11 @@ Once again we have information that we can use to fill out our domain knowledge This process could go on to investigate shipping workflows, warehouse interactions, manufacturer needs etc... - You: Thanks for all this information Nevin this is amazing. Would you mind if I reach out to you in the future for follow up information or to share ideas with you and get your feedback? +> You: Thanks for all this information Nevin this is amazing. Would you mind if I reach out to you in the future for follow up information or to share ideas with you and get your feedback? - Nevin: That would be great I am really excited to fix this. +> Nevin: That would be great I am really excited to fix this. - You: I am also wondering if you would let me shadow you for an hour or so while you work on some warranties to see what you workflow looks like? +> You: I am also wondering if you would let me shadow you for an hour or so while you work on some warranties to see what you workflow looks like? ## Note taking @@ -292,4 +292,4 @@ All these interactions likely point to some piece of tooling you will need to be This is not one of my top 3 areas for focus, but hacks are really valuable for finding confusing or troublesome parts of a system. If a domain expert has take the time to implement a hack to get around a situation it is likely that they understand something the implementors did not and got frustrated to a point that they fixed it themselves. -Hacks can take many forms, post it notes with directions, macros in excel, browser plugins, copy and past patterns and more. Any thing where the user created a one off custom solution to a problem is worth exploring. \ No newline at end of file +Hacks can take many forms, post it notes with directions, macros in excel, browser plugins, copy and past patterns and more. Any thing where the user created a one off custom solution to a problem is worth exploring. From c805800e97815f524a17a7754fc69f13af20f68d Mon Sep 17 00:00:00 2001 From: acrlewis Date: Wed, 13 Feb 2019 12:13:54 -0700 Subject: [PATCH 19/30] outline: minor typos --- book/proposal/outline.md | 66 ++++++++++++++++++++-------------------- 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/book/proposal/outline.md b/book/proposal/outline.md index ec1ce8b..7d001ee 100644 --- a/book/proposal/outline.md +++ b/book/proposal/outline.md @@ -2,101 +2,101 @@ ## Chapter 1: Organic Software with Design Thinking and Domain Driven Development -Organic software is the modern ideal and a quality needed if we seek to perpetuate the success and social responsibility of open source to a wider set of problems. We seek to serve the whole of life, seeking solutions which effortlessly enhance our environments in a informed, thoughtful and responsible manner. +Organic software is the modern ideal and quality needed if we seek to perpetuate the success and social responsibility of open source to a wider set of problems. We seek to serve the whole of life, seeking solutions which effortlessly enhance our environments in an informed, thoughtful and responsible manner. Organic software: - Seeks a natural progression of its environment. - Flows and changes effortlessly with its domain. - Satisfy social needs responsibly. -- Focuses on the communicating consistently across the implementation and domain. +- Focuses on communicating consistently across the implementation and domain. - Seek empowering solutions over narrowly targeted solutions. -Crafting organic software is challenging! Solving problems in a appropriate way without first exposing yourself to the situation is impossible! But this is consistently how we approach software development. A product manager tries to understand a feature someone thinks they need, the product manager then condense this down into an issue that can fit into our software project management process of choice and a developer to implements. +Crafting organic software is challenging! Solving problems in an appropriate way without first exposing yourself to the situation is impossible! But this is consistently how we approach software development. A product manager tries to understand a feature someone thinks they need, the product manager then condenses this down into an issue that can fit into our software project management process of choice and a developer to implements. -This leads to a series of problems with the solution, a lack of domain knowledge throughout the organization, mis-leading code, poor data structures, un-maintainable codebases, in-sufficient or incorrect solutions and worse. +This leads to a series of problems with the solution, a lack of domain knowledge throughout the organization, misleading code, poor data structures, un-maintainable codebase, insufficient or incorrect solutions and worse. -We will explore the intersection of the fields of design thinking, agile and domain driven design as a better way to build products. +We will explore the intersection of the fields of design thinking, agile and domain-driven design as a better way to build products. -In this first chapter we will take a look at what design thinking is, outline the commonly referred to process and pick apart whether it needs to be done in totality. +In this first chapter, we will take a look at what design thinking is, outline the commonly referred to process and pick apart whether it needs to be done in totality. -Design thinking process can offer an excellent way to engage domain experts in the creation of a product. Domain driven design offers a set of tools for taking these findings and creating software implementations that more concisely capture the knowledge we have learned. +Design thinking process can offer an excellent way to engage domain experts in the creation of a product. Domain-driven design offers a set of tools for taking these findings and creating software implementations that more concisely capture the knowledge we have learned. In this chapter we will introduce domain driven design ideas we will be covering in this book: - Ubiquitous languages - Glossaries - Context boundaries for primary and supporting domains -- Domain events +- Domain events - Org personas ## Chapter 2: Discovery -In this book we will be outlining the steps a development team is taking to implement a new warranty tool for a bike company. The first step to working on any problem is learning everything you can about the problem. This phase is often one that software developers are left out of. We will explore why this is and why it should not be the case. +We will outline the steps a development team is taking to implement a new warranty tool for a bike company. Working on any problem first requires learning everything you can about the problem. This critical phase is often one that software developers are left out of. We will explore why this is and why it should not be the case. The first exercise introduced is a Stake Holder Mapping. This is a method for identifying potential domain experts to consult regarding the current process in place for warranty issues. The StakeHolder mapping also serves as a nice first pass at a bounded context diagram. -Next we will introduce how to develop buy in from domain experts and bring them into the process. This includes setting expectations, motivating participation and introducing the problem. +Next, we will introduce how to develop buy-in from domain experts and bring them into the process. This includes setting expectations, motivating participation and introducing the problem. The final method introduced in this chapter is Experience Diagraming. This is a method for exploring the current process and visualizing it. Each of our identified stakeholders will be utilized to help outline all the steps a warranty takes from creation to completion from their perspective. This lifecycle exploration helps us to see potential areas of improvement. It also provides a collection point to work on our context boundaries and ubiquitous language. ## Chapter 3: Interviewing and Job Shadowing -Now that we have identified all the stakeholders and processes we will be impacting, we can develop a picture of day to day operations. Job shadowing and interviewing are two valuable tools for exploring how the user does the task you are looking to augment everyday. +Now that we have identified all the stakeholders and processes we will impact, we can develop a picture of day to day operations. Job shadowing and interviewing are two valuable tools for exploring how the user does the task you are looking to augment every day. -In this chapter we will outline how to conduct a successful interview and how to do job shadowing. This includes +In this chapter, we will outline how to conduct a successful interview and how to do job shadowing. This includes - Using our stakeholder map and context bounding to identify interviewees. - Getting permission. - How to run a successful interview process. -- Finding in roads for future collaboration. +- Finding inroads for future collaboration. - Capturing ubiquitous language. -- Diagramming process flows and updating our experience diagrams with new context. +- Diagramming process flows and updating our experience diagrams with the new context. - Identifying domain events. - Looking for hacks and other contextual clues. ## Chapter 4: Gaining Context -In this chapter we introduce two methods for contextualizing information we gained in the prior exercises affinity clustering and rose bud thorn. +In this chapter, we introduce two methods for contextualizing information we gained in the prior exercises affinity clustering and rose, bud, thorn. -Affinity clustering is a method which helps to sort our notes into contextually similar groups. Through this process we sort the findings and observe groups that naturally start to emerge. Often we find numerous groupings inside a problem area that may map to or expand upon our contextual boundaries. We will use the output of this exercise in three ways, first to redefine our contextual boundaries. Next we will seek related sets of problems we can later prioritize. Finally we will introduce ways to utilize affinity mapping to organize our collected language, processes and domain events. +Affinity clustering is a method which helps to sort our notes into contextually similar groups. Through this process, we sort the findings and observe groups that naturally start to emerge. Often we find numerous groupings inside a problem area that may map to or expand upon our contextual boundaries. We will use the output of this exercise in three ways, first to redefine our contextual boundaries. Next, we will seek related sets of problems we can later prioritize. Finally, we will introduce ways to utilize affinity mapping to organize our collected language, processes and domain events. -The second method introduced is Rose Bud Thorn this tool helps categorize findings into positive (Rose), negative (Thorn) and items with potential for improvement (Bud). We will then use this as a way to discuss identifying potential areas for improvement. +The second method introduced is Rose Bud Thorn. This is a tool used to categorize findings into positive (Rose), negative (Thorn) and items with potential for improvement (Bud). We will then use this as a way to discuss identifying potential areas for improvement. ## Chapter 5: Creating our Ubiquitous Language Glossary We now have a collection of language and bounded context that will allow us to create a glossary. We will explore what a glossary is and how to create one from your findings. -The book will also show some pseudo code examples of how this language and context bound idea can be implemented to lead to cleaner implementation and separation of concerns. We will explore techniques for name-spacing code, organizing files, naming methods vs. objects and separating concerns. +The book will also show some pseudo code examples of how this language and context-bound idea can be implemented to lead to cleaner implementation and separation of concerns. We will explore techniques for name-spacing code, organizing files, naming methods vs. objects and separating concerns. We will also explore how to keep these glossaries up to date and useful in your projects. ## Chapter 6: Defining a problem statement -Often times our problem statement is handed to us due to business needs, however the process by which we choose the problem to work on and state the problem are often difficult tasks that can be aided by process. There are also situations in which we maybe using design thinking to explore a new process inside our development processes. +Often times our problem statement is handed to us due to business needs, however, the process by which we choose the problem to work on and state the problem are often difficult tasks that can be aided by the process. There are also situations in which we may be using design thinking to explore a new process inside our development processes. -Defining a problem statement can be political and difficult to word. Our Rose, Bud, Thorn and Affinity Clustering activities have exposed a number of areas which we can focus on but picking one to hone in on is a matter of aligning people. When we do define it we need to ensure the language we use is open enough to encourage our creative process, yet bounded enough to keep us focused on our problem area. +Defining a problem statement can be political and difficult to write. Our Rose, Bud, Thorn and Affinity Clustering activities have exposed a number of areas which we can focus on but picking one to focus on is a matter of aligning people. When we do define it we need to ensure the language we use is open enough to encourage our creative process, yet bounded enough to keep us focused on our problem area. -We will utilize explore proper language for phrasing problem statements and why language matters. Once we have a identified problem statements we will look at two methods of choosing the problem to work on, bracketing and star voting. +We will utilize explore the proper language for phrasing problem statements and why language matters. Once we have identified the problem statements, we will look at two methods of choosing the problem to work on, bracketing and star voting. ## Chapter 7: Ideation -Now that we have a problem statement to work on we need to start thinking about how to approach our problem. Ideation is a process of generating as many ideas as possible. These techniques are useful in a number of scenarios where you need to generate potential solutions to a well understood problem. +Now that we have a problem statement to work on we need to start thinking about how to approach our problem. Ideation is a process of generating as many ideas as possible. These techniques are useful in a number of scenarios where you need to generate potential solutions to a well-understood problem. We will introduce a few exercises to help with the brainstorming process. -First we will try redefining the opportunity by changing our statement starter by turning it into a question in the phrases of who, what, when, where, why and how. We will use each of these prompts to define as many answers as possible. +First, we will try redefining the opportunity by changing our statement starter by turning it into a question in the phrases of who, what, when, where, why and how. We will use each of these prompts to define as many answers as possible. -Next we will look at creating a creative matrix, in this process we define 5 assets we have at our dispense to solve the problem and we align those with our domain areas to brainstorm how the statement starter could be solved, approached etc in different combinations of tools and subdomains. +Next, we will look at creating a creative matrix. In this process, we define 5 assets we have at our dispense to solve the problem and we align those with our domain areas to brainstorm how the statement starter could be solved, approached etc in different combinations of tools and subdomains. ## Chapter 8: Ranking competing ideas -At this point we have created a number of competing solutions, deciding which one's to pursue is often politically charged. We need tools to remove the personal attachment we hold to ideas and look at them subjectively. We will look at three exercises for doing this work. These tools are exceptionally valuable for going through backlogs, ranking company alignment goals like OKRs or getting stakeholders to express their needs accurately. +At this point we have created a number of competing solutions, deciding which ones to pursue is often politically charged. We need tools to remove the personal attachment we hold to ideas and look at them subjectively. We will look at three exercises for doing this work. These tools are exceptionally valuable for going through backlogs, ranking company alignment goals like OKRs or getting stakeholders to express their needs accurately. -First we will look at importance difficulty mapping. In this exercise we create a x,y graph that shows the importance and difficulty of every item we came up with during ideation in a quadrant. This visualization shows us the low hanging fruit, high-importance difficult items, low importance low difficulty items and low important high difficulty items; assisting us in choosing what to work on. +First, we will look at Importance Difficulty Mapping. In this exercise, we create an (x,y) graph to visualize the importance and difficulty of every item we came up with during ideation in a quadrant. This visualization shows us the low hanging fruit, high-importance difficult items, low-importance low- difficulty items, and low-important high-difficulty items; assisting us in choosing what to work on. -Buy a feature is a game in which each player is given a budget and can choose which features they would pay for. This show which features are most valuable to which stakeholders. +Buy a Feature is a game in which each player is given a budget and can choose which features they would pay for. This show which features are most valuable to which stakeholders. -Brackets are a fun way to have features compete against each other for votes. As you work through the bracket people voting are allowed to change what they are routing for so everyones voice is heard to completion. +Brackets are a fun way to have features compete against each other for votes. As you work through the bracket people voting are allowed to change what they are rooting for so everyone's voice is heard to completion. ## Chapter 9: Prototyping @@ -104,22 +104,22 @@ Now that we have the ranked ideas we wish to implement, it is time to validate o There are two types of prototyping that make sense for software developers that I have experienced. -The first is a user facing prototype that shows off a feature that they will be working with, this is an invaluable alignment tool for working with stakeholder. +The first is a user-facing prototype that shows off a feature that they will be working with, this is an invaluable alignment tool for working with stakeholder. The second is a technology prototype, often when we set out to build a new feature, app, etc... much of our architecture decision is based on the strongest political position in the room or the most familiar tech. Technology prototypes allow us to break out of this and offer a space to experiment and validate different ideas. We will outline how to run a successful technical prototyping session. ## Chapter 10: Validating and learning from Prototypes -We prototype in order ensure we are choosing the right direction, but learning from prototypes is an art. We need to separate our preference and bias and see what the prototype is really telling us. We will look at user testing our stakeholder facing prototypes and how to iterate. +We prototype in order to ensure we are choosing the right direction, but learning from prototypes is an art. We need to separate our preference and bias and see what the prototype is really telling us. We will look at user testing our stakeholder facing prototypes and how to iterate. We will also look at tools for qualifying technical prototypes, setting criteria, validating new tech and outlining how to assess risk. ## Chapter 11: Cooking with ingredients -Throughout this book we have followed a very defined line of discover, ideate, prototype and validate. This recipe is common in design thinking, however the dogma of this process is misleading. Much like a great chef starts by following a recipe, they soon learn to break the ingredients apart and use them appropriately in different scenarios. We can utilize any one of these different methods in a number of scenarios and add a dash of ideation here and a prototyping session there without following the entire process. +Throughout this book, we have followed a very defined line of discovery, ideate, prototype and validate. This recipe is common in design thinking, however, the dogma of this process is misleading. Much like a great chef starts by following a recipe, they soon learn to break the ingredients apart and use them appropriately in different scenarios. We can utilize any one of these different methods in a number of scenarios and add a dash of ideation here and a prototyping session there without following the entire process. -In this chapter we will look at running better retros, aligning a backlog, blameless incident response, prototyping competing implementation details, and how to run partial or full design thinking process in short periods of time. +In this chapter we will look at running better retros, aligning a backlog, blameless incident response, prototyping the competing implementation details, and how to run partial or full design thinking process in short periods of time. ## Chapter 12: Going remote -Many of the tools in this book are possible to do remotely as well. Let's take some of the common methods in this book and discuss how we can bring them to remote teams.:w +Many of the tools in this book are possible to do remotely as well. Let's take some of the common methods in this book and discuss how we can bring them to remote teams.:w \ No newline at end of file From fbc2abf84d42e2aef5482ab5ac18abd15f72e72f Mon Sep 17 00:00:00 2001 From: acrlewis Date: Wed, 13 Feb 2019 12:32:18 -0700 Subject: [PATCH 20/30] proposal: minor edit suggestions --- book/proposal/proposal.md | 50 +++++++++++++++++++-------------------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/book/proposal/proposal.md b/book/proposal/proposal.md index 52099d0..65e0aef 100644 --- a/book/proposal/proposal.md +++ b/book/proposal/proposal.md @@ -2,7 +2,7 @@ ### By: Cory Gwin ## Overview -Technology is simply a tool for solving a problem. Arguably the most valuable tool any developer has in their tool chest is the ability to understand, communicate about, break down a problem and provide a proven solution. Most organization find this incredibly difficult to do and often organization focus on how fast they can ship instead of how well their solutions are received. Oddly, as terrible as we are at this part of our jobs, our problem solving tools get no where near the attention as our text editor skills, scripting language of choice or deployment skills and other tools in our development war chest. Instead we hand it off to other parts of the organization and later complain about them throwing requirements over the wall without asking if we should break down the wall. +Technology is simply a tool for solving a problem. Arguably the most valuable tool any developer has in their tool chest is the ability to understand, communicate about, break down a problem and provide a proven solution. Most organization find this incredibly difficult to do and often organization focus on how fast they can ship instead of how well their solutions are received. Oddly, as terrible as we are at this part of our jobs, our problem-solving tools get nowhere near the attention as our text editor skills, the scripting language of choice or deployment skills and other tools in our development war chest. Instead, we hand it off to other parts of the organization and later complain about them throwing requirements over the wall without asking if we should break down the wall. It is time to break down these artificial boundaries and take responsibility for the solutions we build. The agile manifesto states we should prefer customer collaboration over contract negotiation. As developers we often leave the customer collaboration to others in our organization, leaving only short user stories or issues to gather context. This leads to a number of problems including: @@ -13,7 +13,7 @@ It is time to break down these artificial boundaries and take responsibility for - Scope change or creep. - Lost context over time. - Code that does not properly convey intent. -- Unintended consequence of poorly modeled data. +- Unintended consequences of poorly modeled data. - Incorrect prioritization. Our workflows and structures create communication barriers we must break down in order to move our implementations closer to their domains. As developers, our goals should include moving ourselves and our code closer to the domain. This requires understanding not only the problem being solved by a feature but also, more broadly an understanding of the field we are working in. @@ -28,30 +28,30 @@ Design thinking offers a toolset for gathering insight into the domain that can - Identifying focused solutions. - Providing insight into how an implementation may evolve. -Following the path of a team replacing a legacy application with a new application this book will explore tools that can be utilized to break down a domain and better communicate with domain experts. The book will introduce a number of design thinking exercises and explain how they can be applied in different scenarios to help agile developers craft clearer implementations. +Following the path of a team replacing a legacy application with a new application, this book will explore tools that can be utilized to break down a domain and better communicate with domain experts. The book will introduce a number of design thinking exercises and explain how they can be applied in different scenarios to help agile developers craft clearer implementations. ## What this book will cover: - Introduce the concept of design thinking. - Introduce the following design thinking methodologies from the perspective of the developer: - - Stakeholder mapping. - - Interviewing. - - Job shadowing. - - Rose Bud Thorn. - - Affinity Mapping. - - Experience diagramming. - - Importance/Difficulty matrix. - - Feature Voting. - - Creative matrixes. - - Technical prototyping. - - Story boarding UI's - - Stakeholder validation. - - More?? + - Stakeholder mapping. + - Interviewing. + - Job Shadowing. + - Rose Bud Thorn. + - Affinity Mapping. + - Experience diagramming. + - Importance/Difficulty matrix. + - Feature Voting. + - Creative matrixes. + - Technical prototyping. + - Storyboarding UI's + - Stakeholder validation. + - More?? - Introduce domain driven design concepts: - - Ubiquitous language. - - Context bounding. - - Domain events. -- Outline effective tools for using design thinking to create ubiqoutous language, bounded contexts and domain events. + - Ubiquitous language. + - Context bounding. + - Domain events. +- Outline effective tools for using design thinking to create ubiquitous language, bounded contexts and domain events. - Outline rules for effective design thinking on agile teams. - Discuss ideas for bringing these methods into teams that are not familiar with design thinking. @@ -64,17 +64,17 @@ This book will offer a design thinking tools set aimed at software development, - Communicating effectively with stakeholders. - Identifying when to utilize design thinking methods and when not to. -- The discover, ideate, prototype phases of design thinking. +- The discovery, ideate, prototype phases of design thinking. - Individual design thinking methodologies and when to use them in the software development lifecycle. - How to run better retros. - How to evaluate what to build given competing priorities. -- Understanding the business domain they work in day to day. -- Building long lived communication tools that impact internal/external communication and code design. +- Understanding the business domain they work in the day-to-day. +- Building long-lived communication tools that impact internal/external communication and code design. ## Why we should get excited about your topic: -In the Cathedral and the Bazaar a number of important ideas where set forth related to working closer with our stakeholder: +In the Cathedral and the Bazaar a number of important ideas were set forth related to working more closely with our stakeholder: 1. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. 1. Release early. Release often. And listen to your customers. @@ -84,7 +84,7 @@ In the Cathedral and the Bazaar a number of important ideas where set forth rela 1. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. 1. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry) 1. To solve an interesting problem, start by finding a problem that is interesting to you. -1. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one. +1. Provided the development coordinator has a communications medium at least as good as the Internet and knows how to lead without coercion, many heads are inevitably better than one. Interestingly it contradicts itself pointing out a major issue with the way we develop software: From ebb89eedbc3e8831f29458cf05c5531b4004a541 Mon Sep 17 00:00:00 2001 From: acrlewis Date: Wed, 13 Feb 2019 12:36:39 -0700 Subject: [PATCH 21/30] proposal: minor edit suggestion --- book/proposal/proposal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/proposal/proposal.md b/book/proposal/proposal.md index 65e0aef..b7adeef 100644 --- a/book/proposal/proposal.md +++ b/book/proposal/proposal.md @@ -60,7 +60,7 @@ This book is suitable for developers, managers, product manager, project manager ## Why is your book different? -This book will offer a design thinking tools set aimed at software development, with a minor focus on domain driven design. It will introduce software developers to all the phases of design thinking and teach them skills to help solve problems in more creative ways, skills emphasized include: +This book will offer design thinking tools set aimed at software development, with a minor focus on domain driven design. It will introduce software developers to all the phases of design thinking and teach them skills to help solve problems in more creative ways, skills emphasized include: - Communicating effectively with stakeholders. - Identifying when to utilize design thinking methods and when not to. From cd72da76061a6eefe361512cf1558c61dfc59419 Mon Sep 17 00:00:00 2001 From: acrlewis Date: Wed, 13 Feb 2019 12:56:31 -0700 Subject: [PATCH 22/30] ch2 is so awesomegit push origin cg-book-proposal --- book/proposal/sample chapter2.md | 134 +++++++++++++++---------------- 1 file changed, 67 insertions(+), 67 deletions(-) diff --git a/book/proposal/sample chapter2.md b/book/proposal/sample chapter2.md index 68513ce..540136a 100644 --- a/book/proposal/sample chapter2.md +++ b/book/proposal/sample chapter2.md @@ -1,20 +1,20 @@ # Interviewing and Job Shadowing -What better way to learn about a topic then spend time with an expert. In our stakeholder mapping exercise we began to identify different types of users we should communicate with to better understand their working context and challenges. Now we will explore some methods for engaging these domain experts to increase our awareness of their language, workflows, entities and problems. +What better way to learn about a topic then spend time with an expert. In our stakeholder mapping exercise we began to identify different types of users we should communicate with to better understand their working context and challenges. Now we will explore some methods for engaging these domain experts to increase our awareness of their language, workflows, entities, and problems. -In this chapter we will introduce interviewing and job shadowing. We will use these methods to dig deep into the warranty workflow that exists today in order to understand the domain we are working within. We will be looking to gain as many key insights as we can to aid our implementation choices in the future. +In this chapter, we will introduce interviewing and job shadowing. We will use these methods to dig deep into the warranty workflow that exists today in order to understand the domain we are working within. We will be looking to gain as many key insights as we can to aid our implementation choices in the future. -We will explore how to conduct better interviews, get stakeholder buy in, common pitfalls that could bias you implementation and how to collect common language, domain events, identify entities and processes. +We will explore how to conduct better interviews, get stakeholder buy-in, common pitfalls that could bias your implementation and how to collect common language, domain events, identify entities and processes. # Identifying an interviewing topic -Our warranty process has been flagged for replacement because it is built in a legacy system that we believe is leading to tracking issues and slowing down communications. We have been implementing a new customer support portal in sales and management wants to tie the two systems together for a variety of reasons. The top down pressure is revolving around tracking costs in warranty, but warranty is expressing concerns about customer interactions and fearing a changing process. +Our warranty process has been flagged for replacement because it is built in a legacy system that we believe is leading to tracking issues and slowing down communications. We have been implementing a new customer support portal in sales and management wants to tie the two systems together for a variety of reasons. The top-down pressure is revolving around tracking costs in warranty, but the warranty is expressing concerns about customer interactions and fearing a changing process. -Our interview could go in a number of directions based on what we know. It would be easy to focus on what management wants out of the transition as hierarchies lead to this kind of approach. In our case we choose to seek the topic which is the most domain centric. What does that mean? Glad you asked, we want to get at the most common workflows, entities, processes in the central workflows. In our case what is the common lifecycle of a warranty. This will ensure our solution first focuses on the primary work that needs to be completed, primary domain. We want to avoid getting into the weeds of how are cost being tracked at this point, although it is a motivating force in the org, once we have a solid core domain modeled we can move to cost tracking as a separate subdomain and explore that problem independently. It maybe a driver for why we are making the switch, but the important thing to tackle first is the core domain. +Our interview could go in a number of directions based on what we know. It would be easy to focus on what management wants out of the transition as hierarchies lead to this kind of approach. In our case, we choose to seek the topic which is the most domain centric. What does that mean? Glad you asked, we want to get at the most common workflows, entities, processes in the central workflows. In our case, what is the common lifecycle of a warranty? This will ensure our solution first focuses on the primary work that needs to be completed, primary domain. We want to avoid getting into the weeds of how cost is being tracked at this point, although it is a motivating force in the org, once we have a solid core domain modeled we can move to cost tracking as a separate subdomain and explore that problem independently. It may be a driver for why we are making the switch, but the important thing to tackle first is the core domain. # Determining who to interview -Different domain experts will work with our system in different ways and have differing needs of the system. If we refer to our bounded contexts we can gain some insight into different entities that may need to access this system, we can also do a separate stakeholder mapping exercise just for this project, it may show new bounded contexts to account for. +Different domain experts will work with our system in different ways and have different needs of the system. If we refer to our bounded contexts we can gain some insight into different entities that may need to access this system, we can also do a separate stakeholder mapping exercise just for this project, it may show new bounded contexts to account for. We want to ensure we interview a few people from each context to get some different perspectives, when possible these people should have very different backgrounds. For our warranty system we have identified the following domain experts to discuss this system with: @@ -26,19 +26,19 @@ We want to ensure we interview a few people from each context to get some differ - Large outdoor sporting goods store shop manager. - Product management. -This represents the core group of domain experts that touch the warranty system on a daily basis today. Each of them have very different roles in the company and need very different things out of the system. This should give us a broad view of the domain space and how the different context view things. +This represents the core group of domain experts that touch the warranty system on a daily basis today. Each of them may have very different roles in the company and need very different things out of the system. This should give us a broad view of the domain space and how the different contexts view things. -We have a pretty long list here, generally speaking it maybe hard to talk to this many stakeholders. Trying to talk to 2-3 is better then talking to none, +We have a pretty long list here, generally speaking, it may be hard to talk to so many stakeholders. However, talking to 2-3 is always better than talking to none. # Getting permission from stakeholders -We need to reach out to each of our domain experts and get their permission to do the interviews. The way we speak to each group maybe different in tone based on who they are, our relationship with them, and their relationship to the project. +We need to reach out to each of our domain experts and get their permission to do the interviews. The way we speak to each group may be different in tone based on who they are, our relationship with them, and their relationship to the project. -Warranty should hopefully be aware of the project, getting permission from the core domain experts who you are directly affecting their workflow should be easy. Some times you need to deal with push back about changing processes, but this is an opportunity to ease tensions and express you ambitions to improve their day to day work. Try building enthusiasm in the project by showing a willingness to work together and project often go from dreaded to exciting as the domain experts see the ability to change their day to day workflows in a positive way. +Warranty should hopefully be aware of the project, getting permission from the core domain experts who you are directly affecting their workflow should be easy. Sometimes you need to deal with push back about changing processes, but this is an opportunity to ease tensions and express your ambitions to improve their day to day work. Try building enthusiasm in the project by showing a willingness to work together and project often go from dreaded to exciting as the domain experts see the ability to change their day to day workflows in a positive way. -Outside collaborators such as bike shops are often trickier, in this case I will often leverage the relationship a sales rep has with a shop or find a shop warranty particularly enjoys. Often times your domain experts can grease the wheels and even get outside collaborators excited about contributing back toward improving systems they dislike. +Outside collaborators such as bike shops are often trickier, in this case, I will often leverage the relationship a sales rep has with a shop or find a shop warranty particularly enjoys. Often times your domain experts can grease the wheels and even get outside collaborators excited about contributing back toward improving systems they dislike. -Internal collaborators like sales may often state they don't have time to do an interview. These interviews can sometimes be the trickiest in some ways, however I have had success with drop in conversation or offering to take some one out to lunch. +Internal collaborators like sales may often state they don't have time to do an interview. These interviews can sometimes be the trickiest in some ways, however, I have had success with drop-in conversation or offering to take someone out to lunch. # Writing questions @@ -60,49 +60,49 @@ Filling in our topic `common warranty lifecycle` we end up with the following qu These question will spark conversation and have plenty of room to breath. The goal is to remove yourself from the conversation as much as possible and let the domain expert explain their process. It is common to interject bias into questions and we want to avoid that as much as possible. -It is important to mostly let the interviewee talk, we want to be an active listener. From time to time something will come up in the interview that you think it would be nice to expand upon. Having some potential lines in your questions to help you frame a question in a way the qualifies the statement or expands upon it is helpful. +It is important to mostly let the interviewee talk, we want to be an active listener. From time to time something will come up in the interview that you think it would be nice to expand upon. Having some potential lines in your questions to help you frame a question in a way that qualifies the statement or expands upon it is helpful. - If you had x how frequently would you have used it in the past 6 months? -- Just be be sure I am clear if you had x, what would it allow you to do that you cannot do now? +- Just to be sure I am clear if you had x, what would it allow you to do that you cannot do now? - Tell me more about why you prefer the competitors feature over ours. - If you had to choose between x and y which would you choose? -At some point in the interview the conversation will wind down. I like to offer the domain expert the ability to solution at this point. Often they have stewed over a potential solution or better workflow but don't posses the skills required to implement it. Have some questions ready for this time: +At some point in the interview, the conversation will wind down. I like to offer the domain expert the ability to create a solution at this point. Often they have stewed over a potential solution or better workflow but don't possess the skills required to implement it. Have some questions ready for this time: - How would you solve x? - If you could change one thing today what would it be? - If you had a magic wand what would you change? -I will add all these questions to a question outline so they are ready for interview day. +I will add all these questions to a question outline so they are ready for the interview day. ## Identifying bias -Creating interviewing questions or preparing for a job shadowing exercise can be a bit of a trap. As developers we have strong thoughts and opinions about our users and our products direction. These thoughts and opinions will impact the people we choose to talk to, the topics we lean towards, the questions we ask and how we listen. Acknowledging our biases before starting any sort of interviewing process is a good first step. +Creating interviewing questions or preparing for a job shadowing exercise can be a bit of a trap. As developers, we have strong thoughts and opinions about our users and our products direction. These thoughts and opinions will impact the people we choose to talk to, the topics we lean towards, the questions we ask and how we listen. Acknowledging our biases before starting any sort of interviewing process is a good first step. There are a number of common biases to examine prior to entering any period of interviewing. Identifying these biases in ourselves and our team are not just useful for interviewing and job shadowing but can also help us to understand our team dynamics, inter-team communications and product decision influencers. -The main biases I have seen include confirmation bias, survivorship bias, availability bias and social desirability. +The main biases I have seen include confirmation bias, survivorship bias, availability bias, and social desirability. #### Confirmation biases -Confirmation bias is the tendency to interpret new evidence as a confirmation of one's exiting beliefs. An example of confirmation bias is someone who holds the belief that left handed people are more creative than right handed people. In confirmation bias this individual would place greater importance on this correlation confirming their bias in their mind every time they met a left handed person who was creative, they would ignore the right handed people who are creative. +Confirmation bias is the tendency to interpret new evidence as a confirmation of one's existing beliefs. An example of confirmation bias is someone who holds the belief that left-handed people are more creative than right-handed people. In confirmation bias this individual would place greater importance on this correlation confirming their bias in their mind every time they met a left-handed person who was creative, they would ignore the right-handed people who are creative. -If you start to see questions that can be thought of as confirming an idea or seeking evidence of a belief you are probably in the middle of confirmation bias. Also be cognizant of the tendency humans have to ignore disconfirming information, this is how stereotypes perpetuate. +If you start to see questions that can be thought of as confirming an idea or seeking evidence of a belief you are probably in the middle of confirmation bias. Also, be cognizant of the tendency humans have to ignore disconfirming information, this is how stereotypes perpetuate. #### Survivorship biases -During WW2 the US Military was attempting to strengthen the armor on planes. In order to do this they took stock of where the bullet holes on the planes where located and placed more armor in those locations. This is a great example of the problem with survivorship bias. +During WW2 the US Military was attempting to strengthen the armor on planes. In order to do this, they took stock of where the bullet holes on the planes were located and placed more armor in those locations. This is a great example of the problem with survivorship bias. -The planes hit in the spot where the engineers where putting more armor was pointless because a plane could survive a hit in that location. They later realized they needed to put armor where they were not seeing holes because those planes where not surviving. +The planes hit in the spot where the engineers where putting more armor were far safer because a plane could survive a hit in that location. They later realized they needed to put armor where they were not seeing holes because those planes were not surviving. -We often see similar scenarios in our own interviews, we tend to interview our best customers or heaviest users. This may be helpful from a relationship perspective, but those users needs are mostly being met. Instead we should try to interview the users that abandon our product for another product. +We oftentimes see similar scenarios in our own interviews, our tendency is to interview our best customers or heaviest users. This is helpful from a relationship perspective, but those users needs are mostly being met. Instead, we should try to interview the users that abandon our product for another product. #### Availability Biases As we go through our day we are bombarded with the current events of our work; support's needs, issues you have been working on, parts of the codebase you wrote etc... Anything that is top of mind can influence how you see or think about a situation. -This is why if your company just released a shiny new feature you are more likely to suggest it as a possible solution over something that maybe more appropriate that came out 5 years ago simply because it is top of mind. +This is why if your company just released a shiny new feature you are more likely to suggest it as a possible solution over something that may be more appropriate that came out 5 years ago simply because it is top of mind. #### Social Desirability biases -Anyone being interviewed will be bias toward answering questions in a way that is socially acceptable. When was the last time someone asked you if you test all your code, how did you answer? If you are like most people you don't test all your code, but you said yes, or shaped some story to make it sound like you do most of the time, because you want them to think of you in desirable way. +Anyone being interviewed will be biased toward answering questions in a way that is socially acceptable. When was the last time someone asked you if you test all your code, how did you answer? If you are like most people you don't test all your code, but you said yes, or shaped some story to make it sound like you do most of the time, because you want them to think of you in a desirable way. This is social desirability bias it is a bit like peer pressure, we have a reason to lie or color the truth because we are trying to align our practices with what we perceive as the socially desired values. @@ -113,7 +113,7 @@ Interviewing people is hard, we have to navigate both our biases and the intervi You can learn to follow a mostly formulaic interview process and get good at it. I am often reminded of a statement a friend of mine told me about interviewing, you have 2 ears and 1 mouth try to use them in that proportion. It really is all about listening. -Most people love to tell stories, if you can get a person into a story telling mode they will usually become fairly honest and straightforward as opposed to people answering questions survey style. +Most people love to tell stories and if you can get a person into a storytelling mode they will usually become fairly honest and straightforward as opposed answering questions in a survey style. So how do we conduct such an interview? @@ -128,7 +128,7 @@ To prepare our interviewing space I go through this checklist: - [ ] At least one note taker. - [ ] Question we are going to ask. -- [ ] Post it notes and pens. +- [ ] Post-it notes and pens. - [ ] If desired a recording device, make sure this is ok with the interviewee. ## Conducting the interview @@ -143,11 +143,11 @@ The first step in the process is an introduction. In this portion of the intervi Once we have done the introduction, I like to ask the interviewee something personal, to ease any tension. Ask them about their day, comment on a unique article of clothing or any personal question that is friendly and easy to discuss. I try to avoid cliche question or topics like the weather as they have grown to lack any depth and don't let the person talk about themselves. If you let the person talk about themselves they will be much more at ease. -On to the questions, at this point we ask the pre-planned questions. I usually have 3-4, ideally these questions should be open ended. When getting answers don't feel like you need to stay on script and make sure to let silence hang a little longer then normal. Often the best interview veers in an unexpected direction naturally as you explore reasons and ideas that are unique to the interviewee and potentially introduce topics or ideas you had not considered. +On to the questions! At this point, we ask the pre-planned questions. I usually have 3-4 ready and ideally, these questions should be open-ended. When getting answers don't feel like you need to stay on script and make sure to let the silence hang a little longer than normal. Often the best interview veers in an unexpected direction naturally as you explore reasons and ideas that are unique to the interviewee and potentially introduce topics or ideas you had not considered. Once the conversation starts to dwindle I often will ask the users a straightforward question that prompts them to solve their own problem. Questions like how would you fix the situation or how have you dealt with this in another role often prompt the user to offer a solution. This may have value or not, but often is insightful in a different way. -The time has come to conclude our interview, at this point you can thank the participant and exchange pleasantries. Before the interviewee leaves I always like to ask for permission to collaborate in the future. This helps build a pool of domain experts to tap when it come time to test prototypes, validate ideas or collect more information. +The time has come to conclude our interview, at this point you can thank the participant and exchange pleasantries. Before the interviewee leaves, I always like to ask for permission to collaborate in the future. This helps build a pool of domain experts to tap when the time comes to test prototypes, validate ideas or collect extra information. ## The warranty domain expert interview @@ -160,16 +160,16 @@ It is time to interview our warranty domain expert, Nevin, we walk through our i There is a lot to unpack in that brief overview. From a note takers perspective we can identify: - A high level process: notification of issue -> assessment -> decision of action to take -> shipping arrangement - - Domain events in this process - - Warranty issue received. - - Warranty issue acknowledged by employee. - - Warranty issue assessed. - - Warranty issue resolution proposed - - Warranty issue resolution in progress - - Warranty issue resolved. - - Replacement product shipment received at warehouse - - Replacement product shipped - - Replacement product delivered + - Domain events in this process + - Warranty issue received. + - Warranty issue acknowledged by the employee. + - Warranty issue assessed. + - Warranty issue resolution proposed + - Warranty issue resolution in progress + - Warranty issue resolved. + - Replacement product shipment received at the warehouse + - Replacement product shipped + - Replacement product delivered - A number of potential bounded contexts: - Bike shop. - Manufacturer. @@ -177,9 +177,9 @@ There is a lot to unpack in that brief overview. From a note takers perspective - Shipping - Domain entities - Bike, - - size: xl - - category: Mountain Bike - - Product name: Vision + - Size: Xl + - Category: Mountain Bike + - Product Name: Vision - Bike Shop: - Name: Harrie's - Shipping address? @@ -187,13 +187,13 @@ There is a lot to unpack in that brief overview. From a note takers perspective These things could feed our ubiquitous language, expand our bounded contexts, add to our domain events and ultimately inform our implementation. -From the interviewer perspective we can now take this interview in a lot of directions. Since we are looking to rebuild the warranty system from the ground up, the first thing we want to focus on is the warranty notification data. +From the interviewer perspective, we can now take this interview in a lot of directions. Since we are looking to rebuild the warranty system from the ground up, the first thing we want to focus on is the warranty notification data. > You: Can you tell me more about how you were notified of the issue and what information you needed to assess this incident? -> Nevin: Sure, Harries emailed us about the issue. We require pictures of the bike, pictures of the broken part, the serial number, and a bit of info about how the break occurred. We have an email template we send them to fill in and ask any follow up questions over email. We also ask for a single point of contact with whom to work through the issue with on the shop end to simplify communications. Based on the type of break we assign a category to the issue. +> Nevin: Sure, Harries emailed us about the issue. We require pictures of the bike, pictures of the broken part, the serial number, and a bit of info about how the break occurred. We have an email template we send them to fill in and ask any follow-up questions over email. We also ask for a single point of contact with whom to work through the issue with on the shop end to simplify communications. Based on the type of break we assign a category to the issue. -> You: This is great would you mind emailing us that template? Can you forward us a few example customer interactions? +> You: This is great would you mind emailing us that template? Can you forward us a few customer interaction examples? Once again we have information that we can use to fill out our domain knowledge even more. It is great to try to collect any assets that may already exist to assist a process, often these organically grown processes built in a low fidelity way our early prototypes of what is really desired. We can also further develop our domain knowledge assets with this small question and answer cycle. @@ -219,77 +219,77 @@ Once again we have information that we can use to fill out our domain knowledge This process could go on to investigate shipping workflows, warehouse interactions, manufacturer needs etc... -> You: Thanks for all this information Nevin this is amazing. Would you mind if I reach out to you in the future for follow up information or to share ideas with you and get your feedback? +> You: Thanks for all this information Nevin this is amazing. Would you mind if I reach out to you in the future for follow-up information or to share ideas with you and get your feedback? > Nevin: That would be great I am really excited to fix this. -> You: I am also wondering if you would let me shadow you for an hour or so while you work on some warranties to see what you workflow looks like? +> You: I am also wondering if you would let me shadow you for an hour or so while you work on some warranties to see what your workflow looks like? ## Note taking -It is tempting to try to model our database or layout our objects in our notes. Ideally notes will quickly capture ideas and not model things for us. Ultimately we are trying to understand our domain, not figure out implementation details. +It is tempting to try to model our database or layout our objects in our notes. Ideally, notes will quickly capture ideas and not model things for us. Ultimately we are trying to understand our domain, not figure out implementation details. -Try to keep your notes short, using post it notes for note taking will encourage this as space is limited. We want to capture just enough information to understand the domain. Notes like: +Try to keep your notes short, using post-it notes for note taking will encourage this as space is limited. We want to capture just enough information to understand the domain. Notes like: - Bike, - size: xl - category: Mountain Bike - - Product name: Vision + - Product Name: Vision - Serial number Are preferred to: -> A bike has a size, category, product name and serial number. Each warranty has a bike and the warranty belongs to a bike shop. +> A bike has a size, category, product name, and serial number. Each warranty has a bike and the warranty belongs to a bike shop. -This is the start of a db model, you will get there eventually but it is far to early in the process to know if what you are doing enforces the domain properly. +This is the start of a DB model, you will get there eventually but it is far too early in the process to know if what you are doing enforces the domain properly. ## Developing your ubiquitous language -At this point we should think of things as developing an encyclopedia of institutional knowledge. In fact I would recommend taking on this task at this point. Every interview you undertake should be approached as an opportunity to collect and share very useful domain knowledge that may currently exist in a silo. +At this point, we should think of things as developing an encyclopedia of institutional knowledge. In fact, I would recommend taking on this task at this point. Every interview you undertake should be approached as an opportunity to collect and share very useful domain knowledge that may currently exist in a silo. -If you can build a wiki or some other communication tool that can state what all the domain language is in different parts of you institution then you have a communication standard you can reference for new hires, naming things in the future and understanding what user means in the context of sales. +If you can build a wiki or some other communication tool that can state what all the domain language is in different parts of your institution then you have a communication standard you can reference for new hires, naming things in the future and understanding what user means in the context of sales. # Job Shadowing -Nevin has invited us back to do some job shadowing. In this process we are looking to gain on the ground experience to see all the parts of the process that are often not discussed in an interview because they are so ingrained in day to day activity they seem obvious to the domain expert. +Nevin has invited us back to do some job shadowing. In this process, we are looking to gain on the ground experience to see all the parts of the process that are often not discussed in an interview because they are so ingrained in the day-to-day activity that they seem obvious to the domain expert. -As an outside party we need to steep ourselves in the world of the domain expert a bit, as what they take for granted maybe completely foreign to us. We may also see extremely inefficient practices that computers could automate, that the domain expert may never recognize as a problem. +As an outside party, we need to steep ourselves in the world of the domain expert a bit, as what they take for granted may be completely foreign to us. We may also see extremely inefficient practices that computers could automate, that the domain expert may never recognize as a problem. ## Setup -In a job shadowing exercise we are entering into the workspace of the domain expert. We need to try to set ourselves up to be as un-obtrusive as possible. Often times this means preparing ourselves as humans to be stealth. Have you pens and paper ready, get your coffee in hand or snack and prepare to sit back and be as quite as a mouse, what ever that means for you. +In a job shadowing exercise, we are entering into the workspace of the domain expert. We need to try to set ourselves up to be as unobtrusive as possible. Often times this means preparing ourselves as humans to be stealth. Have your pens and paper ready, get your coffee in hand or snack and prepare to sit back and be as quiet as a mouse, whatever that means for you. -You likely also want to arrange a time when the domain expert is actively undertaking the work you want to observe. Find a time that works well for this observation, ideally they should be moderately busy, meaning not to overwhelmed to answer your questions but busy enough to show some variety. +You likely also want to arrange a time when the domain expert is actively undertaking the work you want to observe. Find a time that works well for this observation, ideally, they should be moderately busy, meaning not to overwhelmed to answer your questions but busy enough to show some variety. When you come into their workspace expect there to be a bit of friendly interaction at the beginning and perhaps a bit of awkwardness as they start their day. Starting work is hard enough, doing it while being watched can definitely impact performance. You can try to ease tension by bringing donuts, telling jokes and then slowly receding back. ## Observation -While observing try to ask as few questions of the observant as possible. I like to take notes of any questions I had and save them for the end. It is normal to have a follow up short interview after the shadowing session. It may also be helpful to have the domain expert explain out loud what they are doing as they undertake their work almost like a stream of consciousness. I tend to reserve this to particularly complex tasks as it can influence their workflow. +While observing try to ask a minimal amount of questions to the observant. I like to take notes of any questions I had and save them for the end. It is normal to have a follow up short interview after the shadowing session. It may also be helpful to have the domain expert explain out loud what they are doing as they undertake their work almost like a stream of consciousness. I tend to reserve this to the particularly complex tasks as it can influence their workflow. -There are a few key areas I tend to hone in on when observing a domain expert doing their work. The main 3 are tools, processes and interactions. I find these high level categories I can hone in on and organize my thinking and notes around. +There are a few key areas I tend to hone in on when observing a domain expert doing their work. The main 3 are tools, processes, and interactions. I find these are high-level categories I can hone in on and organize my thinking and notes around. ### Tools -Any tooling the domain expert interacts with is helpful to note. Often we are integrating with, replacing or augmenting tools. Having an understanding of what tools are in place, what they are used for, why they where chosen, where they fit in the process and what features are used is often handy to note for later use. +Any tooling the domain expert interacts with is helpful to note. Often we are integrating with, replacing or augmenting tools. Having an understanding of what tools are in place, what they are used for, why they were chosen, where they fit in the process and what features are used is often handy to note for later use. -It can also help us to understand were our tooling fits in the broader picture, are these outside system interacting with ours, could they? Should they? Are their patterns or language familiar to the domain expert from these tools that we can co-opt to simplify the environment of the domain expert? Tools in the environment are important to any domain expert, thus they should be important to us as augmenters of the environment. +It can also help us to understand where our tooling fits in the broader picture, are these outside system interacting with ours, could they? Should they? Are their patterns or languages familiar to the domain expert from these tools that we can co-opt to simplify the environment of the domain expert? Tools in the environment are important to any domain expert, thus they should be important to us as augmenters of the environment. ### Processes -How are entities moving through the environments, what tools are taking inputs, creating outputs. What do these inputs and outputs look like? Is most of the process happening on a computer? Is there physical workspace to consider? +How are entities moving through the environments, what tools are taking inputs, creating outputs? What do these inputs and outputs look like? Are most of the processes happening on a computer? Is there physical workspace to consider? -Most of the workflow we are examining is process, whether or not it is recognized as such or any good. Looking for patterns in the workflow and things that could potentially become patterns is a good thing to note. +Most of the workflow we are examining is contained in the process, whether or not it is recognized as such or any good. Looking for patterns in the workflow and things that could potentially become patterns is a good thing to note. This is a great time to outline domain entities, domain events and states that entities could exist in. You may want to actually draw timelines, comics, physical maps or process diagrams to show how things move through the process. ### Interactions -Interactions between different domain experts, processes or tools are all helpful to capture. Is there a point in time where a certain entity transfer to another group in you organization? Does the domain expert need to reach out to other places for information? Does information transfer from one system to another? How are the domain experts entering data into different places? +Interactions between different domain experts, processes or tools are all helpful to capture. Is there a point in time where a certain entity transfer to another group in your organization? Does the domain expert need to reach out to other places for information? Does information transfer from one system to another? How are the domain experts entering data into different places? All these interactions likely point to some piece of tooling you will need to be aware of or consider implementing. Try to map out how entities are moving around in the context bounds and what action is required to move them in an out of these interactions. ### Looking for hacks -This is not one of my top 3 areas for focus, but hacks are really valuable for finding confusing or troublesome parts of a system. If a domain expert has take the time to implement a hack to get around a situation it is likely that they understand something the implementors did not and got frustrated to a point that they fixed it themselves. +This is not one of my top 3 areas for focus, but hacks are really valuable for finding confusing or troublesome parts of a system. If a domain expert has taken the time to implement a hack to get around a situation it is likely that they understand something the implementors did not and got frustrated to a point that they fixed it themselves. -Hacks can take many forms, post it notes with directions, macros in excel, browser plugins, copy and past patterns and more. Any thing where the user created a one off custom solution to a problem is worth exploring. +Hacks can take many forms, post-it notes with directions, macros in excel, browser plugins, copy and past patterns and more. Anything, where the user created a one-off custom solution to a problem, is worth exploring. \ No newline at end of file From 48eb451dc095e1a476160b523263237deb7c2ef3 Mon Sep 17 00:00:00 2001 From: acrlewis Date: Wed, 13 Feb 2019 13:43:05 -0700 Subject: [PATCH 23/30] ch2 is so awesomegit push origin cg-book-proposal --- book/proposal/sample chapter2.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/book/proposal/sample chapter2.md b/book/proposal/sample chapter2.md index 540136a..b8f851b 100644 --- a/book/proposal/sample chapter2.md +++ b/book/proposal/sample chapter2.md @@ -1,10 +1,12 @@ # Interviewing and Job Shadowing -What better way to learn about a topic then spend time with an expert. In our stakeholder mapping exercise we began to identify different types of users we should communicate with to better understand their working context and challenges. Now we will explore some methods for engaging these domain experts to increase our awareness of their language, workflows, entities, and problems. +What better way to learn about a topic then spend time with an expert? -In this chapter, we will introduce interviewing and job shadowing. We will use these methods to dig deep into the warranty workflow that exists today in order to understand the domain we are working within. We will be looking to gain as many key insights as we can to aid our implementation choices in the future. +In our stakeholder mapping exercise, we began to identify different types of users we should communicate with to gain a better understanding of their working context and challenges. We will now explore some methods for engaging these users, or domain experts, to increase our awareness of their language, workflows, entities, and problems. -We will explore how to conduct better interviews, get stakeholder buy-in, common pitfalls that could bias your implementation and how to collect common language, domain events, identify entities and processes. +In this chapter, we will introduce interviewing and job shadowingas methods of digging deeper into the warranty workflow that exists today to better understand the domain we are working within. We will be looking to gain as many key insights as we can to aid our implementation choices in the future. + +We will explore how to conduct better interviews, get stakeholder buy-in, avoid common pitfalls that could bias your implementation and how to collect common language, domain events, and identify entities and processes. # Identifying an interviewing topic From 3e39d4dd3804894f58ac238a090a7920bb303af3 Mon Sep 17 00:00:00 2001 From: acrlewis Date: Wed, 13 Feb 2019 13:52:31 -0700 Subject: [PATCH 24/30] ch2 interview topic --- book/proposal/sample chapter2.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/book/proposal/sample chapter2.md b/book/proposal/sample chapter2.md index b8f851b..9fa86a0 100644 --- a/book/proposal/sample chapter2.md +++ b/book/proposal/sample chapter2.md @@ -10,9 +10,11 @@ We will explore how to conduct better interviews, get stakeholder buy-in, avoid # Identifying an interviewing topic -Our warranty process has been flagged for replacement because it is built in a legacy system that we believe is leading to tracking issues and slowing down communications. We have been implementing a new customer support portal in sales and management wants to tie the two systems together for a variety of reasons. The top-down pressure is revolving around tracking costs in warranty, but the warranty is expressing concerns about customer interactions and fearing a changing process. +What we know: Our warranty process has been flagged for replacement. It was originally built in a legacy system, which seems to be causing tracking issues and slowing down communications. We have been implementing a new customer support portal in sales and management wants to integrate the two systems together for various reasons. The top-down pressure revolves around tracking costs in warranty, but the warranty is expressing concerns about customer interactions and fears a changing process. -Our interview could go in a number of directions based on what we know. It would be easy to focus on what management wants out of the transition as hierarchies lead to this kind of approach. In our case, we choose to seek the topic which is the most domain centric. What does that mean? Glad you asked, we want to get at the most common workflows, entities, processes in the central workflows. In our case, what is the common lifecycle of a warranty? This will ensure our solution first focuses on the primary work that needs to be completed, primary domain. We want to avoid getting into the weeds of how cost is being tracked at this point, although it is a motivating force in the org, once we have a solid core domain modeled we can move to cost tracking as a separate subdomain and explore that problem independently. It may be a driver for why we are making the switch, but the important thing to tackle first is the core domain. +Our interview could go in a number of directions based on what we know. It might be easy to focus on what management wants out of the transition as hierarchies do lead to this kind of approach. However, in our case, we choose to seek a topic which is the most domain centric. + +At this point, you are probably thinking "What does that mean?" Glad you asked. We want to get at the most common workflows, entities, processes in the central workflows. In our case, what is the common lifecycle of a warranty? This ensures our solution first focuses on the primary work that needs to be completed, which is the primary domain. We will avoid getting into the weeds of how cost is being tracked, although it might be a motivating force in the organization. Once we have a solid core domain modeled, we can move to cost tracking as a separate subdomain and explore that problem independently. It may be a driver for why we are making the switch, but the important thing to tackle first is the core domain. # Determining who to interview From 66230b722399fe34bb355c4980928b8c6292c478 Mon Sep 17 00:00:00 2001 From: acrlewis Date: Wed, 13 Feb 2019 14:00:05 -0700 Subject: [PATCH 25/30] ch2 who to interview --- book/proposal/sample chapter2.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/book/proposal/sample chapter2.md b/book/proposal/sample chapter2.md index 9fa86a0..fa78116 100644 --- a/book/proposal/sample chapter2.md +++ b/book/proposal/sample chapter2.md @@ -18,21 +18,21 @@ At this point, you are probably thinking "What does that mean?" Glad you asked. # Determining who to interview -Different domain experts will work with our system in different ways and have different needs of the system. If we refer to our bounded contexts we can gain some insight into different entities that may need to access this system, we can also do a separate stakeholder mapping exercise just for this project, it may show new bounded contexts to account for. +Different domain experts will work with our system in different ways and each will have different needs of the system. If we refer to our bounded contexts, we can gain some insight into different entities that may need to access this system. We can also do a separate stakeholder mapping exercise just for this project and it might uncover new bounded contexts we should take into account. -We want to ensure we interview a few people from each context to get some different perspectives, when possible these people should have very different backgrounds. For our warranty system we have identified the following domain experts to discuss this system with: +We will want to ensure we interview a few people from each context to get different perspectives and wherever possible these people should also have very different backgrounds. For our warranty system we have identified the following domain experts to discuss this system: -- The warranty dept. -- Inventory and purchasing. -- Internal sales reps. -- Outside sale reps. +- The Warranty Department. +- Inventory and Purchasing. +- Internal Sales reps. +- Outside Sales reps. - Small bike shop mechanic. - Large outdoor sporting goods store shop manager. -- Product management. +- Product Management. -This represents the core group of domain experts that touch the warranty system on a daily basis today. Each of them may have very different roles in the company and need very different things out of the system. This should give us a broad view of the domain space and how the different contexts view things. +This represents our core group of domain experts that touch the warranty system on a daily basis today. Each of them may have varying functions in the company and very different things needs from the system. This will give us a broader view of the domain space and how the various contexts view different things. -We have a pretty long list here, generally speaking, it may be hard to talk to so many stakeholders. However, talking to 2-3 is always better than talking to none. +This is a pretty long list here, generally speaking, and it may be difficult to talk to so many stakeholders. However, working with 2-3 is always better than talking to none. # Getting permission from stakeholders From 37a23fe268a58b731f05541408b9383cf81664ec Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Tue, 19 Feb 2019 11:38:57 -0500 Subject: [PATCH 26/30] cccchanges --- book/proposal/sample chapter2.md | 170 +++++++++++++++++++++++++++---- 1 file changed, 150 insertions(+), 20 deletions(-) diff --git a/book/proposal/sample chapter2.md b/book/proposal/sample chapter2.md index 94a6494..c165056 100644 --- a/book/proposal/sample chapter2.md +++ b/book/proposal/sample chapter2.md @@ -1,6 +1,6 @@ # Interviewing and Job Shadowing -What better way to learn about a topic then spend time with an expert. In our stakeholder mapping exercise we began to identify different types of users we should communicate with to better understand their working context and challenges. Now we will explore some methods for engaging these domain experts to increase our awareness of their language, workflows, entities and problems. +What better way to learn about a topic then spend time with an expert. In our stakeholder mapping exercise we began to identify different types of users we should communicate with to better understand their working context and challenges. Now we will explore some methods for engaging these domain experts to increase our awareness of their language, workflows, entities and problems. Our goals are to reduce friction in future communications with stakeholders and code changes. We achieve this by better understand the language, processes and tools of the working environment, ultimately resulting in code that fluidly evolves with its environment by utilizing the common language of the environment, enhancing the ability of the tools already in place and seeking to co-exist in harmony with the processes important to the problem space. In this chapter we will introduce interviewing and job shadowing. We will use these methods to dig deep into the warranty workflow that exists today in order to understand the domain we are working within. We will be looking to gain as many key insights as we can to aid our implementation choices in the future. @@ -10,13 +10,23 @@ We will explore how to conduct better interviews, get stakeholder buy in, common Our warranty process has been flagged for replacement because it is built in a legacy system that we believe is leading to tracking issues and slowing down communications. We have been implementing a new customer support portal in sales and management wants to tie the two systems together for a variety of reasons. The top down pressure is revolving around tracking costs in warranty, but warranty is expressing concerns about customer interactions and fearing a changing process. -Our interview could go in a number of directions based on what we know. It would be easy to focus on what management wants out of the transition as hierarchies lead to this kind of approach. In our case we choose to seek the topic which is the most domain centric. What does that mean? Glad you asked, we want to get at the most common workflows, entities, processes in the central workflows. In our case what is the common lifecycle of a warranty. This will ensure our solution first focuses on the primary work that needs to be completed, primary domain. We want to avoid getting into the weeds of how are cost being tracked at this point, although it is a motivating force in the org, once we have a solid core domain modeled we can move to cost tracking as a separate subdomain and explore that problem independently. It maybe a driver for why we are making the switch, but the important thing to tackle first is the core domain. +Our interview could go in a number of directions based on what we know. For example we could focus on: + - Tracking issue that management is prioritizing. + - The speed of communications for warranties. + - The sales/warranty overlap. + - The common warranty lifecycle. + +Often times hierarchies lead to this kind of approach. We are focusing solely on x problem. This sort of approach assumes that we are certain of the issue itself. It also assumes we are comfortable enough with the domain to not spend time exploring the warranty domain at all and instead focus on a single problem in the domain. In our scenario the original warranty system was implemented over 10 years ago, none of the knowledge accumulated during that implementation is relevant or available any more as the implementation tooling is changing and the work itself is ready to be re-examined because the new development team is in no way familiar with the tools, processes and language of the warranty dept or processes between departments. + +As is often the case we need to choose to seek the topic which is the most domain centric. We want to get at the most common workflows, entities, processes in the central workflows. The team needs to understand what is the common lifecycle of a warranty. This will ensure our solution first focuses on the primary work that needs to be completed, primary domain. We want to avoid getting into the weeds of how are cost being tracked at this point, although it is a motivating force in the org, once we have a solid core domain modeled we can move to cost tracking as a separate subdomain and explore that problem independently. It maybe a driver for why we are making the switch, but the important thing to tackle first is the core domain. + +Once we have a well defined knowledge of the environment, functioning ubiquitous language among different stakeholders and suitable basic implementation of the warranty system we can narrow down our areas of interviewing to more specific features, such as the tracking needs. Prior to defining these context boundaries and ubiquitous language you increase the risk of speaking different languages and increasing code friction by encoding these mis-understandings into you implementation. # Determining who to interview Different domain experts will work with our system in different ways and have differing needs of the system. If we refer to our bounded contexts we can gain some insight into different entities that may need to access this system, we can also do a separate stakeholder mapping exercise just for this project, it may show new bounded contexts to account for. -We want to ensure we interview a few people from each context to get some different perspectives, when possible these people should have very different backgrounds. For our warranty system we have identified the following domain experts to discuss this system with: +We should interview a few people from each context to get some different perspectives, when possible these people should have very different backgrounds. For our warranty system we have identified the following domain experts to discuss this system with: - The warranty dept. - Inventory and purchasing. @@ -26,25 +36,28 @@ We want to ensure we interview a few people from each context to get some differ - Large outdoor sporting goods store shop manager. - Product management. + This represents the core group of domain experts that touch the warranty system on a daily basis today. Each of them have very different roles in the company and need very different things out of the system. This should give us a broad view of the domain space and how the different context view things. -We have a pretty long list here, generally speaking it maybe hard to talk to this many stakeholders. Trying to talk to 2-3 is better then talking to none, +We have a pretty long list here, generally speaking it maybe hard to talk to this many stakeholders. Trying to talk to 2-3 is better then talking to none. + +Every interview cycle will have different interviewee needs. In our example we are seeking a broad audience as we are starting fresh. Once you have captured these perspectives for this broad sweeping project, future more focused projects can be limited to just the parts of the organization who's processes we are affecting. When limiting to less groups it is still a good idea to get some diversity in skillsets and application usage. I like to record interviews when possible so that I can reference them in the future should I need to. -# Getting permission from stakeholders +# Getting buy in from stakeholders -We need to reach out to each of our domain experts and get their permission to do the interviews. The way we speak to each group maybe different in tone based on who they are, our relationship with them, and their relationship to the project. +We need to reach out to each of our domain experts and get their permission to do the interviews. The way we speak to each group will be different in tone based on who they are, our relationship with them, and their relationship to the project. -Warranty should hopefully be aware of the project, getting permission from the core domain experts who you are directly affecting their workflow should be easy. Some times you need to deal with push back about changing processes, but this is an opportunity to ease tensions and express you ambitions to improve their day to day work. Try building enthusiasm in the project by showing a willingness to work together and project often go from dreaded to exciting as the domain experts see the ability to change their day to day workflows in a positive way. +Warranty should be aware of the project, getting permission from the core domain experts who's workflow you are affecting should be easy. When you need to deal with push back about changing processes use this as an opportunity to ease tensions and express your ambitions to improve their day to day work. You can build enthusiasm in a project by showing a willingness to work together. Doing so projects often go from dreaded to exciting as the domain experts start to feel empowered to change their day to day workflows in a positive way. -Outside collaborators such as bike shops are often trickier, in this case I will often leverage the relationship a sales rep has with a shop or find a shop warranty particularly enjoys. Often times your domain experts can grease the wheels and even get outside collaborators excited about contributing back toward improving systems they dislike. +Outside collaborators such as bike shops are often tricky, in this case try leveraging an internal relationship, in our case a sales rep has a relationship with a shop, or find a shop warranty particularly enjoys working with. Your domain experts can grease the wheels and even get outside collaborators excited about contributing back toward improving systems they dislike. -Internal collaborators like sales may often state they don't have time to do an interview. These interviews can sometimes be the trickiest in some ways, however I have had success with drop in conversation or offering to take some one out to lunch. +Internal collaborators like sales may often state they don't have time to do an interview. In this scenario I have had success with drop in conversation or offering to take some one out to lunch, beers may also help. # Writing questions -Now it is time to write interview questions. Interviewing people is a bit like hanging out at the bar with a friend asking them about their last great adventure. We want to go into it curious and with a beginners mindset. It is tempting to approach interview questions in a similar way to writing survey questions, by this I mean questions with yes/no multiple choice answers, try to avoid this. +Now it is time to write interview questions. Interviewing people is a bit like hanging out at the bar with a friend asking them about their last great adventure. We want to go into it curious and with a beginners mindset. It is tempting to approach interview questions in a similar way to writing survey questions, by this I mean questions with yes/no, multiple choice answers, try to avoid this. -We will be using some question starters to help us create good interviewing starters, thinking about interview questions as conversation starters is a good approach. Our starters are: +We will be using some question starters to help create good interviewing starters. I think about interview questions as conversation starters. Our question starters are: - Tell me about the last time you did x. - Have you done x differently in the past? Maybe at a different company. @@ -58,21 +71,27 @@ Filling in our topic `common warranty lifecycle` we end up with the following qu - What do you tell new warranty employees on their first day about the process? - What is the process for a typical warranty? -These question will spark conversation and have plenty of room to breath. The goal is to remove yourself from the conversation as much as possible and let the domain expert explain their process. It is common to interject bias into questions and we want to avoid that as much as possible. +With these questions we are seeking real world stories. Ideally the interviewee will walk you through an experience they recall from recent work. In our warranty example, we want the warranty dept to tell us about a warranty claim starting at the place where they learn about a new claim, how they interact with the person who submitted the claim, how they decide what action to take and how they take said action. There is a lot to dig into with a story that tells the lifecycle of a whole process such as this. -It is important to mostly let the interviewee talk, we want to be an active listener. From time to time something will come up in the interview that you think it would be nice to expand upon. Having some potential lines in your questions to help you frame a question in a way the qualifies the statement or expands upon it is helpful. +These question will spark a story and have plenty of room to breath. The goal is to remove yourself from the conversation as much as possible and let the domain expert explain their process start to finish. It is common to interject bias into questions and we want to avoid that as much as possible. + +Your number one priority is to listen, not to talk. From time to time something will come up in the interview that you think it would be nice to expand upon. Having some potential questions to help you expand a statement in a way that qualifies the statement or expands upon will improve the quality of your interviews. - If you had x how frequently would you have used it in the past 6 months? - Just be be sure I am clear if you had x, what would it allow you to do that you cannot do now? - Tell me more about why you prefer the competitors feature over ours. - If you had to choose between x and y which would you choose? +Each of these questions is designed to dig into the specifics of a task. The 5 why's is another good practice, if you ask why 5 times you will generally get to the end of someone's knowledge on a topic. We want to get as deep into their processes so we can understand what they are doing, why and how they talk about it. During this we are extracting as much language, process, domain entities, events, collaborators and tools as possible. + At some point in the interview the conversation will wind down. I like to offer the domain expert the ability to solution at this point. Often they have stewed over a potential solution or better workflow but don't posses the skills required to implement it. Have some questions ready for this time: - How would you solve x? - If you could change one thing today what would it be? - If you had a magic wand what would you change? +Often times this will not lead to a implementable solution, however it may spark an idea down the road of how you could approach the problem. It could also hand you the solution you need, don't dismiss any ideas at this point. + I will add all these questions to a question outline so they are ready for interview day. ## Identifying bias @@ -166,10 +185,12 @@ There is a lot to unpack in that brief overview. From a note takers perspective - Warranty issue assessed. - Warranty issue resolution proposed - Warranty issue resolution in progress - - Warranty issue resolved. + - Warranty resolution offered + - Warranty resolution accepted - Replacement product shipment received at warehouse - Replacement product shipped - Replacement product delivered + - Warranty issue resolved. - A number of potential bounded contexts: - Bike shop. - Manufacturer. @@ -187,6 +208,16 @@ There is a lot to unpack in that brief overview. From a note takers perspective These things could feed our ubiquitous language, expand our bounded contexts, add to our domain events and ultimately inform our implementation. +### Sidbar: Fidelity in note taking +Depending on how well liked or defined your process is you may want to more fully capture the process. I tend to capture language in a higher fidelity if processes are well defined, liked or efficient. Lower fidelity is better when things are not as well defined, are inefficient or lack in some areas. As Henry Ford once said, if I asked the customer what they wanted they would say a faster horse. Allowing your team room to innovate is a matter often a matter of fidelity, at the point of capture you start to make value decisions of how much you want to replace, be aware of this during your note taking you are already making value judgments. + +In our example we know our system is gravely inefficient, so we want to capture notes that allow for room to improve. If we conducted the same interview in a well loved efficient process, or rigid environment driven by compliance our output should be higher fidelity for the process section. + +> Warranties are received via email then assigned to a warranty manager. The assigned manager then notifies the shop that they are starting work. Next follow up questions are sent to the shop. Once follow up questions are answered, the warranty manager asses the issue and offer a resolution. Given the resolution is accepted any needed parts are then shipped to the shop. Upon receiving the parts the warranty is marked as resolved. + +This higher fidelity process outline captures more information about the process. If you are following BDD this could be dropped in as a spec. User stories such as this have their place, we can see the ubiquitous language, identify context boundaries and capture this directly in our code base. However, this level of fidelity offers a solution, which at times can prevent brainstorming pathways we will explore in future chapters. Feel free to use both approaches depending on your requirements. +### End side bar + From the interviewer perspective we can now take this interview in a lot of directions. Since we are looking to rebuild the warranty system from the ground up, the first thing we want to focus on is the warranty notification data. You: Can you tell me more about how you were notified of the issue and what information you needed to assess this incident? @@ -244,11 +275,6 @@ Are preferred to: This is the start of a db model, you will get there eventually but it is far to early in the process to know if what you are doing enforces the domain properly. -## Developing your ubiquitous language -At this point we should think of things as developing an encyclopedia of institutional knowledge. In fact I would recommend taking on this task at this point. Every interview you undertake should be approached as an opportunity to collect and share very useful domain knowledge that may currently exist in a silo. - -If you can build a wiki or some other communication tool that can state what all the domain language is in different parts of you institution then you have a communication standard you can reference for new hires, naming things in the future and understanding what user means in the context of sales. - # Job Shadowing Nevin has invited us back to do some job shadowing. In this process we are looking to gain on the ground experience to see all the parts of the process that are often not discussed in an interview because they are so ingrained in day to day activity they seem obvious to the domain expert. @@ -292,4 +318,108 @@ All these interactions likely point to some piece of tooling you will need to be This is not one of my top 3 areas for focus, but hacks are really valuable for finding confusing or troublesome parts of a system. If a domain expert has take the time to implement a hack to get around a situation it is likely that they understand something the implementors did not and got frustrated to a point that they fixed it themselves. -Hacks can take many forms, post it notes with directions, macros in excel, browser plugins, copy and past patterns and more. Any thing where the user created a one off custom solution to a problem is worth exploring. \ No newline at end of file +Hacks can take many forms, post it notes with directions, macros in excel, browser plugins, copy and past patterns and more. Any thing where the user created a one off custom solution to a problem is worth exploring. + +## Observing our warranty process + +You: Good morning Nevin, I brought coffee and bagels. How is your day going? + +Nevin: Great now that I have bagels. + +You: Everyone loves a bagel, I am going to hang out back here and just observe your warranty routines. Mind if I look around at your space while you get your day started? + +Nevin: No problem, if you have any questions just let me know. + +You: Thanks + +You walk around and note a few computers, a barcode scanner with internet browsing capabilities, label printers and some notes with email addresses for different warehouses holding our products. + +Nevin: Hey Jim, I got a new warranty issue want to grab it? + +Jim: On it. + +You go over and watch Jim follow up on the warranty issue. He double checks that all the needed information is there in the issue, which it is. You take notes of all the items he is looking for in the email, it looks like there is an email template that they use to have shops submit warranties with, you take a note to get this template from them later. + +Jim: This looks pretty straight forward, we have seen a lot of these bikes break at this junction. Nevin do we still have any x-large, huff and puff frames left in the west coast wharehouse? + +Nevin: No it will have to come from the east coast. Should take about a week to get to them. + +Jim: Ok I will let the shop know and ship it out once they have given the go ahead. + +You capture notes about the location of the bike inventory driving delivery needs and dates. Also the process of notifying the shop. You also request that all the emails exchanged be forwarded to you for reference. + +From this exercise we have gained knowledge around a number of areas that didn't expose themselves during the interview. The warehouse inventory came up as did the tools that they use day to day. You could follow up and ask to see how any of these tools are used to try to drive insights into where you could further inject software into their process. + +## Developing your ubiquitous language +At this point we should think of things as developing an encyclopedia of institutional knowledge. In fact I would recommend taking on this task at this point. Every interview you undertake should be approached as an opportunity to collect and share very useful domain knowledge that may currently exist in a silo. + +Every group is different in how they like to communicate. Self describing software, document everything, automatically generated docs there are a lot of preferences in how we communicate amongst our teams. The method of communication is less important then the ability to capture the knowledge you have gained, so I am not going to weigh in on this religious war. If you can build a wiki or some other communication tool that can state what all the domain language is in different parts of your bounded context then you have a communication standard you can reference for new hires, naming things in the future and understanding what user means in the context of sales. + +Taking our notes from our interview section we can extract our domain entities, domain events, process and new bounded contexts. We are not at a point were we are writing code yet but we can start to organize our domain further on a domain context map, grouping our entities, events and processes in their proper contexts. + +![](https://www.oreilly.com/library/view/domain-driven-design-distilled/9780134434964/graphics/04fig01.jpg) + +Lets augment our previous context map from our stakeholder mapping exercise. Since we have spoken with warranty we identified some outside stakeholder we had not considered prior. The warehouse which houses our replacement parts is a group we will need to work with, the implementation for this group is an unknown at this time, could be an api could be an email workflow, which is what exists today. This is not part of our core domain and thus belongs in its own context. Similarly is the shipping agent, this will live outside our core domain as well. It is likely some other part of the organization, sales, also needs an shipping integration so it will serve us well to look at this as it's own sub-domain. + +We can also fill in some information about the bike entities in our core domain and warranty processes inside our warranty sub-domain, warranty could potentially be the core domain from the teams perspective but is not from the business' perspective. Inside the core domain we can add the new bike and bike shop information we have collected: + +- Core Domain entities + - Bike, + - size: xl + - category: Mountain Bike + - Product name: Vision + - Serial number + - Bike Shop: + - Name: Harrie's + - Shipping address? + - Email address + - Employees + +We can begin to fill in some process information in the warranty subdomain: + +- A high level process: notification of issue -> assessment -> decision of action to take -> shipping arrangement + - Domain events in this process + - Warranty issue received. + - Warranty issue acknowledged by employee. + - Warranty issue assessed. + - Warranty issue resolution proposed + - Warranty issue resolution in progress + - Warranty resolution offered + - Warranty resolution accepted + - Replacement product shipment received at warehouse + - Replacement product shipped + - Replacement product delivered + - Warranty issue resolved. + + We also have a warranty subdomain entities: + + - Warranty Notifications + - Warranty Issue + - Image of the bike + - serial number + - Image of the break + - How the break occurred + - Point of contact for warranty submitter + - Break type category + - Warranty Assigned Manager + - Warranty Assigned shop + - Warranty Discussion + +Along with this we have identified two more potential subdomains, shipping and warehousing/inventory. These could be built out in a similar fashion to what we have done with warranty. + +This represents the core language, process and ideas in the warranty department as it exists today. I will also often add a list of tools available at this point so I have it for future brainstorming sessions. This may not be a part of what Domain Driven Design offers, but I prefer to look holistically at an environment as the problem space in order to better serve the problem. + +- Handheld UPC Scanners, running android +- Cellphones +- Laptops with internet connection +- External Warehouse + +There are clearly interconnections between our sub-domains we will explore mapping those out further in a future section. + +# Conclusion + +We have now collected a strong representation of the domain from the warranty managers perspective. Collecting ideas about how they communicate, work and their environment. This information allows us to think about the warranty environment in a much more informed way then we did prior to the exercise and gives us communication tools that can ease communication friction with stakeholders and also in the code itself. + +We also have a much better long term view of how the code itself may grow and change since we understand the working condition of the warranty lifecycle. This will help us make informed decisions as we build our solution that will keep us from setting up traps based on lack of foresight. + +Finally we improved our relationships with key internal stakeholders. This social capital can help us champion our project and improves collaboration which can only improve our project. We have developed a toolset which helps us collaborate in an effective way instead of just complaining about things that are broken. From 600a896ea3f0a57f19b4e1b3eec9c22764decc1f Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Tue, 19 Feb 2019 12:09:51 -0500 Subject: [PATCH 27/30] update outline and proposal --- book/proposal/outline.md | 86 +++++++++++++++++++++++++++++++++------ book/proposal/proposal.md | 2 +- 2 files changed, 74 insertions(+), 14 deletions(-) diff --git a/book/proposal/outline.md b/book/proposal/outline.md index 7d001ee..590ef95 100644 --- a/book/proposal/outline.md +++ b/book/proposal/outline.md @@ -1,8 +1,6 @@ # Outline for Design Thinking for Developers -## Chapter 1: Organic Software with Design Thinking and Domain Driven Development - -Organic software is the modern ideal and quality needed if we seek to perpetuate the success and social responsibility of open source to a wider set of problems. We seek to serve the whole of life, seeking solutions which effortlessly enhance our environments in an informed, thoughtful and responsible manner. +## Chapter 1: Introduction Organic software: @@ -12,17 +10,25 @@ Organic software: - Focuses on communicating consistently across the implementation and domain. - Seek empowering solutions over narrowly targeted solutions. +Organic software is the modern ideal and quality needed if we seek to perpetuate the success and social responsibility of open source to a wider set of problems. We seek to serve the whole of life, seeking solutions which effortlessly enhance our environments in an informed, thoughtful and responsible manner. + Crafting organic software is challenging! Solving problems in an appropriate way without first exposing yourself to the situation is impossible! But this is consistently how we approach software development. A product manager tries to understand a feature someone thinks they need, the product manager then condenses this down into an issue that can fit into our software project management process of choice and a developer to implements. This leads to a series of problems with the solution, a lack of domain knowledge throughout the organization, misleading code, poor data structures, un-maintainable codebase, insufficient or incorrect solutions and worse. -We will explore the intersection of the fields of design thinking, agile and domain-driven design as a better way to build products. +We will explore the intersection of the fields of design thinking, agile and domain-driven design as a better way to build products. Taking some of the best ideas from each while escaping some of the implementation details that can limit adoption. + +In this first chapter, we will take a look at what design thinking is, outline the commonly referred to process and pick apart whether it needs to be done in totality. We will explore -In this first chapter, we will take a look at what design thinking is, outline the commonly referred to process and pick apart whether it needs to be done in totality. +- Discovery +- Ideation +- Prototyping +- Validation +- The Double D method Design thinking process can offer an excellent way to engage domain experts in the creation of a product. Domain-driven design offers a set of tools for taking these findings and creating software implementations that more concisely capture the knowledge we have learned. -In this chapter we will introduce domain driven design ideas we will be covering in this book: +I will also introduce domain driven design ideas we will be covering in this book: - Ubiquitous languages - Glossaries @@ -33,11 +39,14 @@ In this chapter we will introduce domain driven design ideas we will be covering ## Chapter 2: Discovery We will outline the steps a development team is taking to implement a new warranty tool for a bike company. Working on any problem first requires learning everything you can about the problem. This critical phase is often one that software developers are left out of. We will explore why this is and why it should not be the case. -The first exercise introduced is a Stake Holder Mapping. This is a method for identifying potential domain experts to consult regarding the current process in place for warranty issues. The StakeHolder mapping also serves as a nice first pass at a bounded context diagram. +In this chapter we will introduce the following tools: + +- Stakeholder mapping +- Context Boundaries +- Bounded context diagrams -Next, we will introduce how to develop buy-in from domain experts and bring them into the process. This includes setting expectations, motivating participation and introducing the problem. +The first exercise introduced is a Stake Holder Mapping. This is a method for identifying potential domain experts to consult regarding the current process in place for warranty issues. The StakeHolder mapping also serves as a nice first pass at a bounded context diagram. -The final method introduced in this chapter is Experience Diagraming. This is a method for exploring the current process and visualizing it. Each of our identified stakeholders will be utilized to help outline all the steps a warranty takes from creation to completion from their perspective. This lifecycle exploration helps us to see potential areas of improvement. It also provides a collection point to work on our context boundaries and ubiquitous language. ## Chapter 3: Interviewing and Job Shadowing @@ -56,17 +65,26 @@ In this chapter, we will outline how to conduct a successful interview and how t ## Chapter 4: Gaining Context -In this chapter, we introduce two methods for contextualizing information we gained in the prior exercises affinity clustering and rose, bud, thorn. +In this chapter, we introduce two methods for contextualizing information we gained in the prior exercises: + +- Affinity clustering +- Rose, Bud, Thorn. Affinity clustering is a method which helps to sort our notes into contextually similar groups. Through this process, we sort the findings and observe groups that naturally start to emerge. Often we find numerous groupings inside a problem area that may map to or expand upon our contextual boundaries. We will use the output of this exercise in three ways, first to redefine our contextual boundaries. Next, we will seek related sets of problems we can later prioritize. Finally, we will introduce ways to utilize affinity mapping to organize our collected language, processes and domain events. The second method introduced is Rose Bud Thorn. This is a tool used to categorize findings into positive (Rose), negative (Thorn) and items with potential for improvement (Bud). We will then use this as a way to discuss identifying potential areas for improvement. -## Chapter 5: Creating our Ubiquitous Language Glossary +## Chapter 5: Creating and Using our Ubiquitous Language Glossary We now have a collection of language and bounded context that will allow us to create a glossary. We will explore what a glossary is and how to create one from your findings. -The book will also show some pseudo code examples of how this language and context-bound idea can be implemented to lead to cleaner implementation and separation of concerns. We will explore techniques for name-spacing code, organizing files, naming methods vs. objects and separating concerns. +- Breaking apart your domain by context boundaries +- Keeping language contextual +- Context Mapping +- Escaping implementation details +- Maintaining ubiquitous language and context boundaries long term. + +The book will also show some pseudo code examples of how this language and context-bound idea can be implemented to lead to cleaner implementation and separation of concerns. We will explore techniques for name-spacing code, organizing files, naming methods vs. objects and separating concerns. One tricky thing in the world of domain driven design is the level of implementation detail, this can prevent adoption or cause friction with timelines or frameworks. We will explore how to accept some ideas but not others. We will also explore how to keep these glossaries up to date and useful in your projects. @@ -78,12 +96,20 @@ Defining a problem statement can be political and difficult to write. Our Rose, We will utilize explore the proper language for phrasing problem statements and why language matters. Once we have identified the problem statements, we will look at two methods of choosing the problem to work on, bracketing and star voting. +- How to phrase a problem statement to encourage exploration. +- What is broad enough vs too broad in a statement. +- Choosing one problem statement among many potentials + ## Chapter 7: Ideation Now that we have a problem statement to work on we need to start thinking about how to approach our problem. Ideation is a process of generating as many ideas as possible. These techniques are useful in a number of scenarios where you need to generate potential solutions to a well-understood problem. We will introduce a few exercises to help with the brainstorming process. +- Creative matrix +- Story boarding +- Expanding statement starters + First, we will try redefining the opportunity by changing our statement starter by turning it into a question in the phrases of who, what, when, where, why and how. We will use each of these prompts to define as many answers as possible. Next, we will look at creating a creative matrix. In this process, we define 5 assets we have at our dispense to solve the problem and we align those with our domain areas to brainstorm how the statement starter could be solved, approached etc in different combinations of tools and subdomains. @@ -92,6 +118,11 @@ Next, we will look at creating a creative matrix. In this process, we define 5 At this point we have created a number of competing solutions, deciding which ones to pursue is often politically charged. We need tools to remove the personal attachment we hold to ideas and look at them subjectively. We will look at three exercises for doing this work. These tools are exceptionally valuable for going through backlogs, ranking company alignment goals like OKRs or getting stakeholders to express their needs accurately. +Method: +- Importance difficulty mapping +- Buy a feature +- Bracket voting + First, we will look at Importance Difficulty Mapping. In this exercise, we create an (x,y) graph to visualize the importance and difficulty of every item we came up with during ideation in a quadrant. This visualization shows us the low hanging fruit, high-importance difficult items, low-importance low- difficulty items, and low-important high-difficulty items; assisting us in choosing what to work on. Buy a Feature is a game in which each player is given a budget and can choose which features they would pay for. This show which features are most valuable to which stakeholders. @@ -108,18 +139,47 @@ The first is a user-facing prototype that shows off a feature that they will be The second is a technology prototype, often when we set out to build a new feature, app, etc... much of our architecture decision is based on the strongest political position in the room or the most familiar tech. Technology prototypes allow us to break out of this and offer a space to experiment and validate different ideas. We will outline how to run a successful technical prototyping session. +Methods: + +- User facing prototypes. +- Implementation prototypes. +- Setting up rails to encourage safe experimentation. +- Encouraging playful development. + ## Chapter 10: Validating and learning from Prototypes We prototype in order to ensure we are choosing the right direction, but learning from prototypes is an art. We need to separate our preference and bias and see what the prototype is really telling us. We will look at user testing our stakeholder facing prototypes and how to iterate. We will also look at tools for qualifying technical prototypes, setting criteria, validating new tech and outlining how to assess risk. +Methods: +- Inviting users to the testing table +- Paper prototype testing +- Validating technical prototypes by risk assessment +- Combining competing ideas. + ## Chapter 11: Cooking with ingredients Throughout this book, we have followed a very defined line of discovery, ideate, prototype and validate. This recipe is common in design thinking, however, the dogma of this process is misleading. Much like a great chef starts by following a recipe, they soon learn to break the ingredients apart and use them appropriately in different scenarios. We can utilize any one of these different methods in a number of scenarios and add a dash of ideation here and a prototyping session there without following the entire process. In this chapter we will look at running better retros, aligning a backlog, blameless incident response, prototyping the competing implementation details, and how to run partial or full design thinking process in short periods of time. +Methods: + +- Bridging the gap with agile +- Developing a design sense +- Slowly introducing teams to these methods. +- Retros. +- Scrum planning + + ## Chapter 12: Going remote -Many of the tools in this book are possible to do remotely as well. Let's take some of the common methods in this book and discuss how we can bring them to remote teams.:w \ No newline at end of file +Many of the tools in this book are possible to do remotely as well. Let's take some of the common methods in this book and discuss how we can bring them to remote teams. + +- Google docs +- Post it note applications +- Story telling sessions +- Sharing videos +- Code as documentation +- Test that represent intention \ No newline at end of file diff --git a/book/proposal/proposal.md b/book/proposal/proposal.md index b7adeef..0128832 100644 --- a/book/proposal/proposal.md +++ b/book/proposal/proposal.md @@ -86,7 +86,7 @@ In the Cathedral and the Bazaar a number of important ideas were set forth relat 1. To solve an interesting problem, start by finding a problem that is interesting to you. 1. Provided the development coordinator has a communications medium at least as good as the Internet and knows how to lead without coercion, many heads are inevitably better than one. -Interestingly it contradicts itself pointing out a major issue with the way we develop software: +Interestingly the book contradicts itself pointing out a major issue with the way we develop software: > Every good work of software starts by scratching a developer's personal itch. From f15567c250c6c8c7cbf50e0e7a75d33c115076fb Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Thu, 21 Feb 2019 14:46:58 -0500 Subject: [PATCH 28/30] book proposal --- book/proposal/sample chapter2.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/book/proposal/sample chapter2.md b/book/proposal/sample chapter2.md index c165056..ae2f0a6 100644 --- a/book/proposal/sample chapter2.md +++ b/book/proposal/sample chapter2.md @@ -423,3 +423,5 @@ We have now collected a strong representation of the domain from the warranty ma We also have a much better long term view of how the code itself may grow and change since we understand the working condition of the warranty lifecycle. This will help us make informed decisions as we build our solution that will keep us from setting up traps based on lack of foresight. Finally we improved our relationships with key internal stakeholders. This social capital can help us champion our project and improves collaboration which can only improve our project. We have developed a toolset which helps us collaborate in an effective way instead of just complaining about things that are broken. + +In the next chapter we will take these things we learned in this chapter and use some design thinkings methods to reflect on the knowledge we have gained. From e2c8fc873c3e670077f121c542c34d7d56742f2b Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Sun, 24 Feb 2019 16:04:16 -0500 Subject: [PATCH 29/30] Update proposal --- book/proposal/proposal.md | 77 ++++++++++++++++++++++++++++++--------- 1 file changed, 59 insertions(+), 18 deletions(-) diff --git a/book/proposal/proposal.md b/book/proposal/proposal.md index 0128832..20fd4ab 100644 --- a/book/proposal/proposal.md +++ b/book/proposal/proposal.md @@ -1,10 +1,11 @@ -# Proposal for Design Think for Developers +# Proposal for Domain Centric Software ### By: Cory Gwin ## Overview -Technology is simply a tool for solving a problem. Arguably the most valuable tool any developer has in their tool chest is the ability to understand, communicate about, break down a problem and provide a proven solution. Most organization find this incredibly difficult to do and often organization focus on how fast they can ship instead of how well their solutions are received. Oddly, as terrible as we are at this part of our jobs, our problem-solving tools get nowhere near the attention as our text editor skills, the scripting language of choice or deployment skills and other tools in our development war chest. Instead, we hand it off to other parts of the organization and later complain about them throwing requirements over the wall without asking if we should break down the wall. -It is time to break down these artificial boundaries and take responsibility for the solutions we build. The agile manifesto states we should prefer customer collaboration over contract negotiation. As developers we often leave the customer collaboration to others in our organization, leaving only short user stories or issues to gather context. This leads to a number of problems including: +Technology is simply a tool for solving a problem. Arguably the most valuable tool any developer has in their tool chest is the ability to understand, communicate about, break down a problem and ultimately provide a proven solution. Most organization find this incredibly difficult to do and often organization focus on how fast they can ship instead of how well their solutions solve a problem. As software developers our problem-solving tools get nowhere near the attention that our text editor skills, language of choice or deployment skills get. Instead, we hand it off to other parts of the organization and later complain about them throwing requirements over the wall. The time has come to break down the wall and become closer to the problems we are solving. + +The agile manifesto states we should prefer customer collaboration over contract negotiation. Most developers live in a process I will call task board shuffle leaving implementation to be done in a knowledge vacuum. This leads to a number of problems: - Downstream communication issues. - Misunderstood requirements. @@ -12,23 +13,37 @@ It is time to break down these artificial boundaries and take responsibility for - Developer frustration. - Scope change or creep. - Lost context over time. -- Code that does not properly convey intent. -- Unintended consequences of poorly modeled data. -- Incorrect prioritization. +- Code that does not properly convey the domain. +- Poorly modeled data. +- Mis-prioritization. Our workflows and structures create communication barriers we must break down in order to move our implementations closer to their domains. As developers, our goals should include moving ourselves and our code closer to the domain. This requires understanding not only the problem being solved by a feature but also, more broadly an understanding of the field we are working in. -Design thinking offers a toolset for gathering insight into the domain that can help engineers understand a user's problem more fundamentally and offer a number of useful byproducts such as: +We seek to develop a toolset for gathering insight into the domain that can help engineers understand a user's problem leading to: -- Providing a better understanding of the entire domain. -- A clearer path to a domain language. +- A better understanding of the entire domain. +- A path toward a domain language. +- Bounded Contexts. - Understanding problem nuance. -- Gaining lessons learned of the user. -- Clear prioritization of tasks. +- Capturing valuable insight from domain experts. +- Clear task prioritization. - Identifying focused solutions. -- Providing insight into how an implementation may evolve. +- Foresight into how an implementation may evolve. + +Following the path of a team replacing a legacy application with a new application, this book will explore tools from Design Thinking, Domain Driven Design, and Agile introducing methods that can be utilized to break down a domain and better communicate with domain experts. + +After reading this book developers will feel equipped to: + +- Interview domain experts. +- Capture domain knowledge and translate it into domain centered language in a software application. +- Better understand the problem space they are developing a solution for. +- Learn how to clearly communicate with domain experts about their business problems. +- Evaluate potential software solutions and implementation choices without bias. +- Engage domain experts earlier in implementation for feedback, in order to avoid mistakes as soon as possible. +- More cleanly represent the domain in code and data stores. +- Run blameless retrospectives. +- Engage methods to learn from outages and identify solutions. -Following the path of a team replacing a legacy application with a new application, this book will explore tools that can be utilized to break down a domain and better communicate with domain experts. The book will introduce a number of design thinking exercises and explain how they can be applied in different scenarios to help agile developers craft clearer implementations. ## What this book will cover: @@ -54,23 +69,49 @@ Following the path of a team replacing a legacy application with a new applicati - Outline effective tools for using design thinking to create ubiquitous language, bounded contexts and domain events. - Outline rules for effective design thinking on agile teams. - Discuss ideas for bringing these methods into teams that are not familiar with design thinking. +- Processes for rapid prototyping. +- Tools and processes for beta testing features. ## Audience: -This book is suitable for developers, managers, product manager, project managers, designers and anyone looking for methods to bring implementation closer to a domain. +This book is targeted at developers and architects seeking ways to work more closely with domain experts in order to understand complex problems and craft informed domain centric implementations. ## Why is your book different? -This book will offer design thinking tools set aimed at software development, with a minor focus on domain driven design. It will introduce software developers to all the phases of design thinking and teach them skills to help solve problems in more creative ways, skills emphasized include: +This book will offer a number of methods from design thinking, agile and domain driven design aimed at bridging the gap between domain knowledge and implementation. This marriage of skills will be separated from heavy handed implementation details and instead focus on methods for interacting with domain experts to extract information useful in crafting domain centric software and more creative solutions. Skills emphasized include: + +Design Thinking: - Communicating effectively with stakeholders. - Identifying when to utilize design thinking methods and when not to. - The discovery, ideate, prototype phases of design thinking. - Individual design thinking methodologies and when to use them in the software development lifecycle. +- Methods for prototyping. +- Hack weeks. + +Agile: + - How to run better retros. +- Methods to prioritize tasks during sprints. - How to evaluate what to build given competing priorities. -- Understanding the business domain they work in the day-to-day. +- Time boxing. +- Encouraging design spikes with guide rails. +- Fitting research into your sprints. +- Team switching for knowledge transfer. + + +Domain Driven Design: + +- Capturing business details from domain experts in a way that transfers to software details. +- Identifying domain entities, domain events, context boundaries, and a ubiquitous language. +- Translating domain knowledge to code via testing, method naming and object naming. +- Understanding bounded contexts in software. - Building long-lived communication tools that impact internal/external communication and code design. +## Competing Books +- [Domain Driven Design Distilled](https://www.amazon.com/Domain-Driven-Design-Distilled-Vaughn-Vernon/dp/0134434420/ref=sr_1_fkmrnull_1?crid=33UZDG9LM3BY0&keywords=domain+driven+design+distilled&qid=1550802381&s=gateway&sprefix=Domain+Driven+Design+D%2Caps%2C303&sr=8-1-fkmrnull) +- [Design It! From Programmer to Software Architect](https://www.amazon.com/Design-Programmer-Architect-Pragmatic-Programmers/dp/1680502093/ref=sr_1_1?keywords=Design+It%21&qid=1550802621&s=books&sr=1-1) +- [Lean Customer Development](https://www.amazon.com/Lean-Customer-Development-Hardcover-version/dp/1449356354/ref=sr_1_1?keywords=lean+cindy+a&qid=1550802543&s=gateway&sr=8-1) + ## Why we should get excited about your topic: @@ -92,8 +133,8 @@ Interestingly the book contradicts itself pointing out a major issue with the wa The implication here is that we do not know how to collaborate with our users in the same way as when we develop to solve our own problems. -This book makes a case that in order to solve problems we need to move the solution architects closer to the domain space. I believe in order to replicate the success of the open source movement in a broader way, we need to find ways to bring domain experts together with solution architects to create a new way of interacting. If one is to believe "We are as gods and might as well get good at it" then we need to focus on creating tools for others in a manner we ourselves would accept. +Domain Centric Software makes a case that in order to solve problems we need to move the solution architects closer to the domain space. I believe in order to replicate the success of the open source movement in a broader way, we need to find ways to bring domain experts together with solution architects to create a new way of interacting. If one is to believe "We are as gods and might as well get good at it" then we need to focus on creating tools for others in a manner we ourselves would accept. -It then sets forward a set of tools to help developers take action on this premise equipping them to discuss complex problems with their user base in new and collaborative ways. +I intend to present a set of tools to help developers take action on this premise, equipping developers to discuss complex problems with their domain experts in new and collaborative ways. \ No newline at end of file From 3cc121432980017b852b9c104a9a840e75279c9f Mon Sep 17 00:00:00 2001 From: "Cory Gwin @gwincr11" Date: Mon, 25 Feb 2019 19:51:23 -0500 Subject: [PATCH 30/30] update proposal --- book/proposal/outline.md | 2 +- book/proposal/proposal.md | 30 +++++++++++++++++++++++++----- 2 files changed, 26 insertions(+), 6 deletions(-) diff --git a/book/proposal/outline.md b/book/proposal/outline.md index 590ef95..45f8b59 100644 --- a/book/proposal/outline.md +++ b/book/proposal/outline.md @@ -1,4 +1,4 @@ -# Outline for Design Thinking for Developers +# Outline for Domain Centric Software ## Chapter 1: Introduction diff --git a/book/proposal/proposal.md b/book/proposal/proposal.md index 20fd4ab..53ef73f 100644 --- a/book/proposal/proposal.md +++ b/book/proposal/proposal.md @@ -108,10 +108,9 @@ Domain Driven Design: - Building long-lived communication tools that impact internal/external communication and code design. ## Competing Books -- [Domain Driven Design Distilled](https://www.amazon.com/Domain-Driven-Design-Distilled-Vaughn-Vernon/dp/0134434420/ref=sr_1_fkmrnull_1?crid=33UZDG9LM3BY0&keywords=domain+driven+design+distilled&qid=1550802381&s=gateway&sprefix=Domain+Driven+Design+D%2Caps%2C303&sr=8-1-fkmrnull) -- [Design It! From Programmer to Software Architect](https://www.amazon.com/Design-Programmer-Architect-Pragmatic-Programmers/dp/1680502093/ref=sr_1_1?keywords=Design+It%21&qid=1550802621&s=books&sr=1-1) -- [Lean Customer Development](https://www.amazon.com/Lean-Customer-Development-Hardcover-version/dp/1449356354/ref=sr_1_1?keywords=lean+cindy+a&qid=1550802543&s=gateway&sr=8-1) - +- [Domain Driven Design Distilled](https://www.amazon.com/Domain-Driven-Design-Distilled-Vaughn-Vernon/dp/0134434420/ref=sr_1_fkmrnull_1?crid=33UZDG9LM3BY0&keywords=domain+driven+design+distilled&qid=1550802381&s=gateway&sprefix=Domain+Driven+Design+D%2Caps%2C303&sr=8-1-fkmrnull): Unlike a traditional domain driven design, domain centric software will focus more on the customer interaction process and how to effectively run these processes. I will largely avoid implementation details and offer more design thinking techniques. I also think domain driven design is limited in that it often leads to automating inefficient processes, thus making fast inefficient process due to it often skipping the ideate and prototype steps that I will be covering. +- [Design It! From Programmer to Software Architect](https://www.amazon.com/Design-Programmer-Architect-Pragmatic-Programmers/dp/1680502093/ref=sr_1_1?keywords=Design+It%21&qid=1550802621&s=books&sr=1-1) This books is a great companion book to mine and I hope to work with Michael to run workshops together. I will be covering more of the design thinking processes in depth then this book as it focuses more on Architectural patterns and choosing implementation by using design thinking to evaluate risk. In an implementation point of view I will be focusing less on architecture and more on capturing the language of the domain in your implementation and also on crafting solutions that meet the problems head on by exploring and becoming familiar with the problem the domain expert is working on. +- [Lean Customer Development](https://www.amazon.com/Lean-Customer-Development-Hardcover-version/dp/1449356354/ref=sr_1_1?keywords=lean+cindy+a&qid=1550802543&s=gateway&sr=8-1) This book covers a number of similar methodologies but it is slanted more towards product development as opposed to gathering information for implementation. I am less interested in finding and validating a market and more interested in creating software that feels like it belongs to the domain. ## Why we should get excited about your topic: @@ -137,4 +136,25 @@ Domain Centric Software makes a case that in order to solve problems we need to I intend to present a set of tools to help developers take action on this premise, equipping developers to discuss complex problems with their domain experts in new and collaborative ways. - \ No newline at end of file +## Author Bio: +Growing up I enamored by the house my grandparents lived in, designed by a associate of Frank Lloyd Wright I could sense the oneness it had with the immediate environment. This experience has left me continually frustrated with our inability to create software that encompass the environment of the software in a fluid way. + +In my career I have worked in UI, project management and as a backend developer trying to move myself closer to a place where I can see the thread connecting the problem space back to the solution implemented in our code and how we get there. + +Working at GitHub and watching/participating in the open source movement has made me realize there is a promising pattern available when we collect opinions at a massive scale and understand the domain well, but we do not posses tools and techniques to work on domains other then the domain of the programmer in such a fashion. + +I began trying out design thinking on a job where I was given total control, the results were better then other projects I had worked on and I think it is an incremental improvement. I have found success marrying the ideas found in Domain Driven Design, Design thinking and Agile. I think this combination is unique and beneficial to all significant development efforts. + +## Marketing Ideas +- I live in Pittsburgh near Michael Keeling and we have been discussing teaming up for workshops. +- I like to speak at conferences and run workshops. +- I do some twittering but it is minimal. +- I would be open to podcasting. + + +## Page count: +- 250-300 pages? + +## Timeline +Realistically my first draft will take a year, I am expecting a baby in late May so I think that will slow me down a good bit. +