Basically I am a second generation programmer who has been in this field for quite some time. I got started in the late eighties working on Wall Street, building systems, and I started Industrial Logic in January 1996, basically got the name from thinking about industrial like magic and how could we bring that to the software development field. So, Industrial Logic has been running since then and we are specialists in Extreme Programming and a little bit of Agile project management. So, we help customers around the world get better at writing software, designing it, planning it, delivering it, that's our focus.
2. Can you tell us a little bit more about the Industrial Logic?
Yes, Industrial Logic is focused on three things basically these days: coaching, we coach organizations, project communities in Agile software development. So, we tend to do extreme programming, we do something we call Industrial XP which is a blend of Agile project management and Extreme Programming that we sort of spearheaded back in 2003, we do coaching in that. We help companies adopt it, we do readiness assessments, where we assess companies to see if they can go Agile, and if so what kind of Agile they can do, what blend of practices will be useful to them. That's our coaching practice.
We do lots of training as well; we focus very hard on making excellent trainings, so that people really get a good bang for their buck. Our training is in extreme programming, it's in test driven development, it's in design patterns, it's in user stories, it's in Agile project management these days, we've got trainings in retrospective and chartering, all the things that people study to be good at Agile we teach. Our teachers tend to be practitioners, who are out there doing real work on real Agile projects, so they have lots of good stories to tell and lots of real experience. The third component of our company is e-learning and that's a new thing. We have been building e-learning for Agile software development so that we can teach Agile software development using our e-learning, and we build our own e-learning so we can practice Agile development in our own shop.
So we walk the Agile talk. The e-learning is helping to scale Agility faster, helping us help our clients adopt agility, adopt Agile software development faster than we could do it before, because now we can parallelize the knowledge transfer across the world. So that's essentially what Industrial Logic does.
3. Can you tell us more about the readiness assessment?
Yes, the readiness assessment is something we learnt to do back around 2001. We had been working with a bank, a large conglomerate bank in San Francisco, the San Francisco office called us in for some help. And we went in there and we did a rather naïve readiness assessment we just asked a few questions, one of which is can we do extreme programming, can we train the people and so forth. And they said yes to all of our questions, we went in and we discovered that this particular organization department was not at all ready to be doing Agile.
The enterprise database group was unwilling to make any database changes, except for a three week turnaround time which is not Agile at all. The version control department would lock down the version control so you couldn't even check in codes, no continuous integration, in other words, to make a long story short, we discovered that we had not done our job in assessing this client prior to saying we could help them to see if they were capable of doing Agile. So readiness assessment since then 2001 had become a core part of our practice.
When we work with clients we do a readiness assessment, we do a lot more of interviews, so, we set up a serried of interviews with their people, at different levels: executive level, the management level, customers, developers, testers, anyone who is remotely involved in a possible project or possible transition to Agile we'll talk to, and we get a feel for whether or not they think they can be successful. If they can be successful then we think maybe we can help them and then we'll suggest a path forward. So that's our readiness assessment.
4. And why don't you tell us more about Industrial XP?
Industrial XP came about 2003 after several years of us doing extreme programming, in large organizations. We found that XP was great, however all the upstream stuff, dealing with management, dealing with scope of the project, that was not being dealt with very well. So we decided we needed to bring in new practices and essentially what we did without knowing it was bring in Agile project management. Later, a few years later I was conferring and working with Jim Highsmith, and it turned out a lot of work that he was doing in Agile project management really fit beautifully with what we had done in industrial XP.
So we made Industrial XP turned out to be twenty three practices all devoted to management, customers and developers. It was a little different from XP at the time because it was more cutting edge XP, the latest greatest XP that we had evolved to based upon lots of learning. For example it contains something called story test driven development which back then was relatively new, and I was saying instead of doing unit tests first actually start with an acceptance test first, do as we call it, a story test, story test driven, begin that way.
That was a small innovation we did, that seamed to catch on years later by lots of people around the world. Domain Driven Design, a concept of Eric Evans, that we brought into IXP, and several other practices, and we officially made retrospective part of IXP because we think they are so important, they weren't an official practice in extreme programming and chartering, a huge very important practice that ... three spearheaded, and that is all about figuring out what are the criteria for success of an Agile project. In other words let's be test centric about the project in itself, how do we know if the project is successful; well chartering is a way to not only put some tests around the project success itself, but also figure out what is this thing we are trying to build and is it important anyway for this organization. So that is IXP in a nutshell.
5. So what is the difference between Scrum and Industrial XP?
Scrum I think is more focused on the management side of the practices, so we have elements in industrial XP that are absolutely providing all the things that Scrum provides. It's just that we do it differently and it's been more of a organic growth for this in industrial XP. We basically were doing XP evolved to some Agile project management practices based upon some of our senior coaches that we know, senior consultants that we know, conferring with them, and learning that there are certain things that we could be doing, such as assessment such as chartering and so forth. So that became how we approached this side of the equation, the management side.
I don't think that there is anything wrong with Scrum but we never had a need for it, so when we do our work we don't find that we need Scrum, we find that we need to do chartering, we need to do assessments, we need to do what we call test driven management, these are the things that we developed in IXP that work well for us. So we never actually even been promoting IXP, we thought that IXP is something that we give to the world, through our website industrialxp.org, and if people want to do some of these things they do them.
But we haven't had books about it, we haven't promoted it heavily, it's just something that we find our clients get a lot of use out of it. So, Scrum is gaining a lot of popularity, our approach is very different from Scrum, our approach of industrial XP is called "whole enchilada" agility. We say "Let's approach this from the point of view of", we really do need for the most part technical practices, customer practices, management practices, and most companies we worked with need all of those from the start. That doesn't mean that we are macho people and we have to do everything and no one else can do it, not at all. It basically means that we can evolve and start with some set of these practices across all layers: programmer, customer, manager and begin with an organic whole and evolve it.
But we are not just going to do management practices and forget the technical practices. We are not going to do just customer practices and no management or programmer practices. Industrial XP tends to say "Let's begin with a whole Agile". And it will get more sophisticated over time as the adopters can take on more and more, that's the approach. So Scrum is often combined with extreme programming, and I think it's a pretty good combination. Industrial XP is all of that plus more, it's looking at the customer's practices that we found to be the very best, it's looking at the best technical XP practices, and the best management practices we can come up with.
Yes we have always felt that industrial XP is a set of practices and approach to values that anyone can just pick up. So you don't have to pick up the entire thing. For example we have iterative usability as a practice. We find iterative usability is absolutely critical for making sure that we evolve a product that customers want. So not every client of ours is ready for that, so we may leave iterative usability of the table. In other words if you do a good readiness assessment, and you start to look at the different practice in industrial XP and you start to se how they help a client, and see how they help this project or that project, you can come up with your list of what practices would work well.
Again we would suggest you pay attention to the technical side, the customer side and the management side, and pick some practices from each, but you don't have to do them all, it's really more like a mini framework of Agile practices that people can use. The approach to values is important. Ken Schwaber did say something that I liked a lot, in Italy at a conference there on XP he said "The values are more important than the practices". And that was great because the values are extremely important. So in IXP we say "We don't know what your values are. We don't know what another project's values are.
Let's figure out our values, let's do a little activity and figure out what our values are". Do those values, column down to five, no more than five, got to fit on one hand, we figure out do those values fit with this Agile process that we are coming up with? Is there a fit there? And if so then let's use those Agile values to guide our decision making, to guide our collaboration, we post the values visibly on big posters so people can see them, or if it is a distributed team we make them visible in other ways. But the values are very important. So, Kent Beck later on in the second edition of Extreme Programming started to produce principles. And the principles are very, very, important because the principles are designed to help you almost create your own practices. And I think you can do that with principles, you can do that also with values.
If you value feedback, then you are going to look for all sorts of ways to get feedback, whether it's feedback on your product, usability testing, or feedback from your tests or feedback from people you are talking to, feedback should be an important value. So the values are very important and we say in IXP "Design them yourself, come up with your own values". And on one shop we went to, one of their values was pride. And we said "Pride? That's interesting", and they said "Yes, you know Joshua for many years now we have not been proud of our software, and not been proud of the work we are doing, and we want to be proud of it. So pride is one of our values". And I said "That is fantastic", and we all agreed and pride was one of the five values.
A few weeks later I walked into the open space where they were working and I talked to a woman who was working on a task. She was trying to make something process faster, some software processing in about three minutes, she wanted to get it to process in one minute, her customers wanted to process it in one minute. So she had succeeded in that and typically when you finish a task, when you have succeeded at a task you check it off, so you go up to the white board or you go up to the poster, online if it's an online tool, check and say "I am done with that task". So I said to this woman: "So why haven't you checked it since you got it running in under sixty seconds?", and she said "Well I am not proud of it yet, I am going to work a little bit more and I think I can get it even faster".
So that's great. I came back a couple of hours later after lunch and she had it running in fourteen seconds. And she was very happy, checked it in and said she was done with the task, the customer was very happy, so that's an example where a value - pride - guided her decision making. Like I say, the values have to be in sync with the other values. So had she worked for two days to make it work in fourteen seconds, that probably would have not gone so well with the customers, because the customer wouldn't want her to be wasting all that time just on making it that much faster, but a couple of hours, no problem, it was a good day for her and for the Agile values.
7. Why are you focusing on e-learning?
We started to focus on e-learning a couple pf years ago, we were working with a group in Boston, large group, we got five hundred people in the development organization and they wanted to do what I call a "Broad brush stroke approach" to agility, they wanted to get everyone into this subset of programmer, customer and management practices. We did this work with Jim Highsmith, and basically the trouble we ran into was scheduling training classes, scheduling kick offs, basically knowledge transfer of that many people.
We are only a few of us who are experts in this, how can we get our knowledge transferred effectively into hundreds of people? So we did our best and ultimately their CTO was quite satisfied with our work, but we walked away thinking we probably be a lot better if we had some e-learning. That is if we could take a portion of our knowledge and productize it so that anyone at any time of day 24/7 could access it, that we have a better way to leverage ourselves, that we have a better way to spread the knowledge around. So it is interactive e-learning that we focused on. And we now own our second generation version of this e-learning, we built it ourselves, and we have videos and drag and drop quizzes and labs that you can download and all sorts of things to keep people very engaged.
Feedback mechanisms to ask questions, and the approach is now we are going to an organization and we say "Ok, we are going to begin with some training, and if you have folks in India, North Carolina and New Hampshire, no problem. We all have them doing the training at the same time and then we'll come in and we'll work in person with whoever we can and continue the coaching process". But training more and more we are getting that to be e-learning, some of it we still do in person, but we like the ability to do that cross the globe thing anyone can access it and learn.
8. Can you tell us about story test driven development?
Story test driven development? Yes sure. Story test driven development came about when in 2001-2002 we were doing a lot of projects where we were doing unit test driven development, in other words known as test driven development. And we were expecting the customers to produce acceptance tests, and what was happening was as iterations would come to an end, a lot of times the customers hadn't have time to create the acceptance tests, of course we try to work with them but they are always busy, there is only something happening so as a result, we had plenty of unit tests, but we have not that many acceptance tests, and they started to lag behind. And I found it quite annoying because bugs would start to develop as we misunderstood the requirements in the user story.
A few years later we started to say "Let's do something about this. We have to solve this problem, we can't just keep having this problem again and again". So we started to say what would happen if instead of writing a unit test first, we also wrote an acceptance test first. We worked with the customer to produce an executable test of a feature, of a user story. We started to call that "a story test". And we said "Let's do story test driven development, let's see if on a project we don't write a line of code without first producing a story failing test". And at the very same time Ward Cunningham was working on his FIT, Framework for Integrating Test, so that was great because we started to use FIT to do this, and it was a great fit.
And we helped numerous clients approach development this way. So that they would write a failing story test first and then developers would go and write unit tests first so it changed the rhythm of the development, so instead of it being just rhythm of test driven development it started to be more like a failing story test, failing micro tests, failing story test, failing micro tests, a different rhythm was brought to this and we found that it gave better coverage, better understanding of requirements, better collaboration between customers and programmers and sometimes even management and it even turned out to help with distributed development, because when we had people in Toronto collaborating with some folks in Australia, we can send them failing story tests, and based on those failing story tests they did the right thing.
They wrote the right code and it was a clear specification. So I went back and saw that Tom DiMarco had mentioned this in the early eighties he said "If we could only write these little mini specifications instead of these giant ones, things would be a lot better". And story tests are just like that, they are little mini specifications that are executable, so they call them executable specifications. And they function really well to communicate what a customer wants. So we are big believers in that we even do it in our own e-learning, we do story testing with Selenium and a template engine that we have woven together with it and we also do traditional TDD of course, the two go hand in hand, it's not like one supplants the other, you'll do story test driven development and then go into test driven development.
We haven't written a book on story test driven development yet, but we are hoping to produce some e-learning at some point, few other authors have threatened to write something on this and I hope that they did but they never actually finished. Someday we will have some good writing on this. Of course Rick Mugridge in his book on FIT, Rick's and Ward's book talks about a little bit not in great detail, but it is a very, very, powerful and important practice, that's very helpful to people.
9. What are your three favorite IT books?
My three favorite IT books: the first one is Jerry Weinberg "The Secrets of Consulting", it's an absolute classic, it's been around for more than twenty five years now. I think it's still selling well. I lived and breathed that book in my early days twelve years ago when I started this company, and it's a fantastic book. Wonderful book, even for people who work within organizations, who are acting mostly as internal coachers or consultants, a very important book to read, great stories, funny, lots of wisdom, just try this book.
Second book would be "Design Patterns" that really changed me quite a bit, I will never forget coming back from a vacation in Greece and went to the bookstore to browse around and I wasn't expecting to buy anything that day but all of a sudden I hit "Design Patters" and fifty dollars later I was walking around in Central Park in New York City and I couldn't believe this book, it was amazing, so I went crazy. I started a study group on the book and I had people meeting in Soho New York every week and we would discussed every chapter and we became almost like biblical scholars of that book and you should see my copy today it's turned to shreds but I loved that book, it's a tremendous thing that the Gang of Four did, just changed our industry and it elevated my abilities as an object oriented programmer quite a bit, so fantastic book.
Third one would have to be Kent Beck's "Extreme Programming" that was the next huge thing that affected me. Extreme Programming is just a phenomenal way to approach software development, it makes it an art, and I always felt more like an artist than a business man or anything else and I think I am definitely a combination thereof, but I like the art of software development I like the challenge of crafting software, of meeting market needs, of meeting customer needs and not doing too much work, writing quality code, writing tests, Kent along with Ward Cunningham, Martin Fowler, and the other people that early on started this whole movement, Ron Jeffries of course, it really hit a cord and basically Industrial Logic business 1997-1998 starting to completely turn into this approach of Extreme Programming so this is big, this is bigger than even patterns, this is process stuff, this affects everyone and it's really cool, it really works and that's a mind shift in how you program.
Big shift, I mean I went from structured programming in the '80s to object oriented programming in the '90s and that was a pretty big shift, very big shift on consciousness. The shift to Extreme Programming from objects was as big, test driven development, I write a test before I write some code, very strange. The whole approach to user stories and iterations, really significant contribution Kent made in writing his book and of course Ward Cunningham, and the others who contributed to his ideas.