Expert Explains How to Transform Your Software Development Process

Show video

I can think of countless projects that  I've been on that started with we need   a new piece of software or a SAAS  or probably my favorite is we need   a button on our website and that's going  to solve every problem imaginable and   ultimately the button the technology  solution actually made the problem [Music] worse the world our organizations and customer  needs are changing too fast for monolithic   projects to take months to years to be implemented  we need that value now yet few teams can operate   in pure agile and those challenges magnify  with scale and Rising complexity the answer   is Shifting to a solution delivery life cycle that  includes improving intake product management and   operations it's no longer simply about development  and deployment joining me here today to talk a   little bit more about how we're going to implement  that in practice is principal research director   Vince Mirabelli advisor on solution DLC Vince  what have you been hearing out there in terms   of pain in the marketplace that led us down this  road and why you know people should actually care   about this solution delivery life cycle yeah  I mean first of all great great to be here Jee   thanks thanks for having me I would say the the  thing that we hear the most is about building   alignment with your business partners so as a  as a technology team you know how do we ensure   that we're aligned well with what our business  partners and the entire organization are trying   to achieve and part of that led to this expansion  this reimagining of what the software development   life cycle the traditional sdlc is and it's it's  it's no longer just about software it's about that   holistic uh endtoend process of delivery of value  and so it's not about software software may be one   of the pieces that we deliver but this is about  delivering a solution that adds value and builds   alignment across the organization Vince tell me  a little bit about the current state this world   of software development life cycle and not  solution development life cycle um you know   where's the pain what what are some of the risks  of doing it that way when we're looking through   that software lens we're really hyperfocused on  that development and delivery of software but   what it misses is is the book ends so at the at  the at the front end we've got product management   are we building the right products are we  delivering the right value to our stakeholders are   we doing the right things and and and building the  right things for our stakeholders that become part   of that solution at the other end we have this  concept of continuous uh Improvement continuous   delivery so are we delivering software sort of  monolithically and at the end it's like here's   your thing away you go or are we taking more of  a a lower a agile approach iterative approach   at the end end and emphasizing implementing and  and enabling a continuous delivery model so that   we're we're cycling through and and and enhancing  the value that that the solution brings so it's   it's no longer just about software software is  the piece in the middle that may enable the the   delivery of value but it's really about those book  ends that's really different and that's why we   had to expand this definition to include the that  end to-end solution Vince one of the key insights   Maybe the key Insight you know underpinning this  entire research set is that delivery is about more   than just software you know can can you share  with me you know what that means to you and you   know what technology leaders should be thinking  about in that capacity we tend to default to this   this software solves everything and and at the  end of the day our stakeholders don't care about   software or process enhancements or uh changes  they just they're trying to solve a problem   and so what we're doing here is we're we're trying  to enable that and help them get to that place   where where they're able to solve their problem  we're helping them solve their problems you know   I I can think of countless projects that I've  been on that started with we need a new piece of   software or a SAS or uh um probably my favorite  is we need a button on our website and that's   going to solve every problem imaginable and and  ultimately the button I won't get into the the the   specific details but the button the technology  solution actually made the problem worse and   so that was an example where technology uh and  the the the software did not solve the problem   what we had was actual you know Pro a need for a  process change and a need for some some additional   oversight and governance and so that's the piece  that really includes that treating the the product   as as a whole so that we deliver Optimal Solutions  so you know we we start with product management   what is what are the right things what are the  right features what are the right functions and   how are we going to manage our our products our  processes our projects whatever whatever we want   to call them and then down into that that idea  of continuous delivery so getting deploying a   solution it rating fixing what what might might  broke might be broke or what we don't like or   what features are going to continue to en enhance  value so it really does take that end to end it's   not about that software the software is important  right I don't want to minimize the impact and the   value of of software but it's a it's a way we  get to the solution and to that delivery of   value it's not the end in a solution DLC world  how does product management or how does that   initial piece prevent us from going off the rails  prevent us from the we just need software we just   need a button on the website problem if you've  got effective product managers they can do a   really good job of of cutting through the noise to  ensure that the features and those functions the   pieces that they're that are going down through  the funnel actually are going to add value and so   they become I I I don't want to say that they're  The Gatekeepers because that gives them this this   air of authority but what they really do is they  understand what it is that the business and the   organization and and their stakeholders need and  then they're they're getting they're guiding it   through the various definitions of done so that  it's to a point of okay now now it's ready we've   articulated the problem we understand the  impact uh we understand why this needs to   exist now we're ready to develop a soft a piece of  software or you know some lines of code that help   us solve the problem so product managers become  effectively become The Gatekeepers to effective   solution delivery what does an effective product  manager look like and is it buildable or it does   do you have to hire for that so I I think both I  think both are possible I think good good product   managers we like to say good product managers or  product owners are are like CEOs of their product   right they they own it they own every aspect  of it uh they own the budget they own the plan   they own the strategy they own everything all  too often I see product owners who are proxies   they're representatives of the business and so  they may be product owners in title but they're   still just following the direction of their line  of business partners and we all know that they all   want technology and that's that's fine good good  product owners are like that that true owner they   they're they own it from end to end so I would say  it's a skill that you can acquire because there   are people that probably have that skill although  I would I would maybe argue that having someone   in house that develops the skill maybe of more  value and the reason I say that is they already   come in with that tacit organizational know know  they understand the culture they understand the   players they understand how to navigate the waters  as it were and so they may need upskilling in the   in the technical aspects of product management um  and then they probably need some practice and some   experience but I I think that you you know you  you could go either way I know which way I would   suggest yeah Vince in this research one of the  first statements that we make is that waterfall   is dead what do we mean by that and what are the  implications I think at this point waterfall has   uh outlived its its its life um we you know I  think there's still a place for it somewhere in   the world but not in the world that we live in  now uh we're moving at too fast a pace to spend   months and months and potentially years planning  those big monolithic massive projects because   the world is changing and so waterfall is dead  is is is really our way of saying you know you   can't waterfall does not have a place anymore  now I will say I have seen in some instances   where organizations try to make that transition  to Agile and just end up recreating waterfall in   in small it's like mini waterfall they need it  now right so so one one of the things I caught   you saying there was you know basically monolithic  projects bad right which is kind of a you know a   component of this whole no waterfall approach  I have to believe there are organizations out   there that you know could be hearing that and  saying well I'll tell that to my boss because   I'm in the middle of this like monolithic project  how do we get out of that and how do we make sure   that you know when we do have to deliver new  kind of you know foundational Business Systems   what what what should that look like in the  modern era it can be challenging particularly   for for larger Legacy organizations it's it's  much like steering a battleship right you need   you need to start start turning hours before  you actually need to to turn and so it it's   not going to change overnight um what we need to  do is really espouse the the value of delivering   iteratively and the impact that that has on our  organizations and on our Solutions but also on   our stakeholders just like anything else we need  to present the what's in it for them so what's in   it for our organization to deliver iteratively and  I won't even say agile but to deliver iteratively   versus in that large uh upfront planning which  which may or may not ever come to fruition uh I'm   sure you know the everyone that that that's that's  watching this or that that has uh has been in in   the project space for any any time has worked on a  project that never got out of planning and so you   know you could spend years planning something that  never actually delivers value I think if we if we   avoid the waterfall uh delivery method and go to a  more iterative method we're going to deliver value   or we're going to figure out what doesn't work  fairly quickly the next key Insight that you know   came out of this I was reading is that business  unit integration is not optional so you know tell   me a little bit about you know how we got there  and you know what that means and what that looks   like in practice Yeah we we need we need each  other one of the things that I've I've tried   to to Really push is is this distinction between  I'm in it and I'm in the business and unless   you've outsourced your it function you're all  the business and so recognizing that we the the   involvement of our business stakeholders is not an  option we need them and they need us right so it's   sort of a symbiotic relationship between between  the different lines of business let's call them   it's not about us versus them it's about how do  we align so that we're we're delivering value to   each other from the business perspective we're  getting the right solutions that are going to   help us solve the problems and the challenges that  we're facing that day from an IT perspective we're   working on things that add value and we're  not working on pet projects or working on on   initiatives that maybe don't help the organization  achieve their strategic goals and and objectives   so we we need each other and the only way that  that's possible is by building that alignment   building that bridge between the the those two  lines of business how do you do that what does   that look like that integration how do you how do  you get started it starts with understanding what   it is that your business partners need and then  you start the process of building that bridge it   it's it really is about building trust and and  enabling that alignment between between us and   them and I I don't use that carefully because  I don't want to make that argument that it's US   versus them it's not but it's about building that  bridge and building Trust ensuring that we're all   um aligned to how we're going to deliver value how  are we going to deliver value for our stakeholders   and how are they going to receive value from  us they need it and Technology to unleash to   unlock the value until we get to that delivery  we only have potential value right we're building   potential value we're building potential value  all along our our our our funnel it's not until   we actually launch that into the world deploy it  that our business partners start to to to realize   that value and that at the end of the day that's  what they care about so we need to build trust we   need to demonstrate that we are uh capable and  and have the ability to deliver that iterative   value to our stakeholders so it becomes a uh it  becomes a process of of just building and growing   together in our research Vince I noticed you  know we we took a stand when it comes to solution   delivery and we said quality has to come before  throughput can can you expand on that for us and   and you know how we got there and what the risks  are of maybe doing it the other way around yeah   I mean so if do we want to do we want to deploy  subop suboptimal Solutions into our stakeholder   group into our customer group no of course not and  so by building in quality up front we ensure that   we are reducing the amount of rework we're REM  we're reducing the amount of of required effort   and we're reducing our uh or we're increasing our  stakeholder satisfaction with the solutions that   they receive so to your previous question that's  that's one of the things that we can do to start   building that trust and building that relationship  with our with our stakeholders but we need to we   need to get to that that point where we're we are  delivering value how do you get to these quality   standards and who needs to be you know sitting at  the table to do so one of the biggest challenges I   think is actually aligning on a shared definition  of quality like what does quality mean it can be   subjective and one organization's definition of  quality is going to be very different than another   so what's important is that all stakeholders  align on what that definition means so that you   can drive towards that achieving that level  of quality the last thing you want to do is   have a a difference or Delta in that definition  within your stakeholder groups where one group is   expecting has defined quality as this and another  has defined it as this and that's how you get   that that conflict between stakeholder groups  because they're just not aligned so first and   foremost Define what quality means so  that you can align and drive towards that I'm joined today by three esteemed analysts  from infotech Ari glazel Rob fail and Vince   Mirabelli gentlemen I want to jump right into the  discussion on solution DLC really interesting and   Innovative model here and I wanted to ask you  right off the bat is this something that is   kind of tailor made for small mediumsized you  know projects and and and software challenges   or does it scale all the way up to um you know  kind of enterprise software uh Vince do you   want to take that first the principles that are  included in in in the blueprint apply across the   board um I think they just they help establish  good practices in your software delivery your   product management and your continuous Improvement  continuous delivery model so that and that builds   out your your solution DLC so I I would say that  this this was this scales across the board I got   a question for either of you if you don't mind  me asking a question now based on that would you   say that would you start there like like if I'm  picking up the infotech research on this would you   start with say for example your Erp implementation  or would you start with something smaller it would   depend it's always depends right right it is  one of those if you have no process or framework   to work with then this will give you a starting  place if you already have certain pieces in place   then maybe you need to optimize some of those  first right if for example intake requirements   analysis if you don't have that piece then the  rest of it not going to work because there's no   solution to deliver because you don't actually  or can't figure out what you're delivering so   that in the end would the start you have to have  the start in the right place to get you through   you also ultimately will need the framework  because you need from start to finish right   so does it apply yes it should probably apply to  everything do you have to apply it to everything   immediately no but you will at some point I  would say I just to to build on that I would   say uh could you apply it to an Erp size project  from jump yes you could yeah should you I I I'm   I'm a big big believer in getting some at bats and  getting some practice and locking in the process   before being able to apply it at a broader scale  so I I it would scare me to do something that   massive but that's not to say that you couldn't  well so let me take that uh oh because I for an   Erp the reason actually people have infotech is  because we have the experience to take you through   that solution framework so you don't have to apply  it you use our methodology you apply our expertise   to give you the framework without actually having  you to understand the framework but so it does get   applied you I don't think you'll be successful  without the framework in an Erp implementation   but you don't necessarily have to have it you can  borrow it from an expert such as us just staying   on that point for a minute Rob one of the uh you  know one of the maybe more controversial things   you know we wrote on this is just waterfall is  dead right as one of our insights given the work   you do in the Enterprise app space you know is  waterfall dead should it be dead is it dead in   some areas and H how does that apply when we  get to the the biggest implementations my back   software developer for more than 20 years there's  always been that question now I've always been on   the more flexible I'm not very good at following  rules kind as side so it's always been when is   waterfall successful waterfall is successful  if you understand all your requirements up   front and everything you have to deliver Hardware  engineering chip and level engineering you need   that because it's incredibly expensive to make a  mistake that if you design a software chip it cost   you about $25 million in today to do a prototype  you don't want to get very many mistakes when you   do that because you're throwing away $25 million  so that case waterfall makes sense because you   have an incredible amount of front-end effort  before you get to the solution because of the   value and I think that's really where you have  to look at it what's the value delivered by   doing that waterfall full solutioning throw it  over the fence to the next stage I want to talk   about what first of all focus on waterfall is  waterfall is dead sure so Eric Reese of the The   Lean Startup uh The Lean Startup uh um books and  articles if you've read it you know he said a few   pretty profound things one of them was you know  waterfall is only appropriate if you completely   understand the problem and solution agile is  only appropriate agile is only appropriate if   you understand the problem but not the solution  and lean you would use if you don't understand   the problem or the solution and you to figure  out both so focusing on waterfall for a second   right I I challenge any member to tell me that  they have something that they're implementing   where they completely understand the problem  solution perfectly if you do if you do then you   just need a checklist going from 1 through 10 do  that and you're done right that's not what we're   you know with solution DLC what we're saying  is that like that's just not the case that's   not realistic let's not pretend that we live in  that world still there are certain heart you're   right in specific very specific more narrow than I  think uh anyone really implies where waterfall is   still aoia but really in terms in the context of  of it organizations and what their providing and   the value they're providing to to their customers  internal customers and external customers uh you   know waterfall is truly dead yeah and I I would  say that in the vast majority of cases yes it   does not apply and now people will continue to  try to apply it but it doesn't it as I said it   isn't dead because there is that small percentage  it's so small it's not even worth discussing so   sticking with that for for a minute I mean you  talked Rob about the you know the I guess the   cost of failure or the cost of a redo and and so  you know in in some specific instances you need to   be able to answer those questions you know before  you you know before the shovel goes in the ground   so to speak yes is is is that true of you know  an Erp implementation of a CRM implementation   like when you've got that level of complexity  how how do you best leverage something like the   solution DLC to to make sure that you're finding  the right balance between you know you know we're   going to iterate and fail fast versus we're going  to answer all the questions before the shovels in   the ground so an Erp is already decomposed into  systems you've got accounts payable you've got   procurement you've got your full supplying chain  these are all pieces that in some cases you can   Implement in parallel and stand or stand alone uh  so often as you're implementing your core Finance   you can go ahead and do your procurement pipeline  because they're not really connected except for   the final piece to get the invoice over there  but all procurement setup isn't dependent on   the finance setup so you can do these in and you  can decide how fast I can fail on these different   pieces um and you can fail independently without  affecting the rest of the program so there is lots   of flexibility this definitely applies that you  can do a full solution delivery you could do the   the fail fast and temporary piece look at data  migration nobody gets data migration right the   first time it is often a multi-art stage piece and  in the end you may just decide it's good enough   um so there is built-in failure in an Erp you  just have to manage it it's never one shot you   never take you never shoot your shot and you don't  get another shot at it right but the whole concept   around solution DLC and the integration of agile  and good product practice on the front end cicd   integrated CC Pipeline on the on the on the far  end there is you're going to be taking a lot of   smaller shots and it's about organizing those  shots appropriately so even in the case of an   Erp here and I believe you're saying this is is  really it is is about I'm not going to implement   everything all at once I'm not going to implement  my whole financials module and my whole you know   AP module and all those pieces all in one one shot  I'm going to I'm going to figure out maybe using   some good business analysis practices some good  requirements practices understanding what's most   important versus less important and and order in  and stage in what you're going to do that's just   how that's just how you build software these  days yeah like there's no you're not going to   implement and configure your entire Erp then  test it then hand it over you want to in your   individual functions put the testing as close to  the configuration piece and get it done and then   moved on you know as we think about solution DLC  relative to software DLC you know we're thinking   about now kind of the broader ecosystem and the  pieces on each end of that you know I think about   that in relation to you like agile to waterfall  and I'm sure you know for each of you you've   seen an awful lot of agile implementations  that are kind of waterfall and agile clothing   is that a risk with solution DLC that they just  put you know people put lipstick on software DLC   and they call it solution DLC and if it is a  risk how do you get around that so I'd like to   respond because I I I agree that's a real that's  a genuine criticism and I understand where that   comes from one of the main motivations there were  a couple key motivations behind the research uh   and why we did it the way we did it one of them  was around that you don't have a team of a of a   100 or or 5,000 people writing code in a company  anymore building their own homegrown HR System   their homegrown Erp their homegrown data  transfer function right this is why we're   not talking about software you know software and  and development that's why we not talking about   software development life cycle we're talking  about solution delivery and so how how do we   support solution delivery delivery of offthe  shelf Erp offthe shelf products maybe there's   a little bit of configuration in there but it  is about it is a recognition that the world has   changed it's not about putting a lipstick on the  on a pig the world has changed right we're just   not doing it anymore and we need to catch up with  how people are actually delivering Solutions in   organizations today yeah and to add to that even  when you're building a custom system we don't say   go out and write it from scratch we are saying  pick a platform something that gives you a base   and a bunch of functionality and then extend  it so that there are solutions out there to   do case management why would you build your full  case man man agement system from the database go   ahead and build it on top of something gives  you a large ecosystem you can leverage and   it already has the full solution delivery built  into it because here is a a functioning platform   and all you're doing is building on top of it  and so you start off actually with a solution   to deliver um you're just building it on top of it  the so what what act sorry har no please what what   what you actually end up with is that building on  that base you don't have to configure everything   you just have to you have to figure out and then  configure what's changing and which makes the job   in in theory way easier because it's just what's  changing from A to B as opposed to what does B   need to be yeah you're not inventing you're  not exactly so development has turned into   configuration maybe a little bit of scripting  here and there as you need it right as as we   think about the you know the the roles and  responsibilities here um does this does this   model require us being in a product ownership  world does it require product owners to be   successful or does it work with a variety of kind  of you know operating models may I take that first   please go ahead please take first so a product  ownership model implies that there's somebody   that's accountable for the delivery of value So my  answer is yes can you sure but but you're you're   going to miss a lot of the the key benefits of the  solution delivery life cycle by not having that P   that role I'm not going to say person G be careful  I almost caught myself there um who's accountable   for the delivery of value so who's accountable  for that thing end to end and that person needs   to be and person or group needs to be there to  make sure again using what what Vince had said a   little little earlier on right uh you know deliver  the right thing the right time the right people   and if I'll let you go next I know you want  I'll let you go next but I'm going to really   go next really was going to say was it really is  a question of you know could versus should yes   and that that's really all I wanted to say could  you yes should you no we recommend you don't and   and what I want to add is I think people if they  think that nobody's accountable they're fooling   themselves there's no ownership ultimately whether  you take ownership or not someone is in the end   accountable which really means you have ownership  you're just not necessarily acknowledging um   because in the end if your your Erp fails or  your your software development project fails   somebody's going to have to pay for that yeah and  whether they're willing to accept that or not is   up to them it's better to go in with your eyes  open saying I do own this I'm accountable and   make sure that you're delivering so is there  is there a step zero to all of this which is   like you know understand um and clarify who is  accountable for the delivery of this value like   I don't even want to say call it this role um or  or change the roles but at least clarify who that   person is is that a fair statements that needs to  be step one and you could call the name whatever   you want doesn't really that's that's really as  long as you're internally consistent call the role   whatever you want to call it but somebody needs  to be account someone needs to be defined as that   accountable individual for the delivery of value  and if I could quote from a a movie a famous movie   I you know you can guess the title there can only  be one one and that's very important right yeah I   I use that line whenever I talk about Ry and  I you know that's sort of what we're talking   about here is that roles and responsibilities  is there is only one right yes I don't know what   movie you're talking about I'm um but but no I I  mean when when it comes to you can have multiple   responsible you can have multiple consulted you  can have multiple informed for accountable there   is only one CU you need to know where with whom  Does the Buck stop yeah right that you just you   you end up with pointing fingers of well I thought  you were doing it and I thought you were doing it   and who's actually accountable you have one  person and that's where projects fail is that   nobody's willing to make a decision and often in  public sector this is one of the challenges that   people aren't held accountable and this is why  projects take so long uh that we see it less in   private sector is that there tends to be someone  accountable because usually it's it literally is   the buck stops here yeah uh in public there is  less accountability this is obviously what we're   working to change and I know a lot of the public  sector is working to change but it's the one area   that we see it is projects run long because no  one's trying to no one is accountable right um and   it's hard when you're looking at election cycles  and things people are on a cycle well after four   years I'm no longer accountable so who cares so  these are the things that's why accountability   is a culture another it's trust in in the  organization is important if you're advising you   know an organization where there isn't sufficient  accountability you know would you just tell them   okay well sounds like you know solution  DLC isn't for you or or how how do you get there go ahead so I mean we would probably start  them start them elsewhere as opposed to solution   DLC to get started I mean solution see the  way it's laid out it will link you there but   generally a good a good info you know in fact all  of our good infot analysts will be able to listen   to that and diagnose that and say okay without  without a sense of ownership and accountability   here I mean you could have the most spectacular  uh process you know known to person kind and it   will fall apart and so uh we would start them with  some of our other research that does talk about uh   you know product ownership as a function product  practices and in general and and acclimating them   to that first giving them that context to then  be able to uh I think really appreciate what this   what this research does yeah I think it's it's a  cultural change um that's what you need to instill   yes and you can only do you can't jump in and say  I'm changing your culture that doesn't work so   that's why you have to sort build trust and show  them that this thing actually works and through   the examples of different things that that makes a  difference what pieces of research would you guide   them to if that's their if accountability is a  challenge we have a few pieces of research on   the product side that would that would help if  we're talking about accountability there is uh   make the case for product delivery to talk about  product management as a very broad concept as an   introductory piece we have uh uh you know we have  deliver new digital product Vision which talks   about the activities that that uh you know product  management needs to should be undertaking and in   terms of the role of product management itself  we have a piece of research that's been recently   updated and it's really you know really well done  mature scale product ownership which talks about

2024-08-13

Show video