Future of Work: Transcript of Interview with Ron Lichty, Agile Expert

Interview was conducted on May 29th, 2012 and recorded in the lobby of the Courtyard Hotel. The write up was done at Starbucks in the Presidio, San Francisco, California.

May 30, 2012

 

Host:               Welcome to the Human 1.0 Future of Work series, hosted by Scott K. Wilder, digital strategist and founding partner of Human 1.0.  Today’s call is with Ron Lichty, a consultant focusing on product and software development.  Ron has been managing product and software development teams in organizations for over 20 years.  He is the author of Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, due out from Addison-Wesley in September 2012.

 

Scott K. Wilder:  Hi, there.  Nation, this is Scott K. Wilder, and today I’m with Ron Lichty, and we’re going to be talking about managing the unmanageable.  That’s the title of Ron’s and and his co-author, Mickey Mantle—not the Mickey Mantle the baseball player— new book that is due out  some time in the early fall: Managing the Unmanageable:  Rules, Tools, and Insights for Managing Software People and Teams. Ron, great to have you with us today.

 

Ron Lichty:     Hi, Scott.

 

Scott K. Wilder:  Ron, I want to jump right into the discussion and hear a little bit about your journey in terms of your work experiences and non-work experiences. I think it’s important what kind of career decisions people have made, and how that’s impacted, you know, where they are today.

Ron Lichty:     I’ve had two careers, one of them in journalism and authoring, and the other one in programming and managing programmers.  It’s probably helpful, however, to first talk about where I came from.  So, I grew up on a – I was born onto a 1,000-acre farm in Iowa.

 

Scott K. Wilder:  Sounds like this is going to be about Field of Dreams.

 

Ron Lichty:     Actually, not very far from there (where it was filmed) About an hour from there.  And that’s important for two reasons.  First, as I look back on it, one, farmers are more independent people than programmers are; but they also form together into communities in which they share best practices with each other.

 

And secondly, my Dad was an early adopter of emerging technology in farming.  He was an early adopter of contour farming.  (Contour plowing (or contour ploughing) or contour farming is the farming practice of plowing across a slope following its elevation contour lines.). He was an early adopter of terracing—in Iowa.  Huge equipment coming out and moving dirt around, and creating ways to save soil.

 

But, I was also born an engineer.  I just didn’t know it yet, until I was in about the 4th grade and started building electronics projects, and discovered that my brain is wired that way.  And I kept building more and more sophisticated things, and discovered that you had to debug them sometimes.  And had – was very clear that my path was going to be electronics engineering—until I hit the end of high school and suddenly discovered people.  And discovered, as a senior in high school, that in all of the clubs I was in, they were electing me to run the club

 

As a result, I discovered this competing people side (of my personality). And I went off to college and started in Electrical Engineering, and went through a real journey of investigating political science and social (activities)  And was a – I actually spent a year in a volunteer program as a social worker.  And in that time, I started a magazine, and discovered you needed to know something about writing and graphic design, and I taught myself about those kinds of things. And transitioned again into – and transitioned out of social work, which I discovered was really hard.  But transitioned into something that I really loved, which was writing, and writing English, and I was a journalist for about ten years, freelancing in New York.

 

I ran a newspaper syndicate in New York.  I – of community magazines.  I wrote my first book there, on starting a community magazine or newspaper, all before – this was pre-computer kind of journalism.  I was a newspaper reporter/photographer in Wyoming.  And I came to California to finish my second book, a book called 132 Ways to Earn a Living Without Working (For Someone Else)

 

Scott K. Wilder:  {Laughter}.

 

Ron Lichty:     …and freelanced here and actually bought an early personal computer—what was called then a microcomputer—to use as a word processor.  And discovered you could program this thing.  And it started all of my nerd neurons firing, and I taught myself to program in the course of just a few months.

 

Scott K. Wilder:  What type of computer was it?

 

Ron Lichty:     It was a Southwest Tech 6800 microcomputer with 20K of RAM, a high-speed cassette deck for storage, and a small – I think it was a Panasonic television for a monitor.  Portable televisions, as they were called in those days.  And this thing – I mean, it was a total kluge of a system, but it was totally investigatable from a nerd standpoint.  And I began figuring out how to program it, and I taught myself to program first in BASIC and then in assembly language.  And then I just changed careers.  I went looking for a job, and got a job in a two-person consulting company, writing compiler code generators, and word processing software, and embedded microcontroller stuff.  So, I’ve got – while I was there I got three patents on hotel locking systems, and algorithms for storing postage transactions for smart card-based postage meter – smart cards, the credit cards with a chip on them, that at the time were being used mostly in France for phone…

 

Scott K. Wilder:  That’s right, the French were reall innovators in this area

 

Ron Lichty:     For payphones.  We were using them.  We created a postage meter system for our client that used the same for storing postage transactions.  And you could – instead of carrying this whole postage meter to the post office, you could carry a card to the post office to get a refill.

 

And then – and I wrote two books on assembly language programming in the course of that time, both of which were about the chip that Apple was putting in one of its leading-edge computers, which was the last of the Apple II line actually.  The Apple IIGS.  Which was the first Macintosh in color was an Apple II.

 

Scott K. Wilder:  You were an early Apple pioneer

 

Ron Lichty:     It had the Macintosh interface and it was in color.  And I had written the chip for it, and the result was that our little consulting company got selected by Apple to write the sales demo program that demo’d – this computer demo’d itself, with animation, and sound, and graphics, and wonderful stuff.

 

Scott K. Wilder:  What year was this?

 

Ron Lichty:     So, this was around 1986 when the Apple IIGS came out.  And two years later, then, my co-author had gone to Apple.  Convinced me to come to Apple in a product management role for the first time.  I had taught authors how to promote and publicize their books at this point, and new graphic design.

 

