ARCast.net - Getting Agile in Dublin

Announcer: It's Wednesday, June 27th, 2007 and you are watching ARCast TV.

Ron Jacobs: Hey! Welcome back to ARCast TV! Friends, this is your host Ron Jacobs and today we are going to Dublin, Ireland, which is just a beautiful place. I really enjoyed making a stop there where I spoke to the dot Net user group there in Dublin and they just were terrific and welcomed me. Even though the projector kept flipping out and switching off, and that makes it really hard to give a presentation! But nonetheless, I learn a lot when I go out on my trips on the road.

The person we're going to talk to today is Claudio Perrone. Claudio is an architect there in Dublin and just a very smart guy who is talking to me about behavioral driven development. This is a kind of an interesting way of looking at some of the concepts of agile or test driven development. A way that they are being applied, with a slightly different spin. I learned a lot. In fact, I use some of this in my own presentations. So let's go to Dublin.

Ron Jacobs: Hey, this is Ron Jacobs and I'm here in Dublin today where I'm joined by Claudio Perrone.

Claudio Perrone: Perfect!

Ron: Hey! Wow!

Claudio: Yeah! That's great!

Ron: So Claudio, you know I have to say you have a very interesting mix of Italian and Irish accent.

Claudio: Yeah, I know. I'm sorry!

[laughter]

Claudio: I apologize in advance if you can't understand my accent. I've been here in Ireland for seven years.

Ron: Wow!

Claudio: My wife is Irish.

Ron: Oh, Okay.

Claudio: So that... yeah. That's it.

Ron: See, I've noticed there is a tendency of women to kind of drag men all over the world like this, yeah?

Claudio: Yeah, that's what people actually believe, but it is not really true. The economy in Ireland was pretty strong, so...

Ron: Yeah, that's what I've heard. In fact, I was talking to some folks in the U.K.

Claudio: Yeah.

Ron: I was telling them I was coming to Dublin and they said, "Oh my! Things are going just fabulous in Dublin." They are trying to hire some people and said, "We can't find anybody. There are so many jobs and people are working."

Claudio: That's true. Particularly, a lot of American companies came here for the government, actually. They are a lot of help, I guess, to these companies.

Ron: Yeah.

Claudio: So they came over. They really built the economy in the last few years.

Ron: Wow!

Claudio: So I remember living in Italy, they were saying, "Oh, Ireland is the capital of software in all Europe." So that seemed like a good idea to move over.

Ron: Ah! Terrific! Well it's time that I finally got here for ARCast.

[laughter]

If it is happening... I've been to London so many times. I was in the U.K. and I said, " Well, I might as well pop over. It is not very far." So I'm glad that I did.

Tell me about the company you work for.

Claudio: I work for a company called Inner Workings. What we do is a training company for developers, particularly for dot Net developers. It's a kind of an innovative way to train people, because we believe, really you learn by doing. So it's a form of e-learning but is a reactions of the traditional e-learning... we don't think, actually, traditional e-learning worked for developers at all.

Ron: Yeah.

Claudio: So what we do pretty much, we provide you with challenges and the point is that you learn a technology by solving problems, right? By providing small problems we say, "Ok, write the code. Here are the specifications of the problem. You have a few pieces of codes. You have the solution already there. You have the fill the blanks, in a way.

So you solve them and we give immediate feedback there. That's the way, I guess, for learning. If you don't know how to do it, we provide enough references and links. So as it turns out -- you don't know this -- but you know tonight you are going to do a talk, right?

Ron: Yes.

Claudio: On essay patterns. Well the first time I'd seen you, I think it was in Tech Ed, perhaps a couple of years ago?

Ron: Yeah.

Claudio: And you did maybe the first version of it, or at least that's the first version I saw of those patterns, and so we prepared a few challenges. This one that I remember -- again it was still on 2003. Actually we just used 2003 -- it was about moving from a loosey-goosey interface to a document processor.

Ron: [laughs] Oh! That's great! Wow! You know, I completely agree with you that I find it frustrating to go through the traditional type of learning. Or even, recently I decided I was going to spend sometime working with WPF. One of the things I did was to get one of the hands-on labs that we have and work through it.

