JV: It's like the tools just need to be able to communicate with each other, essentially.
SB:Right, so the commercial value-add is if you know what you're doing you can use your own bare bones. If you know that you're going to have time, GIT out of the box is fine. A lot of people, that's not where their valued added is. They don’t want to spend time figuring out all this stuff.
JV: Got you. Where do you see CM in the future? What do you see in store?
SB: It's interesting. The other thing, and I was talking to a colleague about this, is that we were talking about Git. The distributed version control systems seemed to be the thing to do and they have a lot of advantages. What we also realized is that often people who, not just because they're distributed, they're good because to be distributed they have interesting features and they do things like merging and so forth very well.
People, for example, don’t always need to use all the distributed features. Everybody is not working in Linux. Most use cases are you have some sort of centralized repository or two most corporate applications. You're actually interacting with that. Sometimes people get carried away by trying to use all the distributed features. Then that gets to the problem of, again, delaying integration so that at the end of the day you find a problem, but it's a week later.
JV: Yeah, because you're just someone who’s busy trying to play around with every little thing, every little tiny feature. When all you need it to do is one specific thing.
SB: Right, this integration thing; the sooner you get something all integrated and built and tested the sooner you’ll know there's a problem and you can fix it. Again, that's sort of the premise of why agile works, is that you're finding problems sooner because you can't really avoid all the problems.
JV: Is there any reason why you think companies feel much more open discussing transitioning agile than in the past beyond they just see everyone that's doing it?
SB:I think they see that everyone else is doing it. When I go to groups and things and talk to consultants who are—I work for a company so I do this I see some things, but a lot of—I talk to consultants who see it a lot more.
SB: People get strangled with a lot of the values. They say they want to be agile because it's a good recruiting thing because people want to work for agile companies. It's a good buzzword thing why wouldn’t you be agile?
I think a lot of people still struggle with a lot of the culture change aspects. How do you do requirements? How do you do deliverables How do you do deployments and all the downstream stuff?
JV: I was going to ask you about some of the common things you see companies get wrong when they decide they want to go agile? I mean, obviously, culture being much easier said than actually done.
SB: I think the product management stuff is often the hardest part because you're coming up with small requirements and it’s working things into Sprint.
JV: How does that shift in where they already have a product management team? They already have their ways of doing that. How do you merge those two groups together?
SB: Right. It's possible. It just requires changing the way you're doing it, changes in some job roles.
JV:All right, Steve I think we’re coming to a close. Anything you want to leave the reader with? Any final thoughts?
SB: No, I enjoyed talking with you. Again, the thing that I'm probably struck by is just the whole culture change what Josh Kerievsky’s doing. I feel like that could go somewhere. I'm not quite exactly sure where it's going to go.
It's just interesting that a lot of the things that we’re talking about are things people were talking about five years ago or ten years ago about agile. More people are aware of it. I guess that's the challenge is for it not to fade into just obscure buzz wordiness.
Actually, there is one more thing I do want to mention though is …
JV: Go ahead, feel free.
SB: There's this structured, like Scrum that have fixed iterations. Then, there's Kanban and they all have their place. What I have noticed people trying to do is they fail with Scrum because they just can't get their backlogs done at the end of two weeks. They say we’re going to do Kanban because that means we’re just one thing at a time. They work for different constituencies.