So, I explored product management for the first time in a role at Apple doing product management for development tools, about which I knew almost more than anybody else in the world at that point—about those tools.  So, I went to Apple in a management role.  It was managing product managers, so it was my first management role.  My first product management role; my first large technology company role.  And I stayed at Apple for about seven years, and ended up – I left product management.  I wanted to work with engineers.  I became an engineer.  They kept making me a manager.  I’d become an engineer again and they’d make me a manager again.

 

And eventually I accepted that.  I accepted that with some amount of real pleasure, for the breadth that you get as a manager versus the depth you get as a programmer; but felt the loss of – as a programmer, you finish something, and that moment when it works is a real jump-up-and-down-with-joy kind of moment.  Because you have climbed into a microprocessor and listened to its gates open and close, and gotten them to open and close the way you wanted them to do.  And that’s something very special.  So, it was that – so, I did that transition at Apple, and I ended up managing the UI, the secret jewels at Apple—the team that developed the Macintosh Finder.  I managed that team for three years.

 

And then I got my – an offer to be – for my first director of engineering role, to go to Berkeley Systems, which had the most used entertainment software in the world at the time.  And I got to manage development of it—After Dark and other screensavers.  Almost every PC and almost every Macintosh that was issued had After Dark or one of its – one of Berkeley Systems’ screensavers running on it.

 

And then – and when I left there, I interviewed with the guy who became my co-author a decade later, Mickey Mantle.  If – you know, if VPEs were as famous as baseball players, you wouldn’t have to say Mickey Mantle wasn’t the ball player.

 

Scott K. Wilder:  {Laughter}.

 

Ron Lichty:     This is the Mickey Mantle who’s not the ball player.  Because, between the two of us, we were managing entertainment and home and personal software, that was used by probably, you know, a vast majority of the people in the country—in the world, actually.  On Apple IIs and Macintoshes and IBM PCs.  And so, I interviewed with him, but I ended up going to Fujitsu to do online animated virtual world.  So, I stayed in the entertainment world for a bit longer.  I was there for about a year, and turned around the product, and got it out the door for Fujitsu, and then went to a small tools company that competed with Macromedia, called (M Factor), and was there for not quite a year, working on those tools.

 

And then I got out of the entertainment business and I went to Schwab, in financial services, which was doing – which was changing from the ‘everything’s a mainframe to provide software to our employees, to customers—real people, our customers, millions of customers—have direct access to our systems’.  And they had done web trading but it was all HTML, and they needed something that was rich for investor tools.  And the richness was a choice in those days of either (Microsoft com), dotcom, (sounds like: its com) toolset, or Java.  And Schwab had chosen Java, and I got to manage the teams doing the first investor tools in Java on schwab.com.

 

I stayed at Schwab for about six years.  The second half of that was to move all of Schwab – was a – I took on one of the CIO᾽s initiatives to move all of Schwab to a single common platform and way of doing software, which we succeeded in, with the exception of the mainframe.  So, all of the distributed – all of the desktop software was on a single platform within three years.  So, it was a – and it was all the business units.  It was across the board.  It was a really exciting thing to do and to get to do.  And it got me promoted to vice president of Schwab, and it got – I won the CIO᾽s Technologist of the Year Award.

 

And then after six years there, in 2002, I left and worked at a series of startups and consulting roles in medium to large-sized companies since then.  Though, Stanford would be considered a fairly large company. But it was a fairly medium-sized enterprise of Stanford᾽s that I was most recently working in.  So, I’ve been managing software development for about – not quite 25 years.  And most of that time, with the exception of Apple, which was fairly well-run, remarkably – with the exception of Apple, I’ve been untangling software – knots in software development, almost that whole time.  And so, that’s what the book is about, is Managing The Unmanageable, is figuring out how to be successful in software development, whether it’s IT or whether it’s a product.

 

Scott K. Wilder:  Yes.  I want to get to your book, and you just hit on one of my questions.  So, tell me a little bit about the book, how it came about, and then – and untangling the unmanageable.  What are some – you know, just a few stories or few key things that you highlight in the book, that would be really important takeaways for people?

 

Ron Lichty:     So, the book came about because I called after I took the job at Fujitsu and said, you know, that was a really interesting interview that you did with me.  How about if we have breakfast?  And we started – and that was exploratory, and we both enjoyed it, and we started having breakfast every two or three months for the course of the next, I don’t know, five or seven or eight years or something like that.  I had written four books at this point.  I’d sworn off writing books after I’d had a write-600-pages-in-six-months death march to get one done.  And – but I’ve got a drive to write books, to – it helps me to think, in part; and I like being an author, and I like being a published actual; and I writing.  I like having written.  I like writing.

 

Scott K. Wilder:  You have a drive to write and share your experiences

 

Ron Lichty:     As I was starting to think about it, and it turned out that Mickey had been thinking about writing a book for quite a long time.  And we both sort of realized that – I’ve – of my four books, I’ve co-authored three of them, and now four of five.  We proposed writing a book together on managing software development – managing software developers and managing software development teams, partly because we’d been trading rules of thumbs and nuggets of wisdom over breakfast all this time.  So – and I wrote down a few – you know, the obvious one of Fred Brooks, “Adding manpower to a late software project makes it later.”  You know, it’s the kind of thing that you don’t come up with on your own, but when you think about it, you say, you know, I need that to express to my management – to express to my management team.  They need to understand that software development is not obvious, and that there are some rules of thumb in how it works.

 

Scott K. Wilder:  And Fred Brooks’ book, is that The Mythical

 

Ron Lichty:     The Mythical Man-Month, which is an absolute classic.  It’s a classic on project management.  So, one of the things that we realized, is – Mickey and I realized, as we were looking at things, is, there are a ton of books in project management, of which Fred Brooks᾽ book was probably not the first, but it’s the enduring one of the first.  There are a ton of books in managing teams and managing organizations, but there are almost no books on managing programmers and managing programming teams.  And in fact, programmers are different, as IBM realized when they did their SuperBowl commercial on herding cats, and they had cowboys on horses herding huge herds of cats across the prairie.

 

