The Agile community is pretty strong and it’s actually getting quite stronger. I’m coaching with multiple companies in Iowa, it’s becoming very popular, the Agile Iowa user group which I co-founded with Kent McDonald and some of the other folks you probably know around here, the numbers are increasing, we’re having a lot of great conversations and really learn a lot from each other, so really enjoying the scene. The Midwest area is becoming what they’re kind of tentatively calling the Silicon Prairie, as opposed to the Silicon Valley, there’s quite a bit of tech startups coming up, so it’s a pretty good place to be.
Well, I would say that probably one of the drivers is there is a lot of technology, because there is a lot of financial services in Iowa so the technology business has been there, and I just think it’s low cost of living, a lot of technology people around to learn from and exchange ideas. The culture in Iowa also is pretty collaborative, right? So, it’s very much, you see somebody on the street and you walk by and you just say “hi”. So that makes exchange of information very easy, so I think all the information colliding together helps to make it good, plus the technology backgrounds.
Yes, ok, great. I started off, I don’t even remember, like 2003 or something like that, I was working in an organization and we were going to do a big project and they asked me to be involved in doing the big project and I said “I’m a terrible project manager, I’m not interested” and then we continued the conversation, eventually I got one of the executives to say “ok, we can do it, but we are going to do it completely differently, we’re not going to do the traditional project structure”. And so we started doing Rational Unified Process and we’re in the big use case writing phase and decided we needed some help with UP, so called a recruiter, not a recruiter, a consulting company, Valtech is actually who we called, and got a hold of a manager there and he said “hey, we’ve got a better way than Unified Process, are you interested?”, and he explained it to me and I said this sounds exactly what I am looking for. So we engaged them, I did that for a couple of years, that project ultimately failed, that transition ultimately failed, but it was at that point I said I am not going to work any other way, this is the way I want to work, it’s the most effective way to build product that I have ever seen.
And so I was hooked from that point on and I am also a lifelong learner, I just love learning stuff, so then that opened my eyes to a new way of doing things, so then I started getting more active in this community so that I could learn from more people and learn more ways of getting things done.
Absolutely, there are quite a few things that we learned along the way. What I learned probably the most out of that is the way we pitched Agile was “this is the way you’re going to get the project done successfully”. Now when I enter an organization, much less silver bullet and promises and much more influence and let’s not change so much at once so that people aren’t overwhelmed by the change and become subversive and let’s work within the constraints that you already have and help get you closer to where you want to be, rather than coming in and saying “let’s do XP, this is awesome, pair programming, story point estimation”, that stuff is just a recipe for disaster, unless you have the culture within the organization, there are some organizations in Iowa, that are large organizations, sent a lot of people here this year, they’ve got top down support, the employees are subordinate, everybody is subordinate. So that they were able to make a bigger change because their context was a little different, because people were willing to try stuff, where in a lot of contexts that I go into, you’ve got the people that work there 20 years and they think that’s the only way to do it.
I definitely think my approach to implementation has gone from a more of a big bang style to a slow burn, say “oh, we could add test driven development now, we could add pair programming now”. So, I would say that is the biggest influence that that failure had on me is learning how to effectively apply change as in influence people rather than rely on being the smart guy that knows how to do everything.
Yes, that’s interesting. I guess I haven’t really considered that too much, it’s hard, it’s kind of like asking Tiger Woods “how do you hit the golf ball so well?”, it’s really hard to explain. I’m pretty honest with them and I talk about the behaviors and if you have culture shock and how to effectively influence change, because you can go and do a new process, I’m sure you’ve been involved in these transitions too where you go in and implement the new process and then as soon as the consultant is gone, it goes away, because the consultant is not there orchestrating everything. So if you actually want to change the culture of the organization and have a lasting change, just having the coach come in and big bang and make a lot of progress now with the silver bullet, that’s not sustainable.
Yes. So the Defect Density Heat Map is a pretty cool tool that me and some of my colleagues at previous organizations and previous engagements came up with and it’s really a tool for the team, by the team and for the team. And what Defect Density Heat Map does is if you have traceability and a lot of companies these days, every time you put a commit into your source code repository you put what ticket it was associated with. So what the Defect Density Heat Map does is it goes out and it analyses your commit data and looks at your files in your version control and basically builds a tag cloud that shows the amount of churn in a file based on the number of features or defects it was changed for and then uses that to present the size. So if you have a file foo.java or foo.cpp that has been changed for say 15 different stories, it’s going to be bigger on the tag cloud than something that has only changed once for one unique story.
Now, the second half of the visualization is it takes foo.java and let’s say that’s big but then the size is how much churn it is, but then we change the color based on some other interesting information. And the other interesting information is we look at the ratio of those changes, how many of those changes are defects and how many of those changes are features and so if you have something that is really big and really red, that means that that file is changing a lot and they are all changing because of defects, so I know to be wary when I go into this code because this is involved in a lot of bad situations. So it’s kind of a tool for the team to give, just to be able to take and you can run it into your continuous integration, it just mines the version control logs and gives you what we call a heat map of where some of the potential problem areas are in your code. If there’s something that’s big and black, yes, it changes a lot but not too bad, but when it becomes big and red then we know it’s a significant problem so developers beware when you’re in that code.
Absolutely. I’d get concerned when I have team leads and Scrum Masters doing such things because I really want the tool to be for the team and have the team take ownership of keeping the code clean rather than the Scrum Master coming in and saying “you need to fix this, you need to do a refactoring, let’s put a story on the wall to refactor this code”. Now it might give the team leverage to go to a Scrum Master or a team lead and say “we’d like to refactor this code, and by the way, here’s the proof why we need to do it”. So, however with the right team lead, the right environment, yes absolutely, team leads, architects, it just depends.
So, CoEfficient is something that we’re just starting on and it’s going to have several components. The first one that we’re building, one is we’re turning the Defect Density Heat Map into a Maven plug-in. So, that way you can just be on your command line and just run it and makes it easier to integrate with continuous integration, those kinds of things. So that’s the first phase of it. It’s largely conceptual at this time, but the tools are going to contain things like an IntelliJ plug-in, we’ve all used Facebook and everybody says “where’s the Facebook dislike button?” Well, one of the things that we are going to be adding to that is a Facebook style dislike button for code, so when you’re in your IDE you can click dislike and then now you’ve got a quantitative way of looking at what do the developers, what code do the developers think is bad. You can look at cyclomatic complexity and some of these other things that are out there, the problem I have with those types of tools is those types of tools are very absolute, like cyclomatic complexity of seven. I was talking to some people today and they were doing physics engines for like how hair moves in the wind and stuff like that, there might be some complex stuff so you can’t look at that number. Code quality to me is largely a subjective thing too, right? You can have low cyclomatic complexity and they still think the code is garbage. So this is a way for teams to self-identify what code is good and bad in their system.
Right, absolutely. Other things that we plan on working on largely around source code analysis, things like I want Amazon recommendations for code, so did you know that whenever somebody changes foo.java they also change foo.xml or foo.properties? And that way you can start catching those things, how many times have you made a change and you think you’ve got everything done and when you push to the continuous integration server, there are environment differences because you forgot to change the configuration for that environment, or add that new configuration to the new environment? So, kind of these little helpful tips for people as they are doing their development.
Other areas that we want to build out in CoEfficient are, Craig is currently working on this section of code, let’s say it’s foo.java again, and I go and I start making changes to foo.java, what I want to know that since Craig is the primary committer on this, Craig is probably the expert, oh, and by the way, in the last week he’s been changing this a lot, so you might want to go talk to Craig before you go in and just start changing things because he might be in the middle of a refactoring, who knows? Or you just say “hey, I need to know who the expert is on this code”. Now, using CoEfficient, say “who’s the expert on this file?”, well based on commit history you know it used to be Bob but now it’s Sally, right? Sally has now been taking over, between those two you should probably be a pretty good start to understanding what’s going on, so those are the kinds of things, and I got those from experience working with teams and we would have somebody do a big refactoring in one area of the system and there’s teams 30 people big so it’s very easy to have somebody undoing somebody’s work because they weren’t aware, because they’re work working on a completely different feature, so those kinds of things are why we created CoEfficient.
There’s one other information radiator that’s coming out of that and that’s a build time tracker monitor thingy, and so it’s a Maven plug in and we’ve used it successfully at a client site but now we want to plugin it and make it more flexible because it was a one off, what it does is it actually records the amount of time that each individual spends building the software, so if you run a Maven verify before you push when you’re practicing continuous integration, what it does is it tracks the build time on your machine and then every time you send it, it pushes it up to a server and then the server collects that information and when it collects that information it also passes what the user name was, passes build times, it passes the current date and time, passes information about the machine.
So we’ve been able to do this, we’ve been able to identify people that need and quantitatively say “this guy spends, everybody else’s build is two and a half minutes, and this guy’s build is twelve and a half minutes”, I know his machine upgrade isn’t due yet but this is significant money that is going out the window because it tracks every time he does a build locally.
Craig: Working in enterprises, sign me up for that right now.
Yes, exactly. So it’s all about bringing visibility and a little bit of metrics driven kind of stuff.
Craig: I assume it would also give you, what I was thinking as you were saying that, probably it also gives you a good indication of the hidden build time, because everyone can see on whatever continuous integration server you are using, how long the build is taking but all those other builds that happen.
That’s exactly what it does, it collects at the developer’s work station it says this is how long the developer takes. It can also be used for coaching too, I can see that this person only commits and pushes once a week and this person is pushing three times a day and I know I am not going to spend that much time with this person espousing the virtues of continuous integration to the guy that is committing and pushing three times a day, however I might spend a little more time with the gentleman that only pushes once a week and help try to talk about that, so from a coaching perspective it’s a tool that I can use as well and unfortunately we built the tool after I’d already been coaching the team for a while, so I really didn’t need to leverage that but I am sure I could leverage that in that way down the road at later engagements.
12. Does that tool have a name at this point?
No, it’s just under the CoEfficient project, it’s probably just going to be just a big collection of tools.
Craig: That’s great. So we’ll definitely have to keep an eye on that, see where it goes and talk to you.
And add feature's to it!
Absolutely. Definitely difficult to pick, fortunately Brian Button was a stage producer with me and we had some great reviewers so we were able to get it whittled down but it was definitely difficult, there were a lot of great talks that I really wanted in and we just didn’t have the capacity for them, so popular ones here - Jim Highsmith, Velocity is Killing Agility, something that I spoke about a few years back, in fact I think it was in Chicago, I titled mine Value over Velocity, we monitor that stuff too much, some budgeting stuff, obviously Dean is doing a lot of his Scaled Agile framework stuff and scaling.
Craig: Dean Leffingwell?
Dean Leffingwell, yes. Doing a lot of that stuff here at this conference. Yes, it’s been great, it’s been a lot of fun.
I wouldn’t say I see too many trends in the talks, really. One of the things that Brian and I tried to do is get a really balanced array so there is something for everybody. I will say that there are a lot of people, I’ve been hearing through the grapevine that there are a lot of people looking for some solutions that might not be getting them. Some of the talks maybe are talking about these are the problems but then they are not offering solutions and the folks are saying I came here to learn solutions from people because I know I have a problem, so I am definitely going to keep that in mind next year if I help again with the conference, making sure that at least, like my talk, my talk offered very few solutions this year, it was primarily get people thinking about the topic, I offered how we solved some of these problems but I didn’t come in with a set of slides that said “take this back and you will be successful”, right? So making those kinds of things a little more explicit in the stage and session descriptions and those kinds of things I think might be helpful.
Craig: I think you are right here, not all talks are about just giving you the answer, things like your talk which we’ll cover in a moment, but awareness is just as much a big thing as giving people answers, it’s like a doctor, we can’t ring them up and say “I’ve got a headache, what should I take?”
Yes, abolutely!
Yes, yes. Maybe discovery session, maybe the types of sessions could be changed, I guess that’s a topic for another discussion.
I’ve been hearing a lot of cool stuff from attendees and what they’re doing, I come here to learn first and support my company second, which is probably backwards, but that’s the way I roll. And just lots of cool collaborative stories, vision boards, some of the kinds of things that people are doing, I’m really liking that I’m hearing a lot more about measurement this year, so I get to talk, I’m kind of a measurement nerd, so I get to talk with people about some of the more quantitative stuff and so I’ve been having a good time talking about that.
Well, I think there is a lot we can learn from measurements and quantitative and there’s all kinds of literature out there that’s been around and proven for years that it works and we aren’t applying them as well as I think we could be and I think that the Defect Density Heat Map, some of the stuff that we’ve been doing, the Build Time Monitor, if we don’t measure that kind of stuff then we have no way, we have no leverage when we go and try to get a new machine, we have no lever to use to improve, so the Defect Density Heat Map, we built that entirely so it made it easier for us to know where the nasty spots in our code were, because we all kind of intuitively know where they are but this just makes it much more visible. And so it gives us opportunities to have conversations. I was in a session just a little bit ago before I joined you, and they were talking about using measurement as feedback loops to help enable decisions and the right decisions, and so I feel like we’ve got a long ways to go, but I am really glad we are starting those conversations because I think it can take us to the next level.
Yes, so my talk was titled Stop Listening to Your Customers and it kind of melds some of these concepts. So, I’ve been in organizations over the years where we build these products and we TDD these products and we pair on them and the quality is good, so the technical risk is low, right? We’re getting really good at things like continuous delivery, we’re able to really kick butt in the technology space now, I don’t think we spend enough time thinking about how to build the product or the right product versus the product right. So, the Lean Startup stuff, over the years I’ve got tired of building, and this is where some of my fascinations with metrics, as developers, most developers actually want to work on cool and valuable stuff that customers like, so when they find themselves getting requirements to do things and then it turns out that they can go to say Google Analytics or any other and see that nobody is using those, that’s kind of a demotivator. And then you start looking at the cost that goes into building those features that people aren’t using, and all of a sudden you have a problem and the Chaos Report said 64% of features in a system are rarely or never used, right?
So, if you’re in a million dollar program that’s 640,000 dollars that you didn’t need to spend, and maybe it’s 45,000 or 450,000 dollars, some of those are never used, I’m not naïve, some of those that are never used you might need to check a box on some government requirement to even get your foot in the door and so in those cases yes, sure, you are going to have some things in your system that are not used but they are needed for marketing purposes, but largely I don’t see that kind of thing, largely it’s just some sales guy said “well, we lost this customer and they said the reason we lost is because we don’t have feature x and so then that gets built in the pipeline so we don’t lose another customer”, but we don’t know the ROI of that. So I had always planned on writing a book on this, over the last several years and I wanted to call it, tentatively titled, Production: The Missing Agile Feedback Loop, because we all get stuff into production, we jump up and down and pat ourselves on the back for executing well on this project and having high quality, but we don’t ever go back and look, or rarely do we go back and look to see if that effort was worth it, if we really got that return on investment.
And then, shortly thereafter, I guess a couple of years after I started pondering this book, this gentleman by the name of Eric Ries came out with this Startup Lessons Learned blog and I said “man, this totally resonates with, this is exactly what I’m talking about”, developers are accountable and the technical teams are accountable for estimates and managing risks and all this stuff, but then we don’t ever have, I don’t see that other side of accountability for the business and what I see is Lean Startup starts to bring that accountability for delivering the right product and making sure that the products we’re building are going to give us a return on investment. So somebody asked me at this session, after my session, what are some good books on this topic and I would say a Lean Startup is a good start, now we can’t apply those directly to our enterprise applications, but a lot of those techniques with a little bit of brain power, there’s a lot of really valuable stuff in the Lean Startup.
I would say maybe the biggest one that I see is a fear of our customers. If we tell our customers no on something, I mean I’m all about customers too, a well presented no is better than telling them yes and then spending 100,000 dollars adding a new feature that they are not going to use anyway, what’s the lifetime value of that customer and just because we are, and it’s natural, we want to please each other, we want to please our fellow and I don’t think it’s cost effective. So I like building great products, I like customers too, I just think that we need to be better at handling the customers, and our fear of our customers is probably the biggest barrier that we don’t have that relationship that we feel like we can tell them no.
Right. And I would even assert that one of the other problems is that we think we know our customers much better than we actually do, which was kind of the driver for my talk.
So, my thoughts around professionalism basically revolve around when I look at other industries, like doctors or sports and those kinds of things, I see the way professional athletes behave and I see the way professional software developers behave and one of the big things for me is when I look at a short stop for a baseball team, that guy understands the whole game of baseball, he just doesn’t know his position, in order for his team to be successful, he has to understand the whole game, he is not going to be an expert at pitching, he is not going to be deep at pitching but he understands when you’re going to walk somebody, probably when you are going to bean somebody in the head because you don’t like them, he understands how all the different players interact to make the team successful. So I believe that software professionals, in particular, and business professionals, we tend to get in these functional siloes and we go deep and we go very deep in development or project management, those kinds of things, which is great, we need to be deep, we need to have depth, but a lot of times that’s at the expense, shall I say, of understanding how what you are doing impacts the business and how, when you overbuild this feature or add a bunch of bells and whistles to this feature, you’re impacting all these other people in the organization and that has a real impact in an organization.
So part of the professionalism thing for me is just about we have to break out of our siloes and we have to appreciate and understand what it takes for everybody to be successful and not just focus in on our one specialty and say “I don’t care, just give me something to code”.
I think David Hussman is an example of somebody that, Dude’s Law, right? So, Dude’s Law is Value = Why Over How, and I think a lot of times what we can do is instead of focusing on what the practice is, focusing a lot more on why, and why it impacts other people, why does it impact program management, how does that impact marketing and I don’t think we are great at that yet, I think coaches naturally do that a little bit more, because it’s part of the influencing, the business folks need to understand that I am also their advocate, I am not just some technical guy that’s going to pick sides with all the technical people.
Where can they find my stuff? Well, GitHub and other than that, I don’t talk too much, so actually that’s the problem is I actually talk more than I do anything else, I like to hear myself talk. So, I would say bcarlso.net is my personal blog, everywhere on the web I am pretty much bcarlso, so I can explain that to you sometime, just drop me a line, DM me on Twitter, whatever and let’s continue the conversation.
Craig: That’s great. And if they can’t find you on the web certainly track you down at a conference.
Yes, absolutely, track me down at a conference and let’s talk.
Craig: Or in the middle of Iowa somewhere. Well, it’s been great talking to you, Brandon. Thanks very much for your time!
You too, thank you, Craig! Have a great day!