What I find frustrating about that is the lab tells you exactly what to do: go here, type this, add this, put this code in here. And they don't leave anything to the imagination. They tell you exactly what to do. I'm like a code monkey, just typing these things in. What I found was that at the end of it, I had something that compiled and ran and did something, but I didn't know why it did it. I didn't really understand what the purpose of the different pieces were. I don't think I learned anything really, by doing this.

Claudio: I totally agree with you. There is this limitation where people actually say, "Okay, I'm going to a lab." You really follow like a monkey, step-by-step, what you have to do. But if you are actually presented with a problem and you have to find out, given the documents or the references that we can give you; it is a way to get there, possibly faster that you would go anywhere else.

Sometimes it is good to get a trainer. Even if we go to your talk, that's fine; it's perfect. We learn about patterns and those are really good takeaways. But until we really try to do them, you may lose essentially these kind of learning aspects.

We are trying to reverse that. We say, "Well yes, you might need a trainer. You have a really good perception at the end of a training session." But you know, what most companies do: They send developers around for three days on a training and then they say, "OK, they know everything about us. They can actually go ahead and go develop." We are trying to really change this.

Ron: I think I kind of divide training into two aspects. I want to learn the concepts. Concepts you can pick up from a lecture kind of oriented format. So the kind of presentations I do are oriented around really delivering concepts, and I try to give people analogies or ways to think about things. I talk about an idea that a service is like an international border crossing, as a customs agent and security...

Claudio: A metaphor.

Ron: Yeah! So I try to get them to think like that. But then there is the practical design criteria experience. You know when you take any technology, whether it's workflow, WPF, or anything like this, you can think about the concepts and come up with an idea. But the idea might not work very well, and you won't know it until you actually try to get hands-on there and work with it.

Claudio: That's true. The devil is in the details as well, right?

Ron: Yes.

Claudio: It is like when you hear about... Well, even the document processor -- I remember when the guys actually were working on that, and we were really trying to apply it and we'd start to say: How do we do? Can we really do exceptions? Or, how do we put the error code? Or do we have false errors in the data transfer objects that we pass back? How do we deal with that?

Until you really try coding there are certain questions that essentially don't arise. We really, really try to have to do that in some way.

Ron: Which is why I really like the concept, in sort of agile development, about taking time to do a spike to answer the questions like that. I think many times project managers or management doesn't understand this and they're like, "Why do you need to take time to do that? Just decide what you are going to do and go do it." Unfortunately, if you make the wrong decision, you have to live with that for a long time.

Claudio: Well, that's true. In fact, one of the most mind-changing ways I learned... One of the things I learned by moving from a no merger process to an adjunct process is how, in a way, we adapt to change, and we provide and we stick feedback immediately. That kind of feedback was lost, at least in my previous experiences, which I think in a way is at the heart of the complexity that we put in our software.

This is really something that has been bugging me, and I know a lot of people, like forever... We are still building really, really complex applications, and what can we do about it? And in a way, what I learned is... What I learned about architecture is about managing complexity better, not necessarily to reduce it. You know what I mean? We learn how to separate layers of things, so that we handle complexity by focusing on just a particular area of concern, or security in a particular way, and so on.

We don't really think properly as simplicity as a value of software. It is really something that I got to learn, in a way, really by working in Agile. In an Agile way. Because I see that a lot of people think that Agile developers are just cowboy programmers. There are no rules. Everything is fine. In reality, that is not really true. There are some rules. There are not many rules, but those rules are really followed.

I think certain rules are like the best games. You put just a few rules together, and then the magic happens. They don't have to be complex, right? And in the past, what I realized was that, for example, I was listening to the customers building brighter use cases, fully dressed use cases. Pre-conditions. Post conditions. Specific course of events. The whole thing, right?

And then, from there, you would follow analysis diagrams, design diagrams, and so on. You go with the full process. I realized, "You know what? I'm focusing on the activities of building software, not really the outcome."

So one thing is, thinking about the activities, the actions that actually make you build a software. Of course, you are doing the things that you believe, at that particular point in time, are the right things to do. I did believe, and I still believe, going use cases, and building a lot of diagrams, and so on are still valuable in certain environments, particularly large projects. Low trust environments. You want to give that kind of stance that everything is written down, so we have a contract between the customer and the developer.

However, I learned instead that if we actually change our focus, perhaps, and we start talking in terms of one rule, and the rule is timeboxing, and in fact deliver a lot of Agile practices do use that as a way to essentially build software through iterations. It's not that iterations weren't there before, right? It's always been there. Unified processing.