Mickey and I had both been programmers. We had both achieved some pretty decent stuff as programmers.  We qualify – you know, I – we resembled this remark. We qualified for having nerd genes and being – probably having been difficult to manage when we were programmers.  And we – and so, we understood it from that standpoint, but we also understood it from the – having managed – you know, between the two of us, we’ve managed now for almost 60 years, between the two of us.

 

 

There’s this notion that programming is engineering.  Right?  So, the notion of – the word engineering – there’s a Scientific American article from the ’90s that reports that the word engineering was applied to programming on the 25th anniversary of programming, when a bunch of the leading programming got together and said, you know, this stuff doesn’t work.  Programming isn’t effective.  The processes don’t work.  Then – maybe if we call it engineering instead of programming, it’ll work; and maybe if we apply engineering techniques to it, we can get it there.

 

Because that article was written well after the 25th anniversary, in the ’90s, to report that calling it engineering didn’t make it work any better.  So, this was after the Denver Airport debacle for all the luggage, you know, being destroyed on the – and all that stuff.  It was after there was a satellite debacle.  It was sent into space with the wrong – with the – I think it was the metric English thing.  But there was one of those – so, one of the satellite things had totally failed.

 

Scott K. Wilder:  I just heard a really interesting story that this triggered, is that – so, when Disney set up Disneyland in France, one of the assumptions they made was that people eat lunch like in the States.  They eat at different times.  But in France, you eat at the same time.  So, it was a nightmare in terms of planning.

 

Ron Lichty:     Yes, Lets look at another one of those. I think it was either the IRS or one of the major government – maybe the FBI.  One of the major government agencies had spent millions and millions and then abandoned the project, for inability to get it done.

 

In engineering, you build the same thing over and over again.  It may be slightly different.  You know, we’ve just built a new Bay Bridge that has only got one pillar, and it’s got a suspension off of one pillar, and a fairly new idea.  But it’s an evolution of two-pillar suspension bridges.  The bridge isn’t any bigger or any longer than the thing that was built in the 1930s. Bridges haven’t really evolves sicne then. Now, there are some evolutionary things you need to learn about bridges.  The Tacoma Narrows Bridge fell down in the 1960s – 1950s, maybe, because they didn’t know enough about aerodynamics.  But overall, bridges don’t change that much.

 

Software changes all the time.  And in fact, software – you could say – okay, so, we’re now building it in C++ instead of in assembly language, or we’re now building with C++ modules instead of building from C++ statements.  Great; but the size of what we’re building is even larger than the components are larger than the statements.  The growth of the size of the things we’re building is enormous.  And it outstrips all attempts to make it an engineering kind of thing.

 

Programmers are craftspeople. What it takes to be a good programmer is this combination mind of engineering and craftsperson—of being able to pull order out of chaos in your mind.  It’s as related – one of the things you see in programmers is that a whole lot of really good programmers are also musicians.  And the mentality that it takes to be a musician and the mentality it takes to be a programmer are very similar.  And I don’t think you see that same across-the-board connection between musician and any other kind of engineering.  It’s because it’s a craft, not just engineering.  So, why is it harder?  Because we keep building bigger and greater and heavier-duty things, and the – we keep improving our processes, but they don’t keep up.

 

Scott K. Wilder:  Maybe from a code perspective, what were some of the – and I’m thinking very layman, in terms of number of lines of code that you were working with Apple versus, say, what people are working with today, and where it’s going?  I’m just trying to get a sense of…

 

Ron Lichty:     You know, I don’t keep track of numbers, so I can’t – yes, I can’t give you numbers on it.  But it’s – but, you know, you look at a – so, the space shuttle – not the space; the one before that.  Gemini.  The one that went to the moon.

 

Scott K. Wilder:  Apollo.

 

Ron Lichty:     Apollo 13 went to the moon and back.  And they were using slide rules.  You – go watch the movie  (referring the Tom Hanks Apollo 13 movie). They were using slide rules.  You know, we all knew that, but it revealed it to everyone else.  They were using slide rules to get those guys back.  And what you put into a satellite today is not a slide rule.  And that’s how many – what is that, two decades?

 

Scott K. Wilder:  But I remember my brother in 1970, ’71, going to high school with a slide rule.

 

Ron Lichty:     Right.  Yes, and I went to college with a slide rule.  Absolutely.  I was really proud of having a really great slide – in fact, I’ve still got it somewhere.  Did my taxes on it one year.

 

Scott K. Wilder:  Lets ge back to the book – so, what are some key takeaways from the book?

 

Ron Lichty:     So, one of the key takeaways is just a collection of rules of thumb and nuggets of wisdom.  Between we really – we went out to our networks, and the stuff that we read, and the stuff that we’d collected, and the stuff we’d exchanged, and put the best of those into the book, so that other managers of programming teams and other managers of programmers could use them too.

 

The other takeaways are it’s rules, tools and insights.  Rules are this whole section of rules and nuggets of wisdom.  The tools – we’ve shared the tools that we’ve used.  You know, everything from, you know, interviewing spreadsheets and forms and templates, to managing project management.  So, the – basically, the Word and Excel and PDF documents that we developed for our own use, and that we’ve gathered from other programming managers, to share.  And then we realized we could write a short amount of, you know, the insights that we’ve had as managers, and that turned into nine chapters.

 

But it’s – ranges from insights into who programmers are, and that’s what we’ve just been talking about—that they’re not engineers; and they’re not salespeople, certainly, which is a great deal of what the organizations they’re in are made up of, and we’re trying to figure them out; they’re not artists, and yet they share a mind with artists; they’re something different.  So, who they are?

 

And then, how do you recruit them?  How do you hire them?  How do you ensure they show up for the first day after you’ve hired them and they’ve said yes?  What do you do with them the first day?  How do you incorporate them into your team and ensure the shortest possible path to their becoming an integral part of the team that they – that you’ve hired them for?  How do you build a culture for your programming organization?  How do you motivate your organization?  And then, how do you – you know, and then the nuts and bolts of, you know, how do you manage down, how do you manage out, how do you manage up, how do you manage externally, and how do you manage projects?

 

