Lean Agile Enterprise Requirements


Published on

Dean Leffingwell author of Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series) was the guest on the Business901 podcast. I talked to Dean so long that I divided the podcast into two parts, Lean Agile Software Train, part 1 and Lean Agile Software Train, Part 2. This is a transcription of both podcasts.

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Lean Agile Enterprise Requirements

  1. 1. Business901 Podcast TranscriptionImplementing Lean Marketing Systems Lean Agile Software Requirements Guest was Dean Leffingwell Related Podcast: Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  2. 2. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsDean Leffingwell is a consultant, entrepreneur, softwareexecutive and technical author who provides product strategy,business advisory services and enterprise-level agility coaching tolarge software enterprises. Mr. Leffingwell was founder and CEO of consumer marketing identity company ProQuo, Inc. Dean has also served as chief methodologist to Rally Software and as business consultant to Ping Identity Corporation and Roving Planet, Inc. Formerly, he served as Vice President of Rational Software, now IBM’s Rational Division, where he was responsible for the Rational Unified Process and promulgation of the UML. Previously, Leffingwell was co- founder and CEO of software toolscompany Requisite, Inc., makers of RequisitePro for requirementsmanagement, which was acquired by Rational. Mr. Leffingwellwas also the founder and CEO of RELA, Inc., and publicly heldColorado MEDtech.Dean’s Website: http://www.leffingwell.orgDean’s Blog: http://scalingsoftwareagility.wordpress.com/Dean’s Books (Amazon): Scaling Software Agility: Best Practicesfor Large Enterprises Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series) Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  3. 3. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsJoe Dager: Welcome everyone. This is Joe Dager the host ofBusiness901 podcast. With me today is Dean Leffingwell, a30-year software industry veteran who has spent his careerhelping software teams achieve their goals. He is a renownedmethodologist, author, coach, entrepreneur, and executive. Hefounded Requisite Inc., makers of Requisite Pro and served as itsCEO. And as Vice President of Rational software -- which is nowpart of IBM -- he led the commercialization of the Rational unifiedprocess. As an independent consultant and adviser to Rallysoftware he has helped entrepreneurial teams and largedistributor multinational corporations implement Agile methods atscale. He is the author of "Scaling Software Agility" and theleading author of the Managing Software Requirements.Dean, I would like to welcome you and congratulate you on yournewest book, "Agile Software Requirements." Its simply the bestbook I have seen on describing the structure of Agile from ateam, program, and enterprise perspective. I think you did amasterful job of covering mainstream thought and how to apply itin scale. I guess I have to start out by asking what prompted thebook.Dean Leffingwell: Thanks, Joe. What prompted the book wasactually a full circle in my thinking over the last eight or 10 years.I wrote about software requirements 15 years or so ago whenwere all thinking more linear in our thinking, more stage gatedand the plan was if you could get the requirements up front, theprogram would go better than if you didnt. And that was a timewhen software was more brittle, frankly, and it was harder toread factors and we didnt have the tools we have now. So I thinkthe economics drove us to invest more time up front trying to getthe requirements right. I evolved through the Rup, went throughmy time at Rational as responsible for commercialization of theRup into iterative, incremental development. During that time ofcourse Agile and especially a small team Agile was just a reallystrong trend in the industry over the last six to 10 years or so. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  4. 4. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsSo I wrote the software "Scaling Software Agility" in 2006 andpublished that in 2007 based on my experiences and taking someof those smaller team methods, XP and Scrum hybrids a fewother feature driven development and even DSDM techniqueswrapped in. As I did that the teams got better and better butthey kept coming back to, "Well the hard part is knowing whatsoftware to write and when weve done it well." Its not just amatter of no defects; its a matter of when our customers thinkthis is the right stuff.I was prompted again and again by people that I work with bysaying, "OK how requirements work in this?" If you look at Agiledevelopments from a Lean perspective -- software developmentfrom a Lean perspective -- particularly, the value stream, if youwill, what we deliver are just bits and bytes, this abstractions thatwe call software that reflect a customer’s needs.We dont have tangible widgets to put our hand on and tomeasure and test and to count and to stick up a Kanban cardwhen I need to load another resistor in the bin. A number ofpeople prompted me to say wed like to understand the valuesteam better and that comes back to how requirements flowthrough the system. From maybe a high or poorly expressedcustomer need into a high degree of specificity and user storageand acceptance criteria and test cases.So, a few years after writing "Scaling Software Agility" I decidedto one more time take a look at perspective, look atrequirements, but in this case from an entirely different, totallybottom-up Agile perspective. I also discovered, of course, inscaling Agile that we had some wonderful new constructs in Agilethat I had no part of inventing, mostly driven by XP, particularlythe user story.Card conversation and confirmation alliteration became the sweetspot, but as I was working with these larger enterprises we Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  5. 5. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsdiscovered that by far thats not enough. We need to have theability to describe features to our customer and large scaleenterprise level epics. We need relationships amongst thosethings so we can track when a feature gets done. We need to talkabout non-functional requirements again because if you miss aregulatory guideline or standard or some EPA regulation foremission in your engine control unit, youre going to fail just asbadly as if you missed any other functional requirement.So basically, Im compelled to write about these things, not now.Im certainly not writing anything right this second and thatswhat brought me back to "Agile Software Requirements." Alsowhen I wrote "Scaling Software Agility" we were relatively new inthe market in terms of making that case and consequently I thinkover the last three or four or five years weve developed just a lotmore sophistication in our practices, while still being Agile, thatscale to the enterprise level that I wasnt able to express in thatbook.I basically had a chance to think about Agile and scale again andI structured the book as you know in three parts -- requirementsfor the team, requirements for the program and requirements forthe portfolio. You can either take it a little at a time if you are anenterprise. If youre a team then only the first pieces matters or ifyou’re working with maybe a 100 people the second piece of theprogram. But if youre 300 people or 3,000 people then youregoing to really have to really take an enterprise view. So thatswhy I structured it basically in those organizational levels.Joe: It actually is an outgrowth of the "Scaling Software Agility"book because I think so many people lead into a subject thenthey learn so much more but this is a deep dive into that, isnt it?Dean: Yes, it really is. In "Scaling Software Agility" I had adifferent audience and I remember my editor actually cautionedme. I wrote that for team leads, managers and executives who Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  6. 6. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsneeded to consider the Agile paradigm and their enterprise andhe warned me, he said, "Well, number one theres not as many ofthem as there are practitioners, and number two..." Hechallenged me a little bit and said, "Are you sure theyre lifelonglearners?" And I said, "Well yeah, they mostly are and those thatarent need to be." I wrote the book for them and its effective inthat market but its not a book that was driven directly to thepractitioner. It didnt provide a lot for the developer and tester.So as I learned more and as I saw teams execute Agilesuccessfully more, I decided to go right to the sweet spot againwhich is, A, where there is more readers and, B, where theresmore people that might get a little bit of help out of reading thebook.It is Agile at scale and it is Agile requirements at scale and if youthink about it all we really have is requirements. We take ideasand turn it into software that you cant touch. So its not thatrequirements is one of the nine random artifacts that you mighttalk about in Agile development. Its the one that carries all thevalue to the user.Joe: I think that people get mistaken from a lot of this talk orwhen I talk to people about Lean Agile software, its becomingsuch a common way of businesses. The way theyre looking atthings with the iterations and learning cycles. Its a great learningexperience. We could drop the software off of that and the LeanAgile Enterprise is common place today. Maybe not commonplace but its getting there.Dean: Its definitely getting there. I work right now withenterprises that have quite a mix. Some of them make hardware,big iron. Others make large scale actually sell databases. Othersprovide service oriented approaches delivering various types ofdata and others do traditional enterprise software. They all wantto be leaner. I think if you did a poll right now of basically largeenterprises and large software enterprises and you said are you Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  7. 7. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsdoing Agile development? I believe that 80 percent of them wouldsay yes. But when you pull the covers back a little bit and youask some questions -- because I talk to those types of enterprisesquite frequently -- and you say well what did you do last year interms of Agile?" And they said, "Well we had 20 or 30 Agileprograms and they are quite effective." And you say, "Whats thetarget for next year?" And they say, "Well were going to doublethat. Were going to roll out Agile to twice that.Then you ask a further question that says, "OK. How manyprograms do you think youre going to execute in your largeenterprise next year?" And theyll say "300." So the question thenbecomes at that rate of adoption its going to take anotherdecade before youre really an Agile enterprise. So thats onecaveat.The second caveat is nobody can afford to say theyre not Agile.If you call any large company today and talk to the CEO and doan analyst interview and you say, "Is your enterprise Agile?"Theres only one answer to that and the answer is yes. So theresAgile and theres Agile. Theres little Agile, yeah, we feel prettyAgile and theres big Agile, which is the real Agile practices. Iwould say the enterprise adoption of big "A" Agile is still quitelimited. I think were at maybe at five or 10 percent marketadoption in terms of the number of practitioners today developingsoftware, maybe one in 10 or one in 20 is actually exercising XPand Scrum like serious very short iterations high quality Agile.Joe: Well iterations is a big word that people use and banteredabout and Im not sure everybody really conforms to what aiteration is? It is a complete loop. I think sometimes people forgetthat.Dean: Well, I tell you, thats a loaded word and thats one of thechallenges that we have when we talk to companies that saytheyre doing Agile and some of this is driven by the Rup, which Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  8. 8. Business901 Podcast TranscriptionImplementing Lean Marketing Systemswas iterative incremental and often misapplied. In the Rup; theinception, elaboration, construction and transition also often gottranslated into business case requirements design coding andtest, which was a poor interpretation of the Rup. But I see thingsand hear things all the time. I ran into the other day, forexample, a group that was doing six-week coding iterations. Agroup of 25 people describing to me their Agile prowess. Theywere developers only and they would do their code in large blobssix weeks at a time. It wasnt tested, it wasnt validated, and itdidnt have much feedback at all.It was just the next big increment of code. Well thats iterationbut its not an Agile iteration and theres a pretty big difference.So you run into that type of thing. I also ran into the other day aScrum team requirements analyst.I got to tell you I didnt know what to make of that. I know whatScrum is and I know what requirement analyst are, but you dontput six of them together and do a daily stand-up and call thatAgile or Scrum, its none of the above. I think theres just asmuch confusion and mislabeling as real Agile. I think thats a realdanger for the industry because 24 months from now everybodyis going to say theyre doing Agile, but whos really going to bedoing test driven developments and collective ownership andbuilding really serious high quality software in a short time box?Or are they going to have sprints of requirements and sprints ofdesign.Joe: What are the keys to building a Lean Agile softwareenterprise then?Dean: Working towards my one annual presentation, I do onetrade show a year. I go to the Agile conference every year. Itused to be Agile XP and that has just grown tremendously and itsa high value conference. So Ive been re-framing the way Idescribe the way I see large enterprises being successful around Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  9. 9. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsfive basic keys. Now Ill describe those keys here. It might be agood way to approach the things were talking about. Key numberone is, not everything is a user story. A user story is a reallygreat invention. It came from XP, the user voice forum, which is,as a user, I can perform this activity so I can get business value.This is just a fantastic breakthrough in our thinking. But userstories are small because they fit inside iterations and there arelots of them. So at the enterprise level they dont scale very welland thats why you see in my book "Agile SoftwareRequirements" a three-tier, three-approach of user stories,features and epics and even a fourth year if you will which is theinvestment themes that drive all that.So my first bullet thought is got to be smarter than just takingeverything to a user story. The second key is at enterprise scalethe way weve rolled out Agile historically which is a team entereda time or a Scrum mastered a time is simply too slow. So, I liketo think in terms of Agile programs and not just Agile teams.Agile programs are oriented around this construct that Iveroughly described as the Agile release train, which is asynchronous set... Or a team with a synchronous set of iterationsall timed together, working together, doing their planning, theircommitment, or execution of their feedback together as onefractal above an Agile team, which has exactly the same pattern.Thirdly, architecture emerges in Agile. Its part of the manifesto,but I got to tell you at enterprise class scale it can emerge insome really bad ways. And if youre sticking together an entireportfolio or youre doing enterprise class business applicationsyou cant expect any one team or any half-a-dozen teams to havea real view of how that all needs to work together or what typesof governance needs to be applied to those systems.So, as I wrote in "Scaling Software Agility," Im a big fan ofarchitecture and system architecture in the enterprise. And I call Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  10. 10. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsthat intentional architecture, which maybe flies in the face a littlebit of some of our thinking. Theres some of the agilest thinkingabout architecture but it cant be strictly emergent in my view. Soenterprise systems record potential architecture and I have amodel for that. That was brought to me by others that I had thegreat privilege of working with a couple of enterprises that werequite Agile and also needed to re-architect their systems. I callthat re-architecting the flow. So thats item number three.And fourthly if the teams are Agile and the programs are Agile,but the enterprise isnt, if the portfolio is still being treated withfixed budgets where people must be assigned to tasks. And inmonth nine, in order to justify keeping them on your program orthe portfolio function is driven by those who understandrequirements independent of implementation and communicatethat and make commitments on behalf of the teams andprograms, then youre not going to be very Agile either. Andtheirs set of legacy minds thats there that I think we have tocope with. So thats item number four.Lastly, and this is where Ive been spending most of my timelately and so many things are obvious in hindsight. I think wereall brilliant in retrospect. Its just the going forward part wherewe question our sanity. Lastly, your enterprise is going to be noleaner than the executives thinking and no matter what you try todo at the team or program level, until your executives are totallyon board.Not with Agile so much because Agile for them is good, soundsgreat but they dont do Scrum. They either think their teams arealready empowered or maybe thats just not a big concern oftheirs, depending upon their cultural bias and mindset andhistory. So, we dont have a lot of tools for them in Agile. Youcant take them the manifesto. Its useful and theyre interestedin that but it doesnt drive their lives. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  11. 11. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsIts tough to communicate with high-level executives about Agilepractices in a way thats meaningful for them because they dontdo any of it. But Lean, they can think about and understandingthe value stream and understand how certain, lets just say,governance items really caused delays in the value stream andunderstanding that the total tack time, the touch time, we put ona system is a small percentage of the total delivery time; gettingthem thinking about delays in the value stream and what causesthose delays and what they can do about it, is just a betterapproach.Id like to think in terms of two sub aspects. One is Leaneducation and I have one go to source now, which is Reinertsensnew book that I like to use with executives and have them read itand sit down and discuss some of those key principles. Thenlastly, youve got to show them how their enterprise is going tolook like after the transformation and I call that the AgileEnterprise Big Picture or the scaled Agile Delivery Model. If theydont know how its going to look later theyre not going to bevery comfortable with a totally self-organizing complex dynamicsystem thats just all going to work out.Even though thats largely the case, I think the pattern of howteams and programs get organized and how values flows; howtheyre involved as fiduciaries of the enterprise level; how thegovernance model works; how they drive the portfolio, is criticalto them. Because if they can see an after -- they know thecurrent picture, they know how it works now and they knowtheres some challenges but they wouldnt be reconsideringit -- but if they can and after it just makes their life a heck of alot easier. I call that Lean Education in the Big Picture.So those five keys, not everythings user story for sure, think interms of Agile programs not just Agile teams. Admit that ourlarge scale systems require intentional architecture. Think aboutsome of the legacy mindsets weve had in portfolio management Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  12. 12. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsand how to address those. Then also understand that were goingto be no leaner than the executives thinking. Those are the keysthat I currently keep in mind whenever I approach a barbarian atthe gate of the not as Agile an enterprise it wants to be.Joe: Let me go backwards here and start with the thinking inLean education and the big picture here with the executives. Tointroduce Reinertsens book is a pretty deep dive for them.Dean: It is. I have the good fortune to be called intocircumstances where enterprises are taking this very seriouslyand early on in an engagement model I talk about the executivesand their key role. I think one of the challenges, I dont know ifyou know the Scrum chicken and pig story, all right? Which itbasically says is that the people that write the software are pigsand everybody else is a chicken. Well, I tell you if you sit with abunch of those chickens and you look at the challenge they faceor you sit with them in front of their management and look attheir position in the market place and the challenges they face incompeting, they dont seem like chickens to me at all.I approach it a little bit differently and basically challenge themup front and say that your enterprise will be no leaner than youare and you are the ultimate drivers and the ultimate limiters onhow Lean and how quick your enterprise can be. I talk about theneed to spend time together and we do that often times in aworkshop, quite frequently a full two day workshop.This is just part of the process. Its not really optional if you will, Idont present it as being optional. Reinertsens book is short sothats deceptively cute, right? Its Lean product developmentflow. Its not a translation of the Toyota way of thinking, if youwill, about manufacturing to Lean.It is a guttural view of how things like work in process limits andcontrolling queue lengths and decentralization and cadence andsynchronization, how those tools help drive great performance Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  13. 13. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsand product development. So it is a deep dive for them, but sowhat? Agile is a deep dive. Were looking at productivity increasesthat are substantial, measured productivity increases in some ofthe largest enterprises Ive been involved with have reached 30and 40 percent. Well if you got a 1,000 people, thats 300 freepeople.Do we think an executive who can sit there and look at Agileslides for half an hour or read the manifesto and go, "Great, weknow how to execute." So youre right, its a deep dive but wetake that deep dive and we take it together. Often with me or theAgile working group -- I work with Agile working groups andtheres some pretty bright people there and they help.And the second piece of that, of course, the scaled Agile deliverymodel which is showing them how their enterprise will beorganized afterwards. They know how to organize now. Theyknow theyve got a large test department and they go, "Well if atest moves into development what happens to quality? How willstuff get tested? What about all the stuff that individual teamscant test?" So the scaled Agile delivery model is the other half ofthat. If I can get fixed in their minds, the principles of Lean sothey can operate as Lean thinking leaders every day and givethem an idea of where were headed then their comfort goes upand they can start to lead.I think if you think about transformations in Lean versus Agile, ifyou were doing a factory roll out five or eight years ago or maybeeven today of Lean, you dont go to the floor and just starttraining the people on the floor to work in cells. You takemanagement aside for a two week boot camp and you fullyindoctrinate them and you teach them Lean and you show themwho their partners are going to be in that Lean roll out, and itstheir job to implement Lean. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  14. 14. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsWe took the opposite approach with Agile. We called themchickens and weve kept them out because we didnt whateverreason didnt think theyd led us to where we want to be and itdoesnt scale to have the leaders not lead. It simply doesnt work.I just take it up front and I say, "Were going to be no better thanyou guys. Lets spend whatever time we need to get together toget better principles and philosophies aligned."Joe: Alan Bustamante wanted me to ask you what are the topthree challenges faced in building a Lean Agile softwareenterprise? Is leadership one of them? Is this what were talkingabout as one of your top challenges?Dean: Absolutely. Its the ultimate limiting factor, right? A lot ofthis comes from our experiences. If you train Agile teams, justmaybe roll out Scrum, a very effective and very simple model.Those teams will start putting pressure on the enterprise andtheyll start asking for things, literally tearing down walls. Wedont like our walls or cubicles. Wed like to use that lab overthere for our daily stand ups. Wed like to plan together. Wed liketo get the folks here from India with us every three months or so,so wed like travel budgets to do that. We need better buildinfrastructure. I need a team to work on continuous integration. Ineed the time to do some re-factoring. When you start pushingon managers who arent familiar with the model and you dontunderstand how those things drive performance improvementsover time, or if they understand that theyve alreadyaccommodated to the drone of those complaints then theyregoing to fall on deaf ears. Youll be ultimately blocked and youllbe more Agile than you were because you might have gottensome reorganization and maybe you got some product ownersand powers to make good decisions but youre not really buildingan Agile enterprise, youre building teams that are a little moreAgile than they were. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  15. 15. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsJoe: Can Agile work without the whole enterprise being Agile?Can you have a separate section? Lets say, because I know youwrote about John Deere, is just the software department, Agile orXerox, just the software is and the hardware guys arent. Arethey still compatible then?Dean: Well, you have to basically start that way because theactual manifest was written for software teams, Scrum and XPwhich are the primary roll out models, both very effectiveaddressing different issues. Those get rolled out in the softwareteams and then they start with their cadence andsynchronizations and then they want to have periodic reviews andthey want to have the software run on that prototype hardwareand the prototype hardware wants to run on a prototype machineor whatever. So, in those cases the teams start to drive theenterprise to be more Agile. You start putting pressure onorganizations because if you run Agile releases even if thesoftware isnt shipped youre going to have software available tobe shipped earlier and more frequent. So thats going to putpressure on sales and marketing if you think about how to dothat.So the answer is yes and no. Of course, to build a true Agileenterprise, everything eventually has to be Lean and Agile, butyou dont start there. These are journeys not written in six monthlittle case studies, these are journeys measured in years and theenterprises that Ive learned the most from are the enterprisesthat have been added the longest. Theyve been headed downthat path already. In their second and third and fourth year ofagility and theyre still starting to work with some of the issues,lets say, at the PMO level.Joe: When we go into the portfolio management, thats got to beAgile. There not even a question about that to be able to make itwork, is there? Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  16. 16. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsDean: Well, theres a question because it wont start that way.First, I want to give credit where credit is due and not just pickon the PMO or the other PM guys that were trained. The PMOshave built governance models around the waterfall life-cyclemodel because we taught them that was the way to writesoftware. We have new ways that were writing software now andwe have to teach them those too. But in the meantime, theirgovernance models and all of their activities are focused aroundthe milestones and things like design reviews and test plancomplete, requirement sign off, and code freezes before defecttriage, we taught them all that stuff. We shouldnt be surprised asagilists when we go to instill and install Agile and theyre saying,"Thats just great but you still have to meet the phase to exitgate which requires that the design is complete."Yet, if you go to those teams and say, "When will the design becomplete on this project?" Theyll look you straight in the eye andsay, "The day we take it out of maintenance." Not in the phasetwo milestone review. There are a lot of legacy mindsets that arethere but theyre not there because we have people that think inlegacy terms. Theyre there because thats what we taught them.I think we have the responsibility to educate them with Leanthinking and I have better luck looking at things like the waymilestones... Lets just say theres a design review milestone on aprogram and the program is late. I ask the PMO, I say, "Well ifthe program is late does the review move to the left or the right?"Meaning forward in time or later in time and they say, "Of coursethe review moves later." I then comment to the fact that whatyoure saying then is that the later the program is the less oftenwe look at it, right?They go, "Well thats not very Lean thinking." Because thats theopposite of what we should be doing and since we dont know iffor sure its late or right, why dont we just do periodic review ona cadence and well review maybe all the programs on the same Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  17. 17. Business901 Podcast TranscriptionImplementing Lean Marketing Systemscadence and look at whatever theyre doing. But if theyre notcreating design specifications for us because theyre Agile, theyllbe creating code. Why dont we assess the code? Lets ask themfor a few key measures around the code. Lets ask the productmanagers or customers or whomever how it is they see that thesee that code developing.Lets look at the facts. Lets look at the quantitative objectivefacts of how the code is evolving. Because in Agile, there will beno excuse for not having code. While they may not have some ofthese other things that youre used to seeing, theyll have a teststrategy. They may not have a test plan because to write downtheir test strategy into a plan, number one, they have a modelthats integral. Its no longer separate activity. Number two, theyonly write down what they need to write down and theyre notgoing to write that down just to give to somebody else. So, letsjust look at the code.So when you approach the boundary of a PMO, the way I like toapproach it is that your governance model got us here. Thewaterfall development got us here. Were moving forward. Werenot just going to throw away governance, right? We still needoversight; we need to know how were spending our money.We still need to drive the teams to the right vision and the rightprograms. That hasnt changed. But the practices that wereusing have changed materially. So before I just make thesemilestones go away, let me give you some suggestions for newones.How about this; how about each program has a milestone reviewevery 60 days and every 60 days were going to look at thecurrent amount of working code, the current defect count, thecurrent feedback from the customers and the current plans fordistributing that piece or how its doing if its already distributed.Get their mind around assessing the actual use of the product or Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  18. 18. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsactually looking at the application rather than looking at theirintermediate artifacts that we used to create, the code was allbeing done in parallel before we couldnt really run much of it. Allwe had were these artifacts.The code was so hard to change we had to try and get therequirements right so one of those artifacts was our softwarespecification. Well we dont do that anymore. We do havesoftware requirements. Theyre called user storage andacceptance criteria but we write them just in time.We work from thee against division. We want to make sure eventhough it can seem fairly pointed some times and sometimes thePMO has looked at the mother-ship of all impediments, I dontlook at it that way. I look at it as one of the elements of theenterprise thats going to be transformed as well. There again,youve got to go in with different tools.They can think Lean, they dont care about a daily stand up orhow a Scrum team works. Thats not part of what they do. Sotaking them, teaching them Scrum its kind of an interestingexperiment but they dont do Scrum. You got to speak in theirterms and thats basically the business economics, how Agile andLean thinking drives business economics and the principles.Again, some of the principles of product development flow that Ilike to lean on Reinertsens work for that they can use to helpimprove the overall enterprise performance.Joe: Its really practicing Lean or re-architecting with flow is thewhole point of it?Dean: Well at the portfolio level, I like to get them thinking inLean terms. Architecture is a different topic entirely. I spend a lotof time with system architects and Ive got to tell you I like thoseguys, but my first trip is usually a bit of a roast. If you sit downwith 25 or 50 or 75 system architects and start talking about Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  19. 19. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsAgile, youre not generally in front of a friendly audience. Theyveread about Agile and design emergence and theyve looked atScrum. There are no architects in Scrum and they wonder aboutthat model and they think its ludicrous that in an enterprise theirsize theyre adopting this small team model and these systemarchitectures are going to magically occur.But after the first hour or two of roasting, if I can get them to sitstill long enough to look at Slide #3 and start talking about theway architecture has to evolve, they need to be Agile too. Wedont have the option for building that perfect system or weregoing to stop and make a branch and in 36 months were going tolaunch this new application suite. More generally, we have tore-factor what we have.At the system level, I call that "re-architecting." That requirestaking the big architectural initiatives and breaking it up intosmaller chunks, and as we do that, those smaller chunks has tobe able to deliver immediate value.You cant define a system that says until the tenth chunk works,none of it has value, youve got to design the system in such away that you can roll in architecture incrementally. I had thegreat fortune to hook up with a company that was in theirprobably third or fourth year of an Agile enterprise.They werent huge, they were about 300 developers or so, andthere were only six or eight system architects, but they weresharp, and they were trying to re-engage with their Agileenterprise.We worked together and developed a conceptually simple Kanbansystem, basically just a little state management system that said"Where do our ideas come from? How do we get them and howdo we rank them by economic value? How do we get the teams toestimate them without doing a work breakdown structure?" Andthe answer is relative estimating. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  20. 20. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsThen if we get something that makes the cut, and we go to ourbusiness owners and we say that we are going to make thisinvestment in architecture, how do we bust it up in small enoughpieces that the programs that are operating on a cadence canalways have a potentially shippable increment.Thats new thinking. Its different. You may have working processlimits. You may be talking to them about controlling the amountof that work that goes out onto the floor because the more of thatyoure doing in a time box the less potential end user value youcould be delivering in that same time box because youre playingin some new infrastructure.So they need to be Agile too, but again, its not Scrum for them,generally, or XP because there are certainly principles there. Butcontinue to say that integration isnt a part of their model andwhile peer review is, peer programming isnt.So again, I think a Lean approach and a Kanban-like approach,they resonate with immediately. So when I talk to architects, Italk to them about Kanban and I talk to them about a poll-basedsystem that says "OK when are the teams ready for a new bite,and when are you guys ready for a new bite from the businessbacklog."Joe: For me to understand the enterprise system is it fair to saythats where this architecture here is turning management andwhat they want into what to do?Dean: Absolutely. If you look at the role of the system architectsin the large enterprise, there are lots of inputs; some of these arebasically big business initiatives. So lets just say an acquisition,let me just make that case. So an enterprise acquires a couple ofother enterprises. Thats the way that most enterprises get big,make no mistake about it. Well, all of a sudden the rules aredifferent. Now Ive got two or three business units operatinglargely on their own and Ive got to stitch all of that together. I Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  21. 21. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsneed maybe a single sign on, or common authentication model,or I need to not force large scale DBMS on my client when theybuy my suite of products.So the challenges that they face arent just things that just kindof grow bottom up from what the teams are doing, theyre thingsthat come top down. There are also things that need to happen,for example, maybe just cost. Maybe our deployed applicationsystem is costing too much or its too slow, so this whole bigsystem that 300 people built is operating at a third the speed itneeds to. Well, what one team can improve that? None. What oneprogram can improve that? Well it has to be improved in chunks.So they have that responsibility.Theres also a governance responsibility. One enterprise I know isdealing with credit card compliance. The security officers came inand they said, "Well, we have this new compliance module forcredit card processing", and it affected most of the back officesystems. Well, thats not an organic thing, thats a top downthing. Its foisted onto teams by external forces.So I believe that system architects play a legitimate role not onlyin design of the enterprise level architecture, but in security andgovernance, and that got to be an empowered role in theenterprise but it still has to be Agile.You cant do it the old way either. You cant basically shove theserequirements onto the team and detailed specifications or givethem all the how to do it, and say its going to work this way andthen stand back and hold the teams accountable for delivering itthat way. The teams are accountable for delivering the work, sothere has to be collaboration, there has to be an agreement. Inthe end, its the teams that have to be on board with thosedecisions because theyre the people that write the code.One of the simple principles that I like to use is the teams thatcode the system design the system and Ive gotten into a couple Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  22. 22. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsof good discussions with enterprise architects, and they argueabout that. In the end, Ill kind of look at them and say, "Wellobviously you dont feel that youre part of the team that codesthe system.Why is that? "Well its because Im on the third floor, whatever,and I work with system architects rather than teams." I say,"Well, it seems like to really be Agile, were going to have to getyou guys working together a little tighter." So a small vignette inthe middle there to kind of describe the fact that, A, thosebarriers tend to exist and, B, we cant leave them in place if wewant to be effective as an Agile enterprise.Joe: Well theres one interesting thing that you brought in thebook and it really struck me, is that youre one of the few authorsIve seen that have really combined Scrum and Kanban in thebook together. Because they seem...Dean: Theres a method at work.Joe: Are they really compatible methodologies?Dean: Well Scrum and Kanban are fundamentally different, andI try to avoid the "method" words but you cant entirely. Nowafter a number of years of trying, were very effective in scalingScrum in the larger enterprises. I know how to do that. It has aplan basis. It has a time box, which is great because time boxeshelp control the addition of unplanned work. Because it has aplan basis, you can extend that plan basis to the enterprise andyou can execute larger scale planning events that plan in spirits.I believe that we have some very effective models for that. Iveseen Kanban work quite well too. Ive not personally seen it workat very large scale. If you see a large group of people doingKanban, its typically a couple or three teams that have the abilityto work together and pull from a common backlog and potentiallyhave a daily stand up. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  23. 23. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsI do see Kanban work well. I see it working well in IT, I see itworking well in maintenance, I see it working well wherevertheres a very transactional basis to the business and indeed Iintroduce Kanban, I introduce it in the portfolio and I introduce itat system architecture.I dont personally introduce it at the team level, because Scrum ismore mature and has some things like stronger senses ofestimating, user stories, all of which can be done in Kanban, butdont necessarily come with the freight, backlog estimating,planning and time boxes, and commitments to deliverables intime boxes.Maybe Im an old fashioned manager, but I think its meaningfulto ask a team what they can do in a time box, not to tell thembut to ask them, and to commit to that. To put the wholeenterprise under the onus of saying we plan and we make smallcommitments, and those around us can do that and Kanban isvery effective and extremely efficient, but it doesnt always bringthose same attributes.Now, that doesnt put me as not a fan of Kanban, it just says thatin my view and in my world I use it with respect and to goodeffect in certain instances, but Ive not seen it applied over athousand developers building a common thing. There may come atime where it is applied.Ive seen some pretty silly stuff. Ive heard Kabaners said theelephant in the room of Scrum is dead. And Ive heard Scrumsay, "Were not going to talk about Kanban because we dontthink it works and it violates some of our key principles." Well, Ithink we need to talk about both of those things, but we need tokeep them in perspective. I think they both provide value.Im also sorry. You didnt mention XP in there, Im sorry thatthere is less emphasis now in XP than there used to be, because Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  24. 24. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsif you think about Scrum and Kanban both, none of them reallyput any emphasis on how the code is written.If you want to get a team to do a better job of adhering to codingstandards, or collective ownership or developing T-skills or havinghigher fidelity code, that map to acceptance criteria that theydetermine in advance, thats XP. So all of these things can worktogether, and if youre at the enterprise level, its probably kind offoolish to think that any one of those things alone is your rightanswer because those are all really sets of Agile practices thathave to be integrated.That of course creates a challenge, and I try to address some ofthat challenge by bringing the various aspects of that into mybook, so that people could see how XP-like practices work in thecontext of Scrum, how Scrum can scale, and how around incertain places in particular, architecture portfolio, maintenance,etc., Kanban may be a better choice for you.Joe: I think you did an excellent job of that, Dean. When I readthe reviews of the book, one of the most mentioned things thatyou introduced was the "Agile Release Train." What is that?Dean: Let me just give you by parable, actually by story and notparable in this case. One of my contacts, clients, approached meone time and he said, "You know, Ive got 13 Agile teams and Ireally like these guys. Theyve adopted Scrum and a little bit ofXP and their velocity is going up." He said, "I tell you, its the 12teams. Ive got the 12 tribes of Israel here. I dont know how tobring them together into a common vision anymore." As you getinto the enterprise level, you typically find that there are lots ofdevelopers, three, four, five hundred, five thousand, and theywork together in large groups, and those groups have tocoordinate their activities.If you roll out just Scrum, for example, theyre going tend tomake a strong team, but that strong team has some borders Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  25. 25. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsaround it, which is my backlog, my commitment, etc, etc, andyour backlog and your commitment are a lot less relevant to methan perhaps even than they used to be because Ive now got myown objectives.So the "Agile Release Train" is a construct whereby we take largegroups of teams that need to collaborate, typically on a singleasset. Sometimes they just need to collaborate because theyreall the resources.So they may not be working on a single asset, a single programor applications, but they may be all the resources we have in aparticular department. So we bring them together. We basicallytake a fractal. The teams individually have a known model. Itscalled "plan, commit, execute, demo and retrospect," in twoweeks. Well we do that, lets just say for the sake of argument,eight weeks, and we have 10 teams plan together, committogether, execute together, demo together and have aretrospective together.So from the standpoint of the enterprise theyre not thinkinganymore about those 12 teams, theyre thinking about a singleactual program. Also, if an enterprise is just heading down thatpath, its not hard to get them all together. Get 50 or 100 peoplein the room; train them all at the same time in Scrum orwhatever your particular variant is.Then have a release planning session all at the same time andplan for sprints, not just one. Theyll still go away and plan andexecute one sprint at a time. But basically its a fractal above theteam, and its an actually program and it has to behave just likean actual team does: plan, commit, execute, demo andretrospect. That basically gives you an organizational unit whichis not necessarily a business unit or a product or product line, itsa value stream, and it gives you a governance model. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  26. 26. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsWho is going to run the train, or who is going to at least get theteams together. What metrics are we going to use to measure thetrain? How are we going to feed them content? That is basically amodel of aligning the teams to a common mission, periodically,and putting that team or that program or that value stream incontinuous product development flow.Once you make a decision that were in Business A for a while, Ishouldnt have to do a project charter to get a new piece ofcontent approved. I should just take that to the train and saywere going to make this investment, you guys pick which piecesof content make the most sense, and thats within your control.It eliminates a lot of the project-like thinking and all of thestarting and stopping and just says were in this business for awhile, boys and girls, so lets plan together and execute together.So, its a team of teams. An Agile program is a team of teamsoperating on a common cadence. Not necessarily a commonrelease schedule, they may release independently, but a commonplanning cadence and a common demo cadence and a commonretrospective cadence.Joe: Does this really get rid of project management? Are youjust having teams talking to teams and theres not someoneorchestrating it all?Dean: No, it doesnt get rid of project management. In contraryto some beliefs, some of my best friends in implementing Agile atscale are project and program managers. Their roles change, forsure, especially at the program level. Theyre no longer just kindof program portfolio managers where theyre moving contentaround and giving teams tasks and assignments, they becomelarge scale program facilitators, but running a release train isessentially a program management function. Theres atremendous amount of logistics involved in getting the traintogether. The train does not run itself. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  27. 27. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsThe train consists of people from lots of different teams anddepartments. There will be product managers from the productmanagement group, marketing. There will be program managersor sorry operations people, developers and testers. Those maycome from a lot of different department. You think about it Its alarge continuous cross department operation.Send me a good software project manager, program managerand we can make that work. Without it, youve got a couple ofVPs meeting and going, wheres the room? Who do we invite?How do we drive content because that comes from marketing?They are largely self-organizing, but theyre not self-led.Self-organization at the enterprise level only goes so far, and asexecutives, we need to have some, I guess, what the newproduct development game we call has control over that.At the team level you may not have a project manager per team,but four or five teams might have a hard time getting theequipment they need or support from the field or feedback fromcustomers or whatever. If project managers get Agile, theybecome the glue chips that hold it all together.There are also, of course, old-fashioned project managers andprogram managers that are heretical and dictatorial. They dontwork in the model, but I think if you eliminate projectmanagement approach, program management is a function in thelarge scale enterprise. Youre going to end up putting a lot of thatback later, but kind of like architects you need it, but you dontneed like you had it before.Thats just another kind of domain of people that we need to haveon board. Many will make the cut. Many will get it. Many willresist because that was their control and that was their valueadded was to tell teams what to do. We dont do that anymore.We put teams in a situation where they can do the right thing,and the content authorities, whoever it is that determines what Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  28. 28. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsthe right product compliment is, which typically comes frommarketing or product management. They give the teams thecontent of what needs to be delivered. The teams are organizedin an Agile way, but nobody tells the teams what to do. Theyfigure that out for themselves. Thats what makes an Agile teaman Agile team.Joe: So, theyre really supplying the what or what to do or whatfor.Dean: Right. Theyre facilitating a process of getting the whatwhich comes typically from product management or the businessowners or whatever in front of the teams that do the how, right?Theres a little bit of organizational work on the what becausegetting the portfolio working and getting content fed to the teamsat release planning boundaries or PSI planning boundaries,potentially shipping increment boundaries, thats real work, too.That program manager doesnt determine the what. That has tocome from the product group or the business owners. Theprogram manager facilitates the process, so they create a processwhereby the what is put in front of the teams who do the how,and they do that forever. So, theres always a new what, and theteams do the how. Thats where the teams get empowered onboth sides.When you make the translation that says, the program managersalso do the what and because they manage programs, they tellthe teams the how. Well, you do have a point of control, but youalso have a point of micro management, and you have peopletelling people to do the what that arent actually developers andarent involved in the what. So, that part of the model is noteffective.Having said that, leave me some project and program managersif you want to execute Agile on an enterprise scale becauseyoure really going to be hurting without them. In many of the Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  29. 29. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsAgile working groups Im working with, the strongest people Ihave, the people that are really driving the organization areproject or program managers that might even work for the PMOwho totally get it. Theyre the ones that are driving the hardest toput this new model into place.I have a lot of empathy for those who understand the model. Ihave less empathy for those whose needs are more for control.As one of my mentors once told me on one project that wasstruggling, he said, you know, I think the executives need forcontrol there is greater than their need for results. Thats tough.Give me people with the need for results, and well create amodel where the teams are in control of their own destiny.Joe: I think thats one of the problems of extending Agile, letssay, out of software because you hear all of these terms, likeself-managing, self-directing, and its foreign to the productmanagers and people at the enterprise level. Its real foreign tothem, and it causes issues with them. Its not like they want tojump into that fray.Dean: Think about it. Put yourself in there. Lets just say yourea VP of a company, a VP of development, and you control maybethree or 400 people in an enterprise that has 1,000, and wepresent them with a model that says this is all going toself-organize and self-manage. It seems ludicrous to them, right?How is that going to work? And it rarely does work. It has to beled, and its a facilitated process, right? Its a led process wherethe teams largely do self-organize, and the programs organizethemselves, but they dont do it totally independently. Therelease trains dont just form themselves. You have to say no,heres a place where this is a great place to bring these peopletogether. The people in release trains dont even have theauthority to fly themselves to meet, and whos going to put theagenda together? Whos going to create the schedule? We need Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  30. 30. Business901 Podcast TranscriptionImplementing Lean Marketing Systemsthose leaders, and thats why you started with number five. Weregoing to be no leader than the executive, so we need the peoplethat have brought our enterprise to this level, but just like weneed the development teams, we need them different than weused to have them. We dont need to hand them SRSs. We needto give them vision and feature sets and now create the SRSs.We dont need to tell every person what to do or every team whatfeature theyre working on. They can do some self-selecting. Theycan do some volunteering. They can draft features, but we areresponsible for creating an enterprise organization and processmodel that allows that to happen, and thats still the executivesresponsibility.As leaders and managers, its great to go Agile, but were notabrogating our responsibility as fiduciaries of the enterprise.Weve got to know what theyre doing, and we need to know howtheyre doing it, and we need to know how well theyre doing atit. But thats different than saying were personally making allthat work happen.Joe: When we get back to the very basics where we startedfrom, Agile requirements, forming them and creating them isreally what makes it scalable.Dean: The content flows through requirements, and as Ivedescribed in the book theres different levels of content. If you goto the portfolio level, it should go back to those executives.Theyre talking about six or eight really large scale businessinitiatives. Well, those arent user stories. Those are investmentteams. Thats the way they want to spend their money. And then,they say, OK, one of the things we need to do is we need to getsingle sign on across all these things. Well, thats an architecturalepic. So, its true that I can express it as a user story, but its amuch bigger thing than that. So, I think of it as either bottom upor top down. Bottom up, teams work with stories. Programs work Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  31. 31. Business901 Podcast TranscriptionImplementing Lean Marketing Systemswith features because features deliver real value, features andbenefits. Every product managers been taught that from dayone.Above that, we have to think about that at the architecture andportfolio level, the epics. And above that, we have to makeconscious decisions about how were going to spend our money,and those are the investment teams. So, theyre allrequirements. Theyre all forms of requirement, right? Its arequirement that we spend this much money in this domain.Weve made a requirement that says were going to implementsingle sign on across these five teams.Now, that becomes a requirement for number A to implementsingle sign on the same way all the other teams did it because wedont want to support ten different models, and below that somenumber of teams are going to end up with a bunch of stories thatsay, OK, as a user I can log into this and access this otherapplication, so theyre going to get user stories out of that.Its a hierarchy that works at different levels of abstraction sothat each organization gets to think about the business the waythey naturally think about the business. Portfolio managers dontthink in terms of user stories, and teams dont think in terms ofinvestment teams. Thats fine. Theyre paid for different things.This slight separation of concerns actually works for us. We justhave to give them a language to talk about it, and Agile with juststories or maybe just stories and epics and no non-functionalrequirements or features or investment teams isnt quite richenough at the enterprise level. Now, at the small team level, thesmall program level it absolutely is, but thats not where I work. Iwork where 300 is a small number not a big number.Joe: Would you like to add anything that maybe I didnt askabout, the keys to building this enterprise? Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  32. 32. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsDean: If you understand Agile and you understand theenterprise and you think about these five things, youll probablyget it. Theyre not separate initiatives although there are placeswhere starting a release train is one type of activity and gettingthe teams trained in Agile another, its all part of the gestalt thatit takes to really lean this thing out. You dont have to do them allat the same time. You can start bottom up because you canthave a Lean enterprise if the teams cant build working softwarein a time box. I dont think theres anything wrong with a bottomup approach, getting as many teams Agile as we can, as quicklyas we can, but as soon as you have five or 10 or 20 of themstarting to push back on the system, youve got to have abroader view. Youve got to abstract up a notch. Look at theenterprise. Look at the needs of all the key stakeholders in theenterprise and have Lean and Agile answers for all of them.Joe: Could you sum up the top three challenges that youregoing to face going about this process?Dean: Well, I think in terms of lessons learned, theres three orfour kind of weak spots in there, if you will, that we think about,and one is that the Scrum brings this product owner role whichpeople go, OK, this is a product owner and they manage thebacklog. Thats a really big deal because that also is a person thatmakes decisions on behalf of the enterprise. Theyre typicallyengineering. Theyre often in engineering rather than productmanagement, so thats a bit of a power shift or power struggle.That is one case absolutely where lesson learned is its prettyeasy to under estimate the impact and importance of that roleand the training thats required. Another lesson learned is thisisnt just Scrum or Scrum and Kanban or Scrum and Kanban andAgile portfolio management. The teams as part of Agile need tolearn to write better code. The cleaner their code is, the fasterthey go. If the system is Lean, the higher the quality, the fasterthey go. If the system isnt Lean, in order to get high quality, Ihave to test more at the end, and that slows things down. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  33. 33. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsSo, Id say bullet number one is Agile is basically the role of theproduct owner is key. Bullet number two is these technicalpractices actually matter; therefore, if youre rolling out justScrum, youve got to be thinking about TDD and collectiveownership and pair-programming or, at least, peer review. A lotof people only rolled out Scrum because pair-programming wastoo difficult a cultural thing to implement, and in year three andfour they start selectively pairing because theyre diving intoareas of code that theyre uncomfortable with or they went toincrease the code quality. Thats the second element.The third element is probably what I mentioned before. Itsinadequate to hope that the executives simply understand whatwere doing, right? Its inadequate to hope that they support thatwere doing. Its adequate and only adequate if they lead anddrive what were doing. Thats where I like to spend my time, ishelping those executives regain the control.To a certain extent, they have to be in control of their destinyeven though this is a largely self-organizing process, but getthem in a position where theyre driving the behaviors that drivethe Lean Agile enterprise. Even though its not like what it wasbefore, its not through their spreadsheet of allocations, and itsnot through their individual productivity measures, and its notthrough micro managing the teams. Its through driving vision tolarge programs. Theyre still in control of their destiny, and Ithink they need to be.Joe: I think its interesting the way you put that because it is thekind of change that were seeing created in a lot of organizations.From a marketing standpoint, I talk about co-creation andcollaboration with the customers and everything in a servicedominant type society. Youre driving the value in use, and thatswhat youre trying to do as manager. The value is not in theresource allocation, its in use in the development side of it. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  34. 34. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsThat is happening, and thats the same thing thats happening inthe exterior of the company. Yesterday I looked to buy someprinter cartridges, and I could buy a printer cheaper than I couldbuy the cartridges for my old printer. I really debated about it. Iwas giving up a few things. It goes back to that value in use, andyou charge for the value in use. You charge for the printercartridges. I think the organization -- that may not be a fairanalogy -- but its whats happening. The value is in thedevelopment. Its not in the organization any more. Its whatscoming out of it.Dean: Exactly. Our customers dont buy code from us, and theydont buy tests from us, and they dont buy architectural designsfrom us. They buy value so that managers role is solely tofacilitate value to delivery, and our model to facilitating valuedelivery is different now. It used to be, understand it, write itdown, and instruct teams to do it. Well, that worked at one levelof complexity. Now, its heres the vision. Value is very much inthe details, and value is going to be determined by our customerin using this stuff in real time, over time at a high level ofspecificity. So, whats the best way to organize for continuousvalue delivery, and I know Lean and Agile give us better answersthan we had before. They wont be the end answer any morethan any of our other answers over the last few decades were theend answer, but theyre where we are today. Its the tip provisionof our best thinking. Its the best we have, and it works betterthan anything else weve been doing, and thats why its gettingsuch great adoption is because it gets results.Joe: Ive enjoyed the conversation tremendously. I think thereare a lot of great things you do. I recommend the "Agile SoftwareRequirements" book for a lot of people to take a look at andshare it even outside just the software community. I think theresa lot to be said for that to take a deeper dive in the way thingsare going. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  35. 35. Business901 Podcast TranscriptionImplementing Lean Marketing SystemsHow can someone get a hold of you?Dean: Deanleffingwell@Gmail.com or just go toscalingsoftwareagility.wordPress.com. My blog is there. You cancontact me through there. Im pretty easy. Google me. You cantmiss me.Joe: Well, I want to thank you very much, and this podcast willbe available in the Business901 website and also the Business901iTunes store. So, thanks again, Dean. Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901
  36. 36. Business901 Podcast TranscriptionImplementing Lean Marketing Systems Joseph T. Dager Lean Six Sigma Black Belt Ph: 260-438-0411 Fax: 260-818-2022 Email: jtdager@business901.com Web/Blog: http://www.business901.com Twitter: @business901 What others say: In the past 20 years, Joe and I have collaborated on many difficult issues. Joes ability to combine his expertise with "out of the box" thinking is unsurpassed. He has always delivered quickly, cost effectively and withingenuity. A brilliant mind that is always a pleasure to work with." James R.Joe Dager is President of Business901, a progressive company providingdirection in areas such as Lean Marketing, Product Marketing, ProductLaunches and Re-Launches. As a Lean Six Sigma Black Belt,Business901 provides and implements marketing, project and performanceplanning methodologies in small businesses. The simplicity of a singleflexible model will create clarity for your staff and as a result betterexecution. My goal is to allow you spend your time on the need versus theplan.An example of how we may work: Business901 could start with aconsulting style utilizing an individual from your organization or a virtualassistance that is well versed in our principles. We have capabilities toplug virtually any marketing function into your process immediately. Asproficiencies develop, Business901 moves into a coach’s role supporting theprocess as needed. The goal of implementing a system is that the processeswill become a habit and not an event. Business901 Podcast Opportunity Expert Status Lean Agile Software Train, part 1 Lean Agile Software Train, Part 2 Copyright Business901