With that kind of feature, write a feature box in, so essentially decide I'm going to build all these features, and this is the amount of time it's going to take. If it takes more, well, whatever. But, essentially you decide how long it will take to do a particular set of features, and you define the system in that way. Within that iteration, you do all the documents. You create all the assets you need, and so on.

But, with Agile development, there is this kind of, "Well, no. Let's divide that so that we have a two week iteration, depending on teams, and depending on companies, two weeks, maybe better than four weeks or one week or three weeks, but say two weeks."

And within that you customer, tell me what is the most important thing that you want the system do. OK? So in the way, we actually say: "Let's divide into features. Let's not invest so much time into creating a lot of use cases or whatever. Let's see these features and create these so-called stories." And stories are pretty much placeholder for a conversation. OK?

So the stories are very simple, we actually have heard just as an example, this is a little story: The Customer Withdraws Cash. I actually took this as example without shame really from a friend of mine Dan North was the Agile developer again. He's behind actually a kind of a movements or methodology called Behavior Driven Development we can talk about that now, I mean it.

But the essential idea is - This is the story, these are our scenarios, OK? And this story pretty much has got a title like The Customer Withdraws Cash. We are talking about automatic telemachines and then the story is gotten narrative. The point is you write pretty much some information about the story in that index cards. But you will always have people that would say: "Oh, I need to write a lot more."

And they go there and write long sentences. The rule is: If you find yourself writing more that this index card can actually keep, I'll give you smaller index cards. So at least we are sure that you can't go through it, right? [laughter]

So, the point is with this in minds we create a narrative like a small sentence to describe what the story is. And within that, while we use a template essentially which in this case is SA Customer I want to withdraw a cash from ATM. So that I don't have to wait in line, I don't know what to wrote, at the bank. [laughter]

So, in fact there is a little template, that's a role I want to, that's the feature, so that is the business reason why you want to do this. OK? So you create this little template. And in the way the good thing about the story is that is small. OK?

We try really to say: "Our use case is about long features, a lot of stuff but the story has got a constraint and the constraint is: I have to be able, my team has to be able to develop this and maybe other stories within an iteration and the iteration is only two weeks." OK? So in a way this constraint, I love constraints, I love rules, OK? And the point is it's within rules that is creativity has to be on the list.

Ron: May I ask you a question because a lot of people will say: "Oh, my Gosh, two weeks, what if we have to write logging infrastructure and the whole security infrastructure and that's going to take two months before we can produce anything like that." So, how do you deal with that?

Claudio: Well, it depends, OK? Sometimes you can have a zero feature iteration that takes a bit of time you create a bit of that infrastructure and on the top of that you create this vertical slice. Essentially you create a piece of software that does something. Something that can be demonstrated in some way. OK?

So that would be a pretty standard way perhaps to deal with that. You create just a basic infrastructure that you need. In fact when people talk about Agile they say words like: "You don't create architecture, diagrams, you don't create architecture. You just get without, you just start writing code." But that's not really true.

You write the architecture at the time that you need the session, that you know something about it. There are a lot of choices in architecture, actually about nonfunctional requirements - how scalable this has to be and so on. So you can actually get to that type of information before hand.

So if you go to that then you do it. However sometimes you can manage to put stuff within two weeks and that is where the creativity comes about. Just to give an example. Let's say we have... actually this comes from a real story, different company, so, don't talk about inner workings.

Ron: OK.

Claudio: But essentially we are talking about providing on a website a list of popular content. Ok. And so, when you think about popular content, you say, "Well actually, what does popular content means?"

And you talk to the customers. I said the stories are a placeholder for their conversation. Effectively it means I am talking to you. We discuss this. The reason understanding as well, that's whatever you write down on paper can be misinterpreted sometimes. Natural languages are really ambiguous or they can be really ambiguous and that's one of the reasons why computers can't really understand the English immediately and do whatever we ask them to do, OK?

Ron: Yeah.

Claudio: So there is always ambiguity. But if we talk and if we keep talking about this we can have a better understanding essentially of their requirement in the first place. So I can say as a, as a user, as a customer I want to see a list of popular content so that I am motivated to buy it.