Scott K. Wilder:  Got it.  So, if I was launching a software – if I was launching a company and I need to hire folks, what – how should I think about this?  You know, what kind of framework should I – trying to get a sense.  If I was starting today and I was building a team from scratch, and that means, like, what are some of the questions I should ask, in terms of hiring folks, and how they fit in with the rest of the organization?

 

Ron Lichty:     So, the first question is finding a VP of engineering to hire those folks; not, you hire those folks.  And the questions that I think you look for in a VP of engineering is, you – so, there’s – this is a bigger question than the next two hours.

 

Scott K. Wilder:  Yes.

 

Ron Lichty:     But you want to look at somebody who understands that management of programming organizations is not micromanagement.  It is not managing down.  That you need to be – you need to think about turning your organization upside-down, and that the VP of engineering is supporting – it’s not the pyramid from the top; it’s the pyramid from the bottom.  The VP of engineering is supporting his directors—his or her directors—and the directors are supporting their managers, and they’re supporting their teams.  And you’re trying to create teams that are self-motivated, self-running, self-aware, highly collaborative, and transcend the – just the individual skills of the individuals, to work so well together that they do something that’s greater than any – than you would think, just adding them together.

 

Scott K. Wilder:  Let me ask you a question. If I’m looking at designing a product or adding features how should think about ROI and how should I share this info with programmers or my engineering team.

 

Ron Lichty:     Yes.  So, it’s really important – from a motivational standpoint; strong developers are doing software development because they want to make a difference in the world.  And so, it’s really important for them to understand why the company’s mission and its purpose is about making a difference in the world, and how they fit in that.  The – how the contribution they make, makes a difference to the company making a difference.

 

You know, it was one of the great things of working at Apple, walking into this culture that Steve Jobs had created.  And it wasn’t originally – the purpose wasn’t originally, we’re going to change the world through computers.  It was, we’re going to change the world.  It didn’t have the “through computers” part on the end of that.  And everybody inside of Apple believed that.  And everybody – there – took me six months out of Apple to realize that there was an undercurrent of ruthlessness at Apple, which probably also came from Steve.  But it took six months to realize that, because we were all so bought into changing the world, and into the mission, that we were intensely motivated to accomplish that.

 

Scott K. Wilder:  Some of the discussions that I get into in companies is, you really want this feature; you know, what’s going to be the return on investment in this feature?  And maybe that’s not the right way to frame things.  But the few times I’ve managed an engineering team or developers, that’s the question that’s come up is, you know, here are the list of priorities.  How’s it going to affect the bottom line?

 

Ron Lichty:     So, I think this begins to get into the whole Agile and the nature of Agile, and how – and filters out into how the whole – how whole companies will change.  And some of them have already.  One of them is – so, when you’re selecting a VP of engineering to hire the rest of – to hire the development team, you’re looking for somebody who can collaborate with the product side, and who can collaborate with the head of product management or the head of products, or whoever the visionary is.  Because there’s – there are things that are seen in the development side – there are opportunities that developers realize on the team that – you know, I could make this change and you could have that feature, in half an hour.

 

That may be – what you need is a communication between to the VP of engineering and his team the head of products. almost simultaneously, so that the head of products can make a decision about, okay, that’s a half-hour, and I don’t care.  Or, that’s a half-hour.  I didn’t know about that.  Take it.  Do it.  Because that half-hour will be a week, a month from now.  Because the programmer’s not in that area of code, is not able to – you know, doesn’t remember it, doesn’t see it, doesn’t connect with it in the same way.  It’s – there’s an immediacy of opportunity that happens there.

 

Vice versa, the head of products needs to share the vision, in a way, and needs to be engaged in prioritization, in a way that’s really good businesses do, but most businesses don’t.  It’s difficult to find people who don’t say, “Well, I want everything;” but who will say, “This is the most important thing.”

 

Scott K. Wilder:  Their eyes are bigger than their stomach.

 

Ron Lichty:     It’s – you know, all of our eyes are bigger than our stomach.  The question is, which do you eat first?  And it’s – and when you’re making decisions about products, there are ROIs to be done, and net present values to be calculated, and understanding of the marketplace that has to be made in order to say, “This is the most important thing right now.“”  It’s hard work.  The – one of the books that I read as a technical reviewer was Software by Numbers.  Mark – I mentioned it earlier—Mark Denne and what’s her name, Cleland-Huang’s book, that provides a framework, an analytical framework on the product side, that’s a match for the analytical framework that needs to be done on the engineering side, and is typically – and typically is done on the engineering side.

 

Scott K. Wilder:  Can you just give me an example what that might look like?

 

Ron Lichty:     It divides products into minimal marketable features and says, how are we going to do all the stuff we want to do, and then make a list of all the things that make a difference to customers.  Then you can do an ROI or Net Present Value on them (each feature). We can look at the difference of releasing a product in two months vs. eight months vs. 16 months. So one quesiton is can we beat the competition

We need to be able to do those kinds of discussions. You need to be able to examine the issue from a product side.  It’s one of the product management responsibilities to map out the competition and map out the product, and understand where the value lies.

 

Scott K. Wilder: We were talking about that book, and then some – an example of how to measure, what’s the analytic – an example of an analytic framework, or how to think about it.

 

But you talked about Agile, and I want to kind of focus on Agile for a few minutes.  Can you just highlight some of the key principles of Agile?  And then, if I heard you correctly, there’s some companies who are doing a good job in that space, and then other companies are not really using Agile, and what you think the opportunities are for companies to adopt that approach—that philosophy?

 

Ron Lichty:     So, Agile is, at the highest level, a philosophy.  For example, there’s an Agile Manifesto.  It’s online at, you know, agilemanifesto.com or something like that.  And there’s both the manifesto, which is four weightings, and there’s a set of principles.  So, the weightings are individuals’ interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.  It says, not that you don’t do the less weighted things, but that valuing customer collaboration is way higher than negotiating over how something should be done.  That having a conversation about things is way better than written documentation.

 

