Steve: Hi, I’m Steve Ropa, I’m a coach with VersionOne, I tend to focus on the more technical side of the Agile World, XP Practices, Technical Practices and things like that.
Shane: Thanks, and John?
John: John Krewson, also a coach with VersionOne. My area of specialty I would guess, if I had to pick one, to be maybe the people side of Agile and also the product side of Agile.
Shane: Great, thank you. And Matt?
Matt: My name is Matt Badgley, I’m a coach with VersionOne as well, of course my side, I’m a pragmatic guy, so I try to touch a little bit of everything and I like technical stuff too, I believe you can’t be Agile without engineering practices.
Steve: Sure, what I’m trying to focus on is important those practices that are as Matt mentioned, we need to have a different way of growing programmers, from the very beginning maybe it’s some kid out of high school who’s just kind of curious of computers all the way to a professional, who wants to become truly recognized for his craft, and my talk was to sort of focus on, if that’s the way we are going to go, let’s think about in that way, let’s use the metaphor of Craftsmanship and Apprenticeship and Journeyman and Master as we go forth in our careers as well as just as a metaphor.
3. And what is it take to build Software Craftsman?
Steve: It takes a different way of looking at things, it takes a way to focus not just on the engineering practices, not just on the “how to”, to understand the science behind software but more the art, so think of it as a Craft, think of it as something that can truly put my energies and my focuses and my artistic talent into, and be a Craftsman you need to start with some basic practices but also some basic work habits. Test Driven Development, TDD can be taught but it needs to really be understood and internalized, it’s just how I write software. So if we start with Apprentices who are learning that, and learning this from a Master or a Journeyman, somebody who has reached that level where they can’t have that internalized, then they can continue to grow the Craft, they continue to grow themselves in the Craft. It’s also a way to overcome some of the challenges we’ve run into with the University systems which have been giving us a lot of good theory but not as much pragmatism.
4. Why do we need it? Why does it matter?
Steve: There are two answers to that, or two different reasons why we need it. First is we are still struggling to create great software, software people trust, software people know they can trust when they comes out the door, it’s very expensive to have to redo something, so if we are learning how to do it well early on, and yes, there are iterations but if we are learning how to do it well early on, we don’t have to go back and redo it completely. The other side is we have a crisis coming in our business, we are not producing as many strong programmers as we are strong programming jobs, and we are in a economy where a lot of people are struggling to find work and yet, there are a lot of unfilled jobs in our business that doesn’t make sense to me, we need to do something about that.
5. So what does Software Craftsmen looks like?
Steve: Hopefully they look like me. Software Craftsmen is somebody who they are not willing to, this is challenging, they are not willing to compromise quality but they are also willing to create “good enough” software, they understand the balance, they understand the value of something beautiful, something functional but it’s not perfect, if you look at a truly beautiful piece of furniture, I’m going to use woodworking as my example because that’s my hobby, a truly beautiful piece of furniture, very functional, very elegant, I love the way it fits in my room but if I’m going to inspect that thing, I will find a place where maybe somebody, a chisel might have gone a little too deep, I might even find a burn mark from a power tool, but that’s not what’s important, what’s important is the whole picture. A Craftsmen understands that and can visualize that, and can realize that through practices, through certain tools and skills, and on the top of that can also articulate those tools and those skills to somebody who is learning.
Shane: Great, thank you. John, a really intriguing title “The show must go on”.
John: Yes, that’s the short version, the long version is “The show must go on, Agile Leadership lessons learned from a life in th theater”, that’s a lot. It’s a mouthful.
Shane: So tell us about Agile lessons from a life in the theater.
John: A little background, I spent the first half of my life as an actor and I’m in the second half of my life now, I guess you are always in the second half of your life, hopefully there is a third if you’re counting this as the final marker of my life. In this profession (and it was a turning point about seven years ago) where I realized what I have been doing as an actor and a director in my previous life is really pretty much the same thing as what we are trying to do here in Software Development, and this talk is an opportunity to share some of those similarities, maybe drive a few points home and then offer a few lessons along the way.
6. Ok, so what are some of those similarities?
John: Well, to me acting is the essence of the iterative process. I should say producing a play is a great example of the iterative process, if you look at the process of rehearsal you’ll see iteration and incrementing throughout that process. You start incrementing, we are going to build this scene, we are going to build that scene, eventually we are going to couple a few things together once we have good enough increment and we are going to start iterating on it, layering it, nuancing it, making it smooth where it needs to be until eventually you can put it in front of an audience and get feedback.
I talk about Improv as the perfect example of rapid feedback; in the Second City in Chicago, they use their Improv performances to craft a new shell and they keep what’s funny and take out what’s not funny and eventually they can put a bow on it and call it a Review. I also get into a lot of the sociological benefits of learning how to act, learning how to deal with actors. There is a rule in the theater if you are directing a play that you never gave a line reading, so if an actor is reading a line and the director wants that actor to say that line differently, is just known that the director is not to say, rather you say it in this way, listen to how I say, give me a minute, now you say it like that. Because when you do you’ve totally taken ownership away from the actor, you’ve taken any kind of artistic license away from the actor, so what you want to do instead is hammer home the vision, what are we trying to achieve here, what is your character trying to do, what point are we trying to make in the play, use that as your motivation to say it a different way, and usually the way that the actor winds up saying is better than anything that the director could have dreamed of to begin with.
The reason I call it “The show must go on” is sort of a reflection of, I would call it a misconception among people who see the theater from the outside who think that it’s playtime, who think that it’s a kind of frivolous activity and I really couldn’t be further from the truth. There is a culture of commitment within the theater, so another familiar word, commitment. We are committed to making sure that this show gets produced, that it is of high quality and come hell or high-water, we are going to put it on, we are going to put it in front of an audience, and everyone involved doesn’t worry about the political things getting in their way because there is nothing separating them from the final production, you are the final production if you are an actor, so you are going to do everything you possibly can to make yourself look good and make the team look good, to make your rest of your cast look good.
John: Absolutely, I talk about tech reversal as well speaking of DevOps, tech reversal typically in a production is the first reversal where you get the lighting, the sound, the costumes involved and it’s miserable for actors, because the lighting designer is taking an hour to try to focus a light on a particular actor, the actor just has to stand there. Usually the actors just thinking, let’s get on that, but there is no perspective there, the actor has no idea what is involved in doing all that work and making that person look good. I think there is a lesson there that we can probably do a little bit more role sharing, gain some perspective. DevOps is a perfect play into that whole concept.
Shane: Cool, thank you very much. And Matt, Getting Past The Documentation Conundrum.
Matt: Yes, I choose a big word at the end. So Getting Past The Documentation Conundrum, the whole concept is helping people, it’s a workshop, and the whole idea is help people to get in the room and have that conversation with their peers, and give them a mechanism by which you can explain Agile Delivery doesn’t describe anything by documentation, there are frameworks out there which get a little more specific, but even some of the frameworks don’t really define exactly what we should do with documentation. So therefore people are left to their own devices to figure that problem out and if it’s coming from a traditional environment, you might have a governance type model and you are going to have a whole series of steps and procedures and documents that are fed out throughout the life cycle of building something even in a short cycle, and so therefore the result of that comes in play where, you use to do in Agile, the first that people say is: ”We do working software over comprehensive documentation, so therefore we don’t need to do that anymore”, and that’s not true, we know that not be true. So the whole point of this thing is help people get pass that and understand that Agile doesn’t say anything about this, but it does say very clearly which you have face-to-face communications, so let’s prefer those over that, so we can leverage that, let’s have the conversation about those collaborative documents and say… Prior to us sitting down we talked about the fact that is the context of certain documents that might only have one hour life, so should that be a document or it should be a white board conversation and maybe take a picture of it for eternity. So, the fidelity of things, a lot of the knowledge that I share in the talk in workshop, its stuff that’s out there, so it is a cobbled together bunch of different people’s ideas from Scott Ambler to Mike Cohn, all the guys that have helped inform this stuff, out and inform in the past. But one of the funny ones that I like it’s an acronym of tech called TAGRY which means “they aren’t going to read it”, and the reality is, that’s the case all time. So we should go out there and use the Wiki, put our documents out there and if you think that document it’s so important, make sure you publish it out there and look at the last time it was read.
John: It’s almost like a Lean Startup for documentation, prove that it was worthwhile to write the document in the first place.
Matt: Yes, so it was a waste, was it something that really truly delivered value? So we go through that exercise, it’s a really fun workshop, it’s fast, people are on their feet all the time, so I love those things, it’s a facilitation technique more than anything else.
Steve: I think it’s a good one, I really do, personally because of my technical bent I’ve been very happy with the content of adapt and breath on the content of the more technical and craftsmanship oriented tracks.
John: The variety’s really impressive this year and everybody seems to really know their stuff, really impressive.
Matt: People, you know, the general vibe and maybe is the economy, it’s getting a little better, maybe teams are getting more successful with Agile, but the general vibe, people are smiling, I see a lot more interaction in the hallways.
John: I personally have met a lot more people than I had at previous conferences.
Matt: People are not just passing each other really fast, they slowly passing and as soon as they make eye contact, they stop and they start talking, this is random strangers, which is awesome, and as well as it’s a tight-knit community, so it’s great to start seeing people repeated coming, you start making better connections and start running from one to another. It’s been great, I think not that the past years conferences haven’t been good, but definitely could tell the vibe, it’s a very positive one this year.
9. Any particular theme or message that you are seeing coming out of the conference so far?
Matt: You know it’s interesting, of course there’s the words out there, Scaling, DevOps, these are buzz-es, in the past have people I remember Kanban was a big discussion few years back, the anniversary a couple years back, the concept that this thing’s 10 years old, the Manifesto that was huge.
John: It is nice to see, given all of those new topics, Scaling, DevOps and all that, there is also a healthy dose of reminding us not to forget about the fundamentals, back to the basics.
Matt: Not just every talk it’s timed back to the basics which is great, keep these things in mind because they are good stuff, it has, it’s stood the test of time, it’s there.
Shane: Gentlemen thank you very much for taking the time to come and to talk to InfoQ today, we really appreciate it; enjoy the rest of the conference!
Thank you!
/filters:no_upscale()/sponsorship/topic/199c5fa7-5ded-446e-b353-89c55b6e83dd/QConSFLogoRSB-1653383003269.png)
Community comments