So we have my request, the feature that they want, and what is the business reason for that? And I say that from the point of view of the customer, OK? So you go down to the development team, OK, we ask a little bit what happens and so on and the development team says well, OK, we can say, "Well, what is the most downloaded content that would be popular?" Or for example, we could say, "Well, depending on how people rate that content we can maybe do an allegorate in this way." However, all this information is in another service. We can have maybe a web-service, document processor would wrap all this, we get the allegorate, we get the list then whatever website shows that list we'll have that, OK?

The point, you start thinking, OK, we have to do that in a short amount of time. And you think, what is the simplest thing that can possibly work? Because that is the constraint you have. You have two weeks. You can't really think about that. You say, well, how often this content has to be shown on the website? How often it has to be modified in the first place? And you talk to the customer, he says, well more likely is going to be changed, I don't know, maybe once a week. I'd say probably once a month. Well, fair enough.

How about you have a second page instead where you put the list of popular content? You let the customers believe that is popular because you decide it is popular. Let's call it hot. Let's call it whatever. But you just write that list and as it turns out, all these web services and the code that we started thinking that we had to write becomes simpler.

And the other aspect is to say, well, how about we only provide the page that provides that list and you give us a call once a month and you say this is the new list. And we just go and we hack around the table and the system, and we just write our list. OK?

So the point is, you would say, well the system is hacked. Well, not really because on the first estimate you might have to take two full weeks to do it, well let's say a few days to do it. On the second iteration, where we say well actually you have a management page and a display page, you only have just two, three days and with the list only you have maybe one day, OK? And the system is simpler, is incredibly simpler and unless you take simplicity as a main value and you actually don't carefully think in terms of the system to build as it say what is the simplest thing that can possibly build because if their requirement change, we can add that stuff.

However, right now we can use those features or the time that we freed up for building that feature and creating something that is extremely simpler, for maybe creating something else that maybe is more important, and maybe we'd even consider that, OK?

Ron: Yeah. The thing that's interesting about this to me is that as you are talking about this user story, the user wants to see the popular content, I'm thinking, well how do you define popular? That was the first question in my mind and then it occurs to me that if you were dealing with this business who has this, oftentimes they'll say something like that without thinking about how they define popular. They're discerning one popular. And so if the team doesn't really drill into that and start asking with a focus on the simple, they might go do the very complex thing like you said.

Claudio: Yeah.

Ron: Like, oh, we'll build an olab cube that analyzes sales for the last six months and comes up with the most popular things based on sales and this incredibly complicated analysis...

Claudio: Absolutely.

Ron: ...and all that, and then it turns out the customer says, "Oh, well we decided we just decide that in the meeting we have once a week." Or something like that. [laughs]

Claudio: Absolutely. And it happens. It's one of those things and in fact, one thing that I believe is happening and it does happen in many teams, many developers have this. And I realize that when I said I'm focused too much, I'm focusing too much on the activities of building software. You see, we could have the very complex thing. We would have all the beautiful diagrams you would love and but at the end the software probably would meet somewhat the needs of the customer.

However, because I spend so much time on that, I couldn't spend other time maybe on some other very, very important feature. So as a result, we are not providing value as quick as we can. With the idea of saying, well, wait a second, every two weeks we have a demo, for example.

Ron: Yeah. Yeah.

Claudio: OK? That's what we do. It's a small company in our case, so we have about 40 people at the moment. And what we say is, well, at the, at the beginning of each reiteration (sp) we define what the stories have to be. The customer says what is the priority. We talked about pretty much the stories themselves and we try based on this conversation to estimate them. Based on that estimate we say, well, the team can only do so much. And so this is the amount of effort we can put, so these are the amount of stories we can deal. Whichever, we don't care. You tell us which ones. But you just find the priority.

So, what we do is, we send an email to the entire company and we say, well, in two weeks from now on the date blah blah blah, at the time blah blah blah, we are going to have a demo. These are the lists of stories that we are going to provide. The stories pretty much have, again, the title and this kind of narrative as a user I want to sold out, Ok?

Ron: So let me ask you a question then. At the end of two weeks, you have working code...

Claudio: Yep.

Ron: ...it's ready to go...

Claudio: Fully tested. Yep.

Ron: ...and so then, is the idea then that if a customer looks at it and says, "I like it, " it's ready to put into production that day.

Claudio: Well, in theory, yes. Practically, what happens is the customer will decide which iteration we want to release.