Agile was a term that got applied to a whole set of approaches to software development in the ’90s, when the gurus of all of those approaches got together and said, you know, we’ve got more in common than we have different.  And where the commonality comes together is this philosophy, and this set of philosophies.  And they drafted those four comparisons and the principles at that point, and they’re stuck.

—————- XXXXX

Some approaches (or key terms) have remained constant, such as XP or extreme programming, which Kent Beck came up with, I think at Chrysler, when he was consultant there; Scrum, which Jeff Sutherland came, is another key term. Two other key terms are Lean and Kanban.  All of Agile sort of draws from Lean, and Lean is the manufacturing process that Toyota – that Deming – Earnest Deming?  What’s Demming’s first name?

 

Scott K. Wilder:  W. Edewards Deming. I was actually a student of his

 

Ron Lichty:     Really. Wow. So, Deming taught Toyota how to – it was about – Lean was about eliminating waste, and about engaging everyone on the manufacturing floor in ensuring quality.  And a lot – in a lot of ways Agile draws from Lean. So, there’s a version of Lean called Kanban that is used – it’s spelled K-A-N-B-A-N.  And it’s coming into fairly – a fair amount of use at this point, sometimes with Scrum; sometimes replacing Scrum; sometimes instead of Scrum.  And both of them tend to use extreme programming at least some of the – so, extreme programming is really a set of engineering practices.  Scrum is described as a framework, although you’ll talk to some people who’ll say, no it’s not.  So, there’s arguments over what it is.

 

But it – in some ways it’s a process.  But it says, we’re going to decide on a sprint length.  We’re going to decide that we’re going to release something every few weeks of this project.  And every few weeks we’re going to give you something that is deliverable quality, and you’re going to decide—you, being the business—is going to decide whether to release that to customers or not.  But we’ve given you what we think you asked for, for that short period of time—for that iteration; that sprint.  We’re going to give you something that we think that – you know, and we’re going to do our best to understand what it is you want about just that—just this thing we’re going to deliver in three weeks.  And then we’re going to deliver it in three weeks, and then we’re going to look at – and we’re going to give you the opportunity to say, here are my priorities for the next three weeks.

 

I’ve talked to a lot of development groups.  Two years ago when I was consulting, it was – I gave a talk—you probably spotted that one on SlideShare.  The – Transforming Chaos to Clarity.

 

Scott K. Wilder:  Yes.

 

Ron Lichty:     And, you know, one of the things I would do was to ask developers and project managers and QA people, how many people have worked from a 400-page set of requirements?  Almost every hand in the room goes up.  And then I ask, what percentage of those requirements did you actually deliver?  The numbers I get back, with one exception, which is NASA; they had a couple of people from NASA who’ve delivered close to 100% of the requirements, which was a set of requirements that were really well done to start with; that really understood, this is what it takes to get to the moon, or to Mars, to Venus, or wherever we’re going.

 

With that exception, where they got close to 95%, the numbers tend to be in 15 to 30%.  15 to 13% of requirements are actually delivered in the product.  What that means is, that 70 to 85% of requirements – so, there’s some product manager who’s slaved, and some business analyst, maybe, who’s slaved over those product requirements—spent four months on them before the development team could even begin working on them.  And 70 to 85% of what they put into those requirements was waste.  And wasted.  And not used.

 

Scott K. Wilder:  So, if you’re not taking, you know, the War and Peace document of requirements, what do developers use?  What do they take – they have these conversations, and then do they develop – do they write up a scenario, or they just – what’s the next step?

 

Ron Lichty:     So, what Agile – and I use the word Agile frequently to mean Scrum, but also frequently Lean – where they tend to work from – where they tend to ask the product side to work from is, give us something that will fit on a 3 x 5 card that’s big enough to see on a wall.  So, it’s not, you know – it’s not five-point type on a 3 x 5 card.  It’s big enough that you can stand back from a wall and be able to read this 3 x 5 card in your script, in handwriting.  Give us a set of features described on 3 x 5 cards—features broken done into tasks.  And you don’t have to describe them any further than that, to describe what it is you’re trying to build, for the whole mass of those.

 

The second step is, what are the highest priority ones of those?  So, prioritize those and tell us, which are the ones that you want to deliver?  Let’s say a sprint is three weeks long.  Which are the ones you want to deliver in the next six – in, like, six weeks?  In the next two sprints.  And flesh out the – you know, what do those requirements mean?  What are the details?  What are the edge cases?  What are the – how would you test it, to know that that feature’s there?  Which is typically written on the back of that card.  In fact, there’s even a process for doing that.

 

What’s most important is less the documentation than the conversation between the product vision – visionary—the product owner, as it’s called in Scrum—and the team.  The product owner is part of the team.  And one of the mantras of Agile is, tear down office walls.  Tear down cube walls, even.  Put everybody who’s on the team in a room without walls, so that they’ve got eyesight contact with each other and can look up and – because there is – there are no requirements that don’t have ambiguities.  That’s almost true.  Mickey and I both came – both identified one case in 20 years of software development, 20-plus years of software development.  We both identified one case where we developed directly from requirements, and they were all there to start with.  And we did the whole thing.  One.

 

Scott K. Wilder:  Just one? This actually triggers an interesting question.  So, you know, one of the things IT’s dealing with, or engineering, are dispersed teams.

 

Ron Lichty:     Yes.  So, it’s actually one of the huge – one of the most interesting things in the last decade has been two competing – two very diametrically opposed trends, one of them Agile, and the other one is distributed teams.  Dispersed teams.  Distributed teams.  And, in every way.  So, in some cases it’s offshore teams.  In some cases it’s teams where every member of the team is in a different city.  In some cases it’s – you know, it’s contractors scattered around.  In some cases it’s the business and the development team are in two different places.  But there’s – in every possible way that you can do a distributed team, it’s been – it’s happened in the last ten years.

 

And so, that’s a huge – it’s a huge challenge.  You know, a couple of our –couple of the gurus who we’ve quoted in the rules of thumb and nuggets of wisdom that we’ve collected, talk about the level of value of having people within eyesight of each other, and that there is no way that a distributed team can be as productive as a team that’s got eyesight contact.  They just can’t.

 

And so, then, that brings across more, how do you add process?  How do you add tools?  How do you add – you know, it’s one of the things that I predict we will see in the coming decade, is some kind of tool – some kind of workplace – some kind of individual workplace tool that identifies when a programmer is in the zone and when a programmer is not.  Because what happens is, a programmer looks up – in a – you know, it – we need to enable the water cooler conversations that happen in teams that are in eyesight contact with each other.  Because the programmer who looks up from having been in the zone and says, I’ve got a question, or I just need to chat, and they will chat about the project with a team member.

 

But in the distributed team, they have no way of knowing that their teammates aren’t in the zone, are they interrupting?  So, they can take them out of the zone.  Which getting a programmer back into the zone is – that’s expensive.  And so, some of them will do it anyway, and take their colleagues out of the zone.  Others of them won’t make – won’t do communication.  And it sucks both ways.  It’s a bad thing.  And so, we need tooling and office spaces that support knowing when your teammates are in the zone or not.

 

Scott K. Wilder:  It’s funny you’re using that terminology.  Maybe that’s the common one, but whenever I have a developer on my team or I’m working with a developer, the first question I ask them is, are you in the zone?  Should I come back later?  You know?  And they love it.  And it helps me a lot too, because I don’t want to throw them off.  And – anyway – so, that raises another question of, is Agile—and I don’t know if you know the answer to this—just more of a North American thing?  Or is it – you know, think about companies that have their developers in Romania and India and…

 

Ron Lichty:     Yes.  So, one of the aspects – and it comes partly from the philosophy, but one of the aspects of Agile is teams – so, it turns management of teams upside down.  The manager who’s been managing a team to do waterfall, and has been directing the team’s activities, will find himself with his hands in his pockets, while scratching his head, trying to figure out what his role is, or her role is.

 

And – because it turns things upside down, because the Agile – so, I’m – the numbers I’m seeing – the percentage – that it’s more anecdotal than data-driven, but it appears to me that well over half of development in the United States, and a great deal of software development around the world, is being done in Agile these days.  In some form, some aspect of Agile.  And what you – what drives that is, comes from two places.  One is from senior management, which says, we know that Agile is going to be more – is going to drive more productivity.  Therefore, let’s do Agile.

 

The other one is grassroots.  The team says, we need to do Agile.  You know, I did Agile at my last company.  Here was the results.  Let’s do Agile here.  And builds it from the team level up.  But in both of those cases, the middle man is – I’m developing a class for – a training for managers right now in how to be the Agile manager.  Because there are certain aspects of things that managers have always done and will continue to do; and there are other things that you need to rethink your role relative to the team.  Your role is to mentor, and to coach, and to remove obstacles, and to – but also to do the things you’ve traditionally done.  To hire, to fire, to build culture—to do all those kinds of things.

 

Scott K. Wilder:  I could ask a thousand questions about what the future office should look like, if you’re trying to get everybody, you know, around the same water cooler.  But I’m going to save that for a follow-up some time.  But one of the things that interests me is, how is Agile evolve when we start dealing with web, mobile apps—whatever comes next after that?  Is it the same principles have carried through, or has there been…?

 

Ron Lichty:     I think it’s solidified the principles.  And it’s solidified the principles because the ability to update software is – the ability to deliver software is – you know, when – you know, 20 years ago we were delivering things on CD-ROMs, and before that on floppy disks.  And you developed and developed and developed and developed; and then, you know, put out the product at the end of four months, or a year, or three years, or whatever it was.  And you were stuck with that – with those bits.  They’d better be right.  And you were done.

 

And these days, you know, even satellites are being updated on the fly with new software.  I’m not sure that cars are.  But there’s an awful lot of embedded software that is updatable on the fly.  Even Coke machines order inventory – you know, this is – they’ve been ordering inventory for 15, 20 years at this point.  They were doing it by modem.  The early ones were doing it by modem 20 years ago.

 

Scott K. Wilder:  So, I was looking at some of your slides, and you have a slide about prioritizing things by business value.

 

Ron Lichty:     Yes.

 

Scott K. Wilder:  And I just wanted to get your thoughts on, how should – what’s some useful ways to think about that?

 

Ron Lichty:     So, yes.  I did a webinar with Greg Cohen, who’s the – who’s one of the gurus over at 280 Group, which is a product management consulting group.  And the – identifying business value’s an interesting – and prioritizing, is an interesting process, because it’s not just product side and it’s not just engineering side.  So, it goes to what I was talking about earlier, of the value that engineering brings to prioritization—the opportunities that developers see, that need to be identified to the business.

 

But there’s also something called technical debt.  So, we should talk about technical debt, because that’s come up in the context of Agile, but it᾽s – regardless of what process you’re using, you’ve probably got technical debt.  It’s writing crufty code…

 

Scott K. Wilder:  Crufty?

 

Ron Lichty:     Crufty! It’s Technical term.  Writing crufty code in order to get the product out, is one of the places technical debt comes up.  You’ve got something to put in, and you’ve got no time left to do it, and you Band-Aid the thing together in order to get it out the door.  That’s technical debt.  And if you let technical debt build up, it’s just like the financial model.  If you allow debt to build up, you’ve got a higher and higher debt that you’ve got to pay back.  And at some point, you won’t get any development done until you’ve paid down your debt.

 

Scott K. Wilder:  Can’t I just print more code in the same way I can print more money?

 

Ron Lichty:     You can try that, and organizations have tried that, and that works to a certain point.  And it works for nations, and it works for code development organizations in the same way.  There comes a time when the pile of debt is so high that you’ve got to bring it down, in order to be successful with your main objective.

 

Scott K. Wilder:  So, any other kind of future trends you see in terms of product development?

 