Ron: OK.

Claudio: Because sometime effectively you don't have enough to provide value outside the company but you still want to prove your, to show progress. So you show the progress at each iteration and it has to be a feasible progress in many ways.

Ron: Yeah.

Claudio: OK. However, the customer will decide, well at this point we have enough features so that we can go live.

Ron: Ok. Because that would be the other question you have is that, OK, the customer picks four user stories they want to focus on this iteration. But if those are the first four, that might not be enough of the system to put up a website.

Claudio: No. Absolutely. And in fact, actually, we are redesigning our website internally in our case and yeah, it will take five or six iterations before we can go live because we need to replace the old one and we want to have basic things but the things that really count, and we can't do that before we manage to go through all those iterations.

Ron: OK. So then, you have to have some kind of planning where you, where you say, OK, here's some of the user stories.

Claudio: Yeah.

Ron: And then you say, in order to have a useful website, we have to have at least these and those might take five iterations to get done and we'll decide what order we're going to focus on them."

Sometime people complain that in Agile, there's such a narrow focus. "Oh, just this iteration and those four stories." And they said, "Well, how could you possibly architect something if that's all in your focus." But what I'm saying is you do have a larger focus so the architect can say, "Well, I know we're going to be doing all of these stories. These stories are going to induce some requirements on the architecture. So even though this iteration, we're only working these, the architect's going to say, "Well, you can't do that because this iteration over here's going to need something else."

Claudio: Yeah. General wise, actually, there is a space for it and it is the release plan for that to be right. Because, yes, we can talk about two weeks iterations and you really focus and try to understand all the details about the story at that point. But there is also the aspect of a release plan, which pretty much puts all these iterations together and essentially say, "All these iterations will make a release."

Ron: Yeah.

Claudio: The fact, me and you as developers, we don't know when the release is until the customer actually tells us all the stories put together are enough to make a release.

Ron: Mmm hmm.

Claudio: Because we don't know. Can we go live without the speech or what? I don't know. Like we have to ask the customer, really.

Ron: Sure.

Claudio: And I think actually, the most exciting aspect, I think, of in Agile that I find, I really get excited with. You have all these index cards. There are physical index cards on a table and divided into iterations. And the thing about index cards is it's better, perhaps, than an Excel spreadsheet, because you can easily reprioritize them. You can move them around, you can move things from one iteration to another before you actually do it.

And so, I'm right and it's really exciting to see. Hold on, like if you actually moved this before, maybe you can go to release date before this. Have you considered that aspect? It's really, really exiting to see that part. The trick, though, is that because we don't invest or if we go to extremes, we may not invest too much on what the actual story means in terms of development.

That is really where communication skills with the customer are important. And the other aspect is that it's not just communications skills in the sense of just talking to them, we do have to listen and really dig down into what they're really looking for. What is the outcome that they are looking for? Most people say communication skills is not about talking, it's about listening.

Ron: Yeah.

Claudio: You really have to listen first. That's one rule for us. But the other aspect is actually to take responsibility for our own creative capabilities. One of the most over-complex applications I've built in the past was as I realized that I did not take responsibility for my creative support. You know, you just say what the customer says and you do whatever the customer asks for. You never question that, you do all the features and unfortunately, we easily get into that trap of add-in features like checkboxes because the marketer, you know, our market guys ask for everything.

But one of the solid things about doing the most important thing first is that after a while, you may realize - you may not realize it immediately, but as you build things, you get feedback. And as you get feedback, you actually start thinking, "Maybe those important things are enough. The features that we built at that point are enough."

Let me give you an example. If we build say, a mobile phone, we would have a... OK, let's start building a mobile phone. If we are Waterfall or Russian Unified, or whatever, we decide actually what we have to build. We listen to the customer. "Ah, we need to have a keyboard, we need to have a display, but we also need to download songs and we need to have a camera." You know, everything. Then of course, there is this war because the other company does the same and it's absolutely everything or nothing.

Ron: Yeah. Right.

Claudio: But in Agile, we say, "OK, what do you want first?" Because we can't build everything in two weeks or a month. Right? We can't do that, so what do we start with first? Well, we need a keyboard. I need to talk and I need to listen. Fair enough. Very basic phone, maybe not even on display. You know, very basic things. And we start building that.

And at the very end of that, let's say it takes two weeks iteration, OK? We demo that. We demonstrate that. In fact, in our company, what happens is we as a team don't demonstrate that, the customer that asks for the feature, demonstrates that.

Ron: Oh.

Claudio: And the reason for doing that is that it does announce the kind of collaboration where the customer, at least at the end of the iteration on the last few days before he has to demo the damn thing, better go there and ask us exactly what we did there, right?

Ron: Mmm hmm.

Claudio: And because, otherwise, we won't be able to do the deal.

Ron: You know what I like about that is that it puts the customer on your side. You know, it's not like if you're demoing for them, they're the critic. They sit back and they say, "Well, I don't like that, " and "I don't think that." But if you get them on your side and say, "Well, you have to demo it, " you're going to have those conversations before you show everybody.

Yeah, and they're going to be working out with you the things they like or don't want and they're owning the project as well.

Claudio: Absolutely. And there's a lot of feedback we get as well because as you demo, you see, the customers, they want this within the companies. An internal customer, customer proxies, you know, the typical products manager, whatever. They demo this in front of the company and at the beginning, I was told, "You never get feedback. People are so much more ask to do, " and so, as it turns out, on the first iteration where we applied this kind of stuff, we got pretty much three-quarters of the company sending feedback.

Ron: Wow.

Claudio: So we use the feedback and we also did a so-called retrospective, which is a postmortem.

Ron: Mmm hmm.

Claudio: I used to do postmortems in the past at the end of a big project. You get up and say, "Well, what did work what did work, " and that crap. Or we would do something different and so on, right?

Ron: Mmm hmm.

Claudio: The problem about doing that at the end of a project is it's too late to save that project. It might be helpful for other projects, but not for that one.

Ron: Yeah.

Claudio: However, if we do retrospectives at the end of each iteration, as it turns out, we get to analyze what went well for the iteration. In fact, actually, we're in a room, white boards. Column one, we have what works in this iteration. Second column, what didn't work that well. Third column, what we're going to do on the next iteration actually to improve.

For example, when we start our projects like this, typically, the customer is available but not available. Sometimes, if the customer is actually there, like in the office, that's great. Sometimes, that's not the case. In our case, we work within Ireland and the U.S. as well. We have some offices in the U.S. And pretty recently, actually, we started the projects, the customer was great, he actually came, we did the planning and everything off the stores. So, no reason to believe that the project couldn't work well, right?

Ron: Right.

Claudio: Now, at the end of the first iteration, the customer says, "Well, you know what, I'm not ready to do the deal to the company." Fair enough. And the developers were saying, "Well, actually, we didn't interact that much with the customer in the first place. And so, that's something that really didn't work. How are we going to tell him? How are we going to save the project?" Because a lot of software that we produced, and the result of lack of feedback from customer. We produced, we spent months developing stuff. The customer doesn't see anything. What they see is a piece of paper. That, most of the time, doesn't work that well unless the customer is really lucky in there, and understands everything.

So, we did a retrospective. We said, "Well, what did we like about the first iteration?" Well, we liked... The feedback was really positive. A lot of people really loved the thing, and so we started with the nice things, and the customer actually... We started saying, "One problem was, I didn't like that you didn't do the demo. It would have been great to do the demo."

And somebody else started, "Well, I didn't like the fact that you weren't as available as you could be. Or maybe we should try to be better, like in the first case."

So, the customer came back and said, "Yeah, I apologize for this, guys. It's really hard to find the time." And so on. However, we scheduled a twice weekly conference call. We discussed features in that way.

So, as you see, on the second iteration, that happens, and as a consequence, the customer was able to do the demos, and so on. Without a retrospective, it would be hard, actually, to talk about these things. Again, there are techniques to make sure that those kinds of meetings feel safe. Some people don't feel comfortable talking to everybody else about things that didn't work that well.

That, in a way is.... The outside is what the rest of the company sees. It's our own laundry, in a way. But it works really well.

Ron: You know, that's a terrific idea, because, like you said, the big postmortem... I've always found those really difficult. Often they're just a time when people complain about other people, or things they didn't like.

Claudio: Things that become a blaming game.

Ron: Yes, that's right. I found in most organizations that nobody was really learning anything from them anyway, and so a lot of companies just quit doing them because it just left a lot of bad feelings around.