Ron Lichty:     Well – so, there’s a couple of things that happen across the rest of the business, that I think are really interesting.  The whole Agile movement has happened inside of development and has crossed the line to product managers; a product owner who’s part of the team and sits with the team, and is always available to the team to be able to answer questions, and to be able to spec out this particular feature that we’re working on in this sprint.  And it’s gone up the line to management a little bit—to engineering management, to development management, a little bit.

 

But it really hasn’t crossed the line into the rest of the business very much.  And it has real opportunities for the rest of the business.  If you think about –so, let’s go back to those requirements.  So, those requirements, that 15 to 30% of requirements are actually delivered.  If you think about – you know, so, where᾽s the waste here?  So, a product manager – so, somebody in the business said, we need a product.  The work on the product didn’t begin for four months while the product manager spent four months figuring out how to write 400 pages of requirements.  So, the work didn’t begin for four months.  Then, all of that work happened, and only 15% of the four months actually – or, 15 to 30% of that four months, actually went into the product.  So, that part was wasted.

 

But the whole development cycle can move up.  If all you’re doing is writing down features and identifying the ones that you want to prioritize—if you do that, and you iterate, you could start development in just a couple of weeks, as opposed to waiting four months.  You can start projects way faster.  You can get feedback on whether the team’s on track.

 

So, the other thing that happens in waterfall development, in more typical development, non-iterative development, is, the team gets 400 pages of requirement and they work on it.  And they’re a black box until they’re done.  And then you find out, oh, that wasn’t what we wanted.  So, what you want to find out—what Agile gives you the opportunity to do is, every three weeks, or every two weeks, or however long those sprints are, to find out whether the team’s on track; whether it’s what you want; whether you’ve got the most important things that you desire.

 

So, I did consulting with a startup that, the development team was using – was – said, okay.  So, we’ve got enough requirements here that this will take us six months to build.  And they would get about three weeks down the line, and the sales team would go out and talk to a customer, and come back and say, well, it wasn’t what we wanted.  We wanted something different.  And so, they would change this.

 

And so, if you’re on an Agile – so, I helped transition them to Agile so that they were delivering something every three weeks.  And when you’re doing that, you deliver something in three weeks, and then you don’t care what the business comes back and tells you the next three weeks are about.  You can build anything.  They can take a 270-degree turn, and that’s fine with the development team, and it’s fine with the business.  Because the business will get the highest-priority thing built out of that 270-degree turn in three weeks.  Three weeks after they ask for it.  Or maybe five weeks after they ask for it, because maybe you’re in the middle of a sprint and it takes two weeks to get done with the last thing you asked for.  But then you get – in three weeks, you get the highest thing of the – that you think is most important to you.  And so, you’re constantly iterating on highest-value stuff.

 

You know, I talked a minute ago about how important collaboration is on the product side and the engineering side.  It’s partly because you need to take down technical debt.  You need to identify technical opportunities.  Those come from the engineering side.  And on the product side, you’re constantly evaluating, what’s the highest priority. The technical side’s looking at, what’s the highest risk.  If we do this, what do we have to put in place in order to ensure that we get to there?  And on the product side, you’re saying, what’s the highest risk?  What do we as a company fail at, if we don’t get this feature out?

 

So, you’re matching those things up and constantly reformulating what the highest value is.  And that highest value comes both from customers and from the technical – the technology side.  So, it’s a melding.  It’s collaboration of those two people—those two organizations.  Those two thought modes.

 

Scott K. Wilder:  Fascinating.  I mean, I could even see other parts of the organization impacted.  You know, I think about customer service, that hears the pain first-hand, and can help figure out what the scenarios or the stories are, or the tasks that people are trying to complete and whether – you know, they could pass it on to the product man – product manager or woman—man or woman.  The problem is, it’s kind of like the game, Telephone.  It could get watered down by the time it gets to the engineers.  Any other – sorry, go ahead.

 

Ron Lichty:     So – yes.  So, I started – you know, where᾽s the waste?  And I – you know, the 65 – the 60 to 85%, 70 to 85%, of the requirements that the project manager writes, are waste. The time it takes for the development team to start.  The QA team typically starts writing test cases, and writes test cases for all 100% of the requirements.  That’s a huge waste if you’re only implementing 15 to 30% of the requirements.  Customer service has to figure out the product, and they’re reading this huge thing.  The developers try to understand 400 pages all at once.  It’s an absolute impossibility.

 

I have maybe met – maybe the guy who wrote, or the woman who wrote 400 pages understands everything that’s in there; but I don’t know anyone who understands everything that’s in a 400-page requirements document, and can absolutely deliver to that.  So, everybody in the whole company, in fact, is saddled by that whole process of, create the whole thing.

 

Now, the other thing that happens is, you say, okay, so, we’re not going to deliver anything for a year.  So, therefore, we better put everything in here that we could possibly want.  And so, now it becomes a two-year project.  But you’ve only got a year to deliver it.

 

And what’s the team do?  The team makes decisions about what’s the priority because they don’t know.  Because they’ve been told they have to deliver everything.  So, they deliver on the basis of, what’s the easiest?  What’s the most fun?  What’s the most interesting?  What’s the – you know, and you get those kinds of decisions being made, as opposed to the product owner saying, this is – and the head of engineering saying, this is the most – this is the highest priority.  This is where the highest risks are.  This is what we need to tackle this three weeks.

 

Scott K. Wilder:  Yes.  And I would imagine if you and I were sitting here a year ago, we might not be talking about developing something for a mobile device or a smartphone; where, now, it’s high probability that we would be working on something like that.  Any other trends that – you know, things – or, down the road, where things might evolve?

 

Ron Lichty:     You know, I think Agile is such a big trend.  And it’s right – I think it will transform companies, and transform how companies think about developing products.  You know, you brought up Eric Ries earlier.  The whole Lean startup idea and the minimal marketable feature idea are on the – you know, it’s sort of the minimal marketable product and the minimal marketable feature—they’re in the same ballpark.  You’re looking at, what can I bring to market that will provide value to our customers, and revenue to our company, the most quickly?

 