Claudio: I know. There are definitely some rules. There is one main rule. That is, "Here we're not to blame. It is actually how to improve." You actually try to move the responsibility outside the people, and about the actions, I guess, that happened in that iteration.

Ron: This is the one thing that I wondered about on Agile projects, is that you've got the businessperson, somebody from the company that wants this project. You're trying to get them engaged in it, but I'm that's often the case. That these people have a lot of other responsibilities, and they don't want to devote the time they need to do this. And so, I was curious about how you deal with that.

Claudio. Yeah. I guess it's fair, and the point is it probably doesn't work that well... Agile doesn't work that well if the customer is not available. What happens is then you go to the point where you have a proxy of that customer. It's actually somebody who acts as the customer, and invents what he thinks the customer asks for.

Ron: So it seems that you would need, at the very beginning of the project, be very, very clear with the customer, and say, "This is how we do it, " and set the expectation up front, and say, "Our success is going to depend on your availability to engage."

Claudio: It is. And you can, I guess, schedule it a little bit. Set availability, instead of saying you're always available. Of course, you schedule that in some way. That is one of the problems I see, as I said before, was using use case style, where you would spend literally a couple of months just writing use cases, OK?

Ron: Yeah.

Claudio: And then that was it. That was the contract. And then the customer was almost unneeded; I'm not saying unneeded, because of course there ambiguities, in the language and so on. But then the customer, in theory, wasn't that available. However, almost all the time, all those systems were overcomplicated. They were over-engineered. They were what they asked; the systems weren't exactly what the customers need.

Actually, to take back the idea of what I mentioned before about the mobile phone, as we go through iterations and we start building pieces, what comes out is another thing that I kind of love about this system is we should be more opinionated in the way on the software that we write. And adding features doesn't make a software necessarily better. OK?

And one way is to think, for example, my granny, she buys only books that have big fonts. She can't read, OK? So if you think in terms of mobile phones, what happens is, well, you could say, "How about, instead of adding the camera, downloading songs and whatever, how about we create a larger display?" So by doing that, as it turns out, you don't need the camera anymore.

Yes, if you think about the features that you're building and you build so much, but then you think about what you have there and you say, "Hold on a second. If I build a larger display, I can sell this stuff to the elderly people." And you created a market that you haven't thought about before...

Ron: Right.

Claudio: Probably, you couldn't think about before. And we keep it something simple, but designed for a particular market. Essentially, we are really talking about segmenting the marketing, right?

Ron: Sure, sure.

Claudio: And a lot of people are going to say, "Well, Claudio, you're trying to change too much. You're trying to change the customer, the customer's culture, the company's culture. It's hard stuff. The developers, how to develop software." But I think it's something that we have to try to do, in a way.

Ron: Yeah.

Claudio: To start making people think in terms of the value of simplicity and the value of outcomes, really, what you can get there, because sometimes you can get there sooner than you may think.

Ron: From time to time, you run into a project or a product or something where somebody looked at the problem in a really different way and they came up with a very unique solution that it just seemed like nobody ever did before.

And I think it's these kinds of processes, where you're really focused on the end result and the functionality, above all, that leads people to these kind of unique solutions. And someone will say, "Well, you know, maybe we don't need all that other stuff, " or "Maybe we don't need to be just like the other guys and try to do exactly what they did, only a little better." So these are good practices to get us to that.

Claudio: Yeah, really. And I think it's all a consequence of the constraints, I guess, sometimes, you have. And because you don't have time, you think in different ways.

Ron: Yeah.

Claudio: And it becomes really a practice, in a way.

Ron: Wow! Well, we're out of time. But thanks so much, Claudio, for sharing with me today.

Claudio: Thank you very much.

Ron: Claudio Perrone, ladies and gentlemen, with some really great thoughts on behavior driven development. And there was so much more we could've done. The thing I really liked about what we talked about was this idea of his version of the user's story, with like, "As a user, I want to do this sort of thing." And then the scenarios, where you say, "Given that particular condition, these things are true."

I loved that stuff so much, I put it into my "Introduction to Software Architecture" seminar that I do in various places around the world. And I hope that you get a chance to do one of those some day. It's a lot of fun. We spend a day talking about architecture and just learning from each other. There is no right answer in a lot of this stuff, so we have to just learn from each other about what works. That's what's great about architecture...