And it changes the way you think about doing development. Whether it’s a product for external customers or whether it’s a product for internal customers, who can begin getting value from an internal IT kind of internal support software, way faster using an Agile approach, than they would if they waited for the whole, you know, give-me-everything-at-once approach.

 

Scott K. Wilder:  I would imagine that some of your clients go through real cultural transformations when they start looking at this.

 

Ron Lichty:     They do.  And so, it’s interesting to see, over the last ten years – you know, the – I started – you know, my connection with Agile started when I was at Schwab, and I was doing that – the CIO᾽s initiative to move everything to a single platform.  And some of those teams that we were supporting and ensuring would be successful, were using Agile.  And it was – Agile at that point was extreme programming.  And the term, extreme programming, inside of a financial services organization, was not exactly comforting…

 

Scott K. Wilder:  Of course, it was extreme.

 

Ron Lichty:     It was scary for executives to think of a process labeled as ‘extreme.’  And Scrum isn’t a much better name.  And, you know – and I think the naming has been problematic, and it’s probably slowed the change to – you know, Agile itself is probably an outstanding name.  But in fact, people are using Scrum, or they’re using extreme programming, or they’re using Kanban, whatever that – you know, I can tell you what it means, but it’s a Japanese word, and no one who’s American knows it.  And it’s probably slowed the implementation.

 

And yet, the implementation is such that there’s probably – there are very few companies – there are very few large companies that don’t have some of their development going on in Agile today.

 

Scott K. Wilder:  So, say more about that.

 

Ron Lichty:     So, you know, it’s a development team that’s doing it, versus – it hasn’t transformed the culture of the whole company yet.  You know, companies are – many companies are still command and control.  Many companies are still – they haven’t transformed their cultures.  And cultures change from founders and CEOs, not from development teams.  One of the things that we counsel companies on is to make sure that you do not isolate development teams from the rest of the company and to make sure that if engineering is doing something important, embrace it. Leverage the parts of cultures that are valuable, and that are inspiring, etc. Its important to recognize what kind of a culture you’re in, and what kind of a culture you need to build in order to motivate and protect developers from demotivation, basically.

 

Scott K. Wilder:  This is fascinating.  I just – because we’re – we’ve gone – talked for over an hour, and I just want to ask two or three more questions.  Are there certain websites or resources, besides your book, that you would recommend that people look into?  You talked about the Agile Manifesto.  And I know your book’s going to be out, and we’ll do a little plug for that at the end.  But are there user groups?  I know there’s some – there’s one on Yahoo.  I’m just curious if there’s other things that…

 

Ron Lichty:     Yes.  So, you know, I’ve done – I do – I’ve done, and I do, my learning in every way.  So, I attend – so, here in the Bay area I attend a couple of meetups on a very regular basis.  The Agile Leadership Network has local chapters.  We’ve got one here in the Bay area.  We have speakers and workshops every month.

 

Chris Sims, who created an organization called Agile Learning Labs, has a meetup here in the Bay area that I attend.  I’ve, you know, taken classes from some of the really good leaders in – we haven’t talked about test-driven development, which is a very techy way of doing development.  But Rob Myers is, you know, one of the gurus in test-driven development.  Chris Sims has written a book on Agile.  Mike Cohn has written a really good book on transitioning organizations from something else to Agile.

 

There are a couple of free conferences, one for developers and one for product managers, that I try to attend every year.  The developer one is two days on a weekend, and draws thousands of developers to Foothill College every October.  The product manager one draws – I think it was about 1,000 product managers, in April.  I think it was April.  In the spring.

 

You know, I read Joel.  Everybody reads Joel on Software.  I’ve read Marc Andreessen.  You know, I’m part of LinkedIn groups.  I read Dr. – I was just reading something in an old Dr. Dobb’s, but Dr. Dobb’s is embedded online in somebody else’s website now.  You know, ACM.  Better – there’s a magazine called Better Software that puts on a conference every year.  A smattering of trade magazines.  Software by Numbers, which I mentioned earlier—Mark Denne and Cleland-Huang’s book.

 

There are a lot of really good websites, but I’d have to look them all – you know, I’ve actually got a list of them, because I share them with people regularly, and say, go read that stuff.

 

Scott K. Wilder:  Well, maybe when – yes.  Maybe when I do the write-up, we can add some of those.  So, I also like to end these discussions by asking you, what are you – asking people what they’re reading.  And it doesn’t have to be necessarily work-related.  Or – you know, and the last person I spoke to corrected me and said, you should ask me what I’m listening to, because he’s very addicted to NPR, like I am.  So, what are you listening to?  What are you watching?  What are you reading, these days?

 

Ron Lichty:     So, you know, I’m addicted to NPR too.  I listen to Fresh Air whenever I can, and a couple of other shows on NPR.  I just finished reading a book called The River Flows Upward, or something like that.  It’s a book on – a bunch of scientists take a rafting trip down the Colorado River through the Grand Canyon.  And this scientist who wrote the book, uses it as an opportunity to talk about geology, and evolution, and life, and brain cells.  And it’s just a fascinating read.  I read pretty eclectically.

 

Scott K. Wilder:  I see.  So, I’ve been with Ron Lichty.  And Ron, I want to thank you.  This has been really fascinating.  There’s a lot of real nuggets here, in terms of what companies need to think about, moving forward.  Do you want to just give one quick plug for your book, and when it’s coming out?

 

Ron Lichty:     So, the book is Managing the Unmanageable:  Rules, Tools, and Insights for Managing Software People and Teams.  It’s – Addison-Wesley᾽s the publisher.  They tell us it’s coming out in September but they have it up for preorder, so you can order it now on Amazon or on Barnes & Noble.  And, you know, they’ve moved the date a couple of times, so I think September’s probably pretty likely.

 

Scott K. Wilder:  Great.  Okay.  So, we’re going to wrap it up here.  This is Scott Wilder, and we’ve had a discussion today about all sorts of development and programming issues.  This is part of the Future of Work series, that might evolve into the name, to be Digital Ready.  And, want to thank you.

 

THE END

